Chỉ mục chính

Một phần của tài liệu hệ cơ sở dữ liệu phân tán cassandra (Trang 45)

3. Mô hình dữ liệu Cassandra

3.8.1 Chỉ mục chính

Trong thiết kế cơ sở dữ liệu quan hệ, một khóa chính là khóa duy nhất được dùng

để xác định mỗi dòng trong bảng. Một chỉ mục khóa chính, giống như chỉ mục, tăng tốc độ truy nhập ngẫu nhiên tới dữ liệu trong bảng. Khóa chính cũng đảm bảo tính duy nhất

của bản ghi, và có thể điều khiển thứ tự trong đó các bản ghi được phân cụm một cách vật

lý, hoặc được lưu trữ trong cơ sở dữ liệu.

Trong Cassandra, chỉ mục chính cho một column family là chỉ mục của các khóa

dòng. Mỗi node giữ chỉ mục này cho dữ liệu nó quản lý.

Các dòng được gán cho các node bởi phân vùng cluster được cấu hình, và chiến lược đặt bản sao keyspace đã cấu hình. Chỉ mục chính trong Cassandra cho phép tìm kiếm

các dòng theo khóa dòng. Vì mỗi node biết khoảng các khóa mà nó quản lý, các dòng

được yêu cầu có thể được định vị một cách hiệu quả bằng việc quét các chỉ mục dòng chỉ

trên các bản sao liên quan.

Với các khóa dòng được phân vùng ngẫu nhiên (mặc định trong Cassandra), các

khóa dòngđược phân vùng bởi mã băm MD5 và không được quét theo thứ tự như trong

các chỉ mục cây nhị phân truyền thống. Sử dụng các phân vùng có thứ tự cho phép giới

hạn các truy vấn tới các dòng, nhưng không được khuyến khích vì độ phức tạp trong việc

3.8.2 Chỉ mục thứcấp

Các chỉ mục thứ cấp trong Cassandra chỉ các chỉ mục trên giá trị cột (để phân biệt

với chỉ mục khóa dòng chính cho một column family). Cassandra hỗ trợ các chỉ mục thứ

cấp của kiểu KEYS (tương tự như chỉ mục băm).

Các chỉ mục thứ cấp cho phép truy vấn hiệu quả bởi việc chỉ ra các giá trị bằng

phép bằng (where column x = value y). Và, các truy vấn trên các giá trị đãđược đánh chỉ

mục có thể áp dụng các bộ lọc bổ sung vào tập kết quả cho các giá trị ở cột khác.

Chỉ mục thứ cấp của Cassandra tốt nhất cho các trường hợp nhiều dòng chứa giá trị được đánh chỉ mục.

Ví dụ, giả sử bạn có mọt bảng user với hàng tỉ người dùng, và muốn tìm kiếm người dùng theo bang mà họ sống. Rất nhiều người dùng sẽ có cùng giá trị cột cho bang (như CA, NY, TX…). Đây là ứng cử viên tốt nhất cho chỉ mục thứ cấp. Mặc khác, nếu

bạn muốn tìm kiếm người dùng theo địa chỉ email của họ (một giá trị thường là duy nhất

cho mỗi người), thì có thể hiệu quả hơn khi duy trì một cách thủ công column family động dưới dạng một “chỉ mục”.

Thậm chí với các cột chứa dữ liệu độc nhất, sử dụng các chỉ mục thứ cấp cũng là một điều khôn ngoan, chừng nào khối lượng truy vấn tới các column family được đánh

chỉ mục là vừa phải và không dưới một tải liên tục.

Một ưu điểm khác của các chỉ mục thứ cấp là sự dễ dàng về mặt thao tác duy trì chỉ mục. Khi bạn tạo một chỉ mục thứ cấp cho một cột, nó đánh chỉ mục dữ liệu ngầm bên

dưới.

Các column family được client duy trì như những chỉ mục phải được tạo một cách

thủ công; ví dụ, nếu cột bang được đánh chỉ mục bằng cách tạp ra một column family như

users_by_state , ứng dụng client phải xây dựng column family với dữ liệu từ column

family users.

3.8.3 Tạo và sửdụng chỉ mục thứcấp

Bạn có thể chỉ ra kiểu KEYS khi tạo ra định nghĩa cột, hoặc bạn có thể thêm vào

sau để đánh chỉ mục một cột có sẵn. Các chỉ mục thứ cấp được tạo một cách tự động bởi

tiến trình nền mà không cần phải khóa các thao tác đọc, ghi.

Ví dụ, trong Cassandra CLI, bạn có thể tạo ra một chỉmục thứ cấp trên một côt khi định nghĩa column family (chú ý index_type: đặc tả KEYS cho các cột state và birth_year):

[default@demo] create column family users with comparator=UTF8Type

... and column_metadata=[{column_name: full_name, validation_class: UTF8Type}, ... {column_name: email, validation_class: UTF8Type},

... {column_name: birth_year, validation_class: LongType, index_type: KEYS}, ... {column_name: state, validation_class: UTF8Type, index_type: KEYS}]; Hoặc bạn có thể thêm một chỉ mục vào column family đã có:

[default@demo] update column family users with comparator=UTF8Type

... and column_metadata=[{column_name: full_name, validation_class: UTF8Type}, ... {column_name: email, validation_class: UTF8Type},

... {column_name: birth_year, validation_class: LongType, index_type: KEYS}, ... {column_name: state, validation_class: UTF8Type, index_type: KEYS}];

Vì chỉ mục thứ cấp được tạo cho cột state, giá trị của nó có thể được truy vấn trực tiếp với

những người dùng sống ở một bang nào đó, như

[default@demo] get users where state = 'TX';

3.9 Thiết kếmô hình dữliệu

Việc thiết kế một mô hình dữ liệu trong Cassandra cần một số cân nhắc trong thiết

kế khác so với trong cơ sở dữ liệu quan hệ. Sau cùng, mô hình dữ liệu bạn thiết kế phụ

thuộc vào dữ liệu mà bạn muốn lưu giữ và cách bạn truy nhập nó. Tuy nhiên, có một số

cân nhắc thiết kế chung cho việc dự kiến mô hình dữ liệu Cassandra.

3.9.1 Dựa trên các truy vấn

Cách tốt nhất để tới gần với mô hình hóa dữ liệu cho Cassandra là bắt đầu với các

truy vấn và làm ngược trở lại từ đó.

Nghĩ về các hành động mà ứng dụng của bạn cần thực hiện, bạn muốn truy nhập

dữ liệu như thế nào, và sau đó thiết kế các column family để hỗ trợ các mẫu truy cập đó.

Ví dụ, bắt đầu với việc liệt kê tất cả những use case màứng dụng cần hỗ trợ. Nghĩ về dữ

liệu bạn muốn lưu giữ và các tra cứu ứng dụng cần làm. Chú ý cả các yêu cầu về sắp xếp,

chỉ quan tâm đến dữ liệu của 6 tháng trước, những điều này nên là nhân tố trong thiết kế

mô hình dữ liệu cho Cassandra.

3.9.2 Phi chuẩn hóa đểtối ưu

Trong thế giới quan hệ, mô hình dữ liệu thường được thiết kế với mục tiêu chuẩn

hóa dữ liệu để giảm thiểu tối đa dư thừa. Việc chuẩn hóa thường liên quan đến việc tạo ra

các bảng có cấu trúc chặt chẽ, nhở hơn và sau đó định nghĩa quan hệ giữa chúng. Trong

quá trình truy vấn, các bảng liên quan được kết nối với nhau để thỏa mãn yêu cầu.

Cassandra không có mối quan hệ khóa ngoại giống như cơ sở dữ liệu quan hệ,

nghĩa là bạn không thể kết nối nhiều column family với nhau để đáp ứng mọt yêu cầu truy

vấn cụ thể. Cassandra thực hiện tót nhất khi dữ liệu cần thỏa mãn một truy vấn nào đó được đặt ở cùng một column family. Cố gắng thiết kế mô hình dữ liệu để một hoặc một

vài dòng trong một column family được dùng để trả lời mỗi truy vấn. Điều này hy sinh

không gian đĩa (một trong những tài nguyên rẻ nhất cho một server) để giảm số lượng tìm kiếm trên đĩa và lưu lượng mạng.

3.9.3 Lập kếhoạch cho việc ghi trùng lặp

Trong một column family, mỗi dòng được xác định bởi khóa dòng của nó, một

chuỗi có độ dài gần như không giới hạn. Khóa này không có dạng cụ thể, nó phải là duy nhất trong một column family. Không giống khóa chính trong cơ sở dữ liệu quan hệ,

Cassandra không bắt buộc tính duy nhất. Việc thêm vào một khóa dòng bị trùng sẽ upsert

(kết hợp của insert và update) các cột trong câu lệnh insert chứ không trả về lỗi vi phạm.

3.9.4 Sửdụng các khóa dòng tựnhiên hoặc thay thế

Một vấn đề cần xem xét là sử dụng các khóa tự nhiên hay thay thế cho một column

family. Một khóa thay thế là khóa được sinh ra (như UUID) xác định duy nhất một dòng,

nhưng không có quan hệ với dữ liệu thực tế trong dòngđó.

Với một số column family, dữ liệu có thể chứa các giá trị được đảm bảo là duy nhất và thường không được cập nhật sau khi dòng được tạo ra. Ví dụ, username trong column family user. Đây được gọi là khóa tự nhiên. Các khóa tự nhiên khiến cho dữ liệu

dễ đọc hơn, và loại bỏ nhu cầu các chỉ mục bổ sung hoặc phi chuẩn hóa. Tuy nhiên, trừ

khi ứng dụng của bạn đảm bảo tính duy nhất, thì vẫn có nguy cơ viết đè lên cột dữ liệu.

Và các dùng khóa tự nhiên không cho phép cập nhật khóa dòng một cách dễ dàng. Ví dụ,

nếu khóa dòng của bạn là một địa chỉ email và người dùng muốn thay đổi địa chỉ email

của mình, bạn có thể phải tạo ra một dòng mới với địa chỉ email mới và sao chép tất cả

3.9.5 Các kiểu UUID cho tên cột

Kiểu UUID comparator (id duy nhất) được sử dụng để tránh xung đột trong tên cột. Ví

dụ, nếu bạn muốn xác định một cột (như blog entry hay tweet) theo nhãn thời gian của nó,

nhiều client viết cùng một khóa dòngđồng thời có thể gây ra xung đột về nhãn thời gian, nguy cơ ghi đè dữ liệu không có ý định bị ghi đè. Sử dụng UUIDType để thể hiện một

KT LUN

Trong tiểu luận này nhóm em đã trình bày khái quát về hệ cơ sở dữ liệu phân tán

Cassandra. Cassandra, hệ thống phân phối và quản lý cơ sở dữ liệu, vốn được phát triển bởi

Facebook, công bố mã nguồn mở vào tháng 07/2008 và chính thức gia nhập vào “đại gia đình” Apache. Và trong cuối tháng 02/2010, Cassandra đã trở thành Apache Top-Level Project (TLP). Mặc dù vẫn còn khá mới mẻ với cộng đồng người sử dụng, nhưng công nghệ

của Cassandra đãđược ứng dụng rộng rãi trong những công ty và tổ chức có quy mô như

Cisco, Twitter và Digg.

Cassandra đã mở đầu cho một thế hệ database kế tiếp là một thế hệ cơ sở dữ liệu

non-relational (không quan hệ), distributed (phân tán), mã nguồn mở, horizontal scalable (khả năng mở rộng theo chiều ngang) có thể lưu trữ, xử lý từ một lượng rất nhỏ cho tới

hàng petabytes dữ liệu trong hệ thống có độ chịu tải, lỗi cao với những đòi hỏi về tài nguyên phần cứng thấp.

Tiểu luận đã giới thiệu về hệ cơ sở dữ liệu phân tán Cassandra, kiến trúc và mô hình dữ liệu trong Cassandra. Đây là một tiểu luận khá mới, phần lớn là tham khảo từ tài liệu nước ngoài, không thể tránh khỏi những thiếu xót. Chúng em mong thầy cô và các bạn góp ý để kiến thức của chúng em ngày càng hoàn thiện hơn.

Xin chân thành cảm ơn.

TÀI LIU THAM KHO

1. Apache Cassandra™ Documentation(http://www.datastax.com/doc- source/pdf/cassandra10.pdf)

2. Cassandra: The Definitive Guide–Eben Hewitt

3. Cassandra 2.0 Tutorial V1.0 Sébastien Jourdain, Fatiha Zeghir 2005/06/01 4. Cassandra–An Introduction Mikio L. Braun Leo Jugel TU Berlin, twimpact LinuxTag Berlin, 13. May 2011

Một phần của tài liệu hệ cơ sở dữ liệu phân tán cassandra (Trang 45)

Tải bản đầy đủ (PDF)

(50 trang)