3. Mơ hình dữ liệu Cassandra
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, lọc và nhóm dữ liệu. Ví dụ, nếu bạn cần các sự kiện theo một thứ tự thời gian, hoặc bạn
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 q 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ả các cột đang có từ dịng cũ sang dịng mới.
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
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 ngồ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