3. Mô hình dữ liệu Cassandra
3.8.1Chỉ 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ư (adsbygoogle = window.adsbygoogle || []).push({});
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. (adsbygoogle = window.adsbygoogle || []).push({});
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
KẾT LUẬN (adsbygoogle = window.adsbygoogle || []).push({});
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 LIỆU THAM KHẢO
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