tìm hiểu hệ quản trị cơ sở dữ liệu phân tán cassandra

ĐẠI HỌC QUỐC GIA TP.HCM
TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN
KHOA HỆ THỐN THÔNG TIN

LỜI CAM ĐOAN

Tôi cam đoan rằng, ngoại trừ các kết quả tham khảo từ các công trình khác như đã ghi
rõ trong luận văn, các công việc trình bày trong luận văn này là do chính tôi thực hiện
và chưa có phần nội dung nào của luận văn này được nộp để lấy một bằng cấp ở
trường này hoặc trường khác.
Ngày 6 tháng 1 năm 2008,
Phan Nhật Hải – Nguyễn Hoàng Anh

BÁO CÁO BÀI TẬP LÝ THUYẾT

TÌM HIỂU HỆ QUẢN TRỊ CƠ SỞ DỮ LIỆU PHÂN
TÁN CASSANDRA

GVHD: Nguyễn Trường Sơn
---oOo--SVTH:

1
TP. HỒ CHÍ MINH,
05/ 2012


TÓM TẮT
Mục đích của bài báo cáo này là tìm hiểu hệ quản trị cơ sở dữ liệu (DBMS)
phân tán Cassandra để từ đó có thể thấy được sự khác biệt của nó so với hệ quản trị cơ
sở dữ liệu quan hệ (RDBMS). Bài báo cáo này tập trung chủ yếu vào việc tìm hiểu
kiến trúc của Cassandra (Cassandra Architecture), mô hình dữ liệu (data model), quản

cách quản lý và truy suất dữ liệu (managing and accessing data), ngôn ngữ truy vấn
của Cassandra (Cassandra Query Language) và một số khác niệm mới được định nghĩa
trong một hệ quản trị cơ sở dữ liệu phân tán. Từng phần sẽ được trình bày theo từng
chương và sẽ đi từ tổng quát đến chi tiết để có thể tiện theo dõi. Hiện tại Cassandra
vẫn còn tiếp tục phát triển nên trong tương lai nó sẽ xuất hiện thêm nhiều vấn đề mới
mà bài báo cáo này chưa đề cập đến.

2


MỤC LỤC
TÓM TẮT......................................................................................................2
MỤC LỤC......................................................................................................3
DANH MỤC HÌNH.......................................................................................5
DANH MỤC BẢNG......................................................................................6
Chương 1. GIỚI THIỆU.................................................................................6
1.1. Khái niệm..............................................................................................................6
1.2. Các đặc trưng của Cassandra................................................................................7
1.2.1. Tính phân tán............................................................................................................7
1.2.2. Tính co giãn (Elastic Scalability)..............................................................................7
1.2.3. Tính hướng cột (Column-Oriented)..........................................................................7
1.2.4. Tính sẵn sàng cao (Highly Availability)...................................................................7
1.2.5. Chấp nhận sai (Fault Tolerant)..................................................................................7

1.3. Mục đích của báo cáo............................................................................................7
1.4. Cấu trúc bài báo cáo:.............................................................................................8

Chương 2. KIẾN TRÚC CASSANDRA........................................................9
2.1. Giao tiếp giữa các node (Gossip)..........................................................................9
2.1.1. Hiểu về cluster membership và seed nodes..............................................................9

2.1.2. Hiểu về Failure Detection và Recovery..................................................................10

2.2. Phân vùng dữ liệu (data partition) trong Cassandra...........................................11
2.2.1. Hiểu về phân vùng dữ liệu......................................................................................11
2.2.2. Các loại phân vùng..................................................................................................12
Random Partitioner..........................................................................................................12
Ordered Partitioners.........................................................................................................12

2.3. Hiểu về Snitches..................................................................................................13
2.4. Hiểu về Replica Placement Strategy...................................................................13
2.4.1. SimpleStrategy........................................................................................................13
2.4.2. NetworkTopologyStrategy......................................................................................14

2.5. Hiểu về yêu cầu của client trong Cassandra.......................................................14
2.5.1. Hiểu về yêu cầu ghi.................................................................................................15
2.5.2. Hiểu về yêu cầu đọc................................................................................................15

Chương 3. MÔ HÌNH DỮ LIỆU CASSANDRA.......................................17
3.1. So sánh với RDBMS...........................................................................................17
3.2. Keyspace.............................................................................................................19
3.3. Column family....................................................................................................20
3


3.3.1. Hiểu về column.......................................................................................................21
3.3.2. NHỮNG CỘT ĐẶC BIỆT......................................................................................21
3.3.3. Kiểu dữ liệu.............................................................................................................22

3.4. Index trong Cassandra.........................................................................................23
3.4.1. Primary index..........................................................................................................23

3.4.2. Secondary index......................................................................................................23

Chương 4. QUẢN LÝ VÀ TRUY XUẤT DỮ LIỆU...................................25
4.1. Hiểu về ghi trong Cassandra ..............................................................................25
4.1.1. Hiểu về Compaction................................................................................................26
4.1.2. Quản lý giao tác và truy suất đồng thời..................................................................26
4.1.3. Hiểu về Inserts và Updates......................................................................................27
4.1.4. About Deletes..........................................................................................................27
4.1.5. Hiểu về ghi vào Hinted Handoff.............................................................................28

4.2. Hiểu về đọc trong Cassandra..............................................................................29
4.3. Hiểu về nhất quán dữ liệu trong Cassandra........................................................30
4.3.1. Tùy chỉnh tính nhất quán cho những request của client..........................................30
Nhất quán ghi...................................................................................................................30
4.3.2. Những tính năng chỉnh sauaw tính nhất quán được xây dựng sẵn trong Cassandra
...........................................................................................................................................31

Cassandra có một vài tính năng được xây dựng sẵn để đảm bảo rằng dữ liệu vẫn
còn nhất quá thông qua nhiều bản sao..........................................................31
4.4. Client APIs cho Cassandra.................................................................................32
4.4.1. Cassandra CLI (Command-line Interface)..............................................................32
4.4.2. CQL (Cassandra Query Language).........................................................................32
4.4.3. Những client cho Cassandra ở cấp độ cao khác......................................................32

Chương 5. NHỮNG HOẠT ĐỘNG TRONG CASSANDRA......................33
5.1. Tùy chỉnh trong Cassandra.................................................................................33
5.1.1. Tùy chỉnh cache......................................................................................................33
Cách cache hoạt động......................................................................................................33
Cấu hình key cache cho Column Family.........................................................................33
Cấu hình row cache cho Column Family.........................................................................34

5.2. Backup và Restore dữ liệu..................................................................................34
5.2.1. Tạo Snapshot...........................................................................................................34
5.2.2. Xóa file Snapshot....................................................................................................35
5.2.3. Cấu hình thông số Incremental Backups.................................................................35
5.2.4. Restore từ một Snapshot.........................................................................................36

Chương 6. CLI VÀ CQL...............................................................................37
6.1. Command-Line Interface (CLI)..........................................................................37
6.1.1. Tạo một Keyspace...................................................................................................37
6.1.2. Tạo một Column Family.........................................................................................38
6.1.3. Thêm Row và Column............................................................................................38
4


6.1.4. Đọc Rows và Columns............................................................................................39
6.1.5. Index một Column..................................................................................................40
6.1.6. Xóa Rows và Columns............................................................................................40
6.1.7. Drop một Column Families và Keyspaces..............................................................40

6.2. Cassandra Query Language (CQL)....................................................................40
6.2.1. Khởi động chương trình CQL(cqlsh)......................................................................41
6.2.2. Chạy lệnh CQL bang cqlsh.....................................................................................41
Tạo một Column Family..................................................................................................41
Insert và Retrieve Columns..............................................................................................41
Thêm Column với ALTER COLUMNFAMILY.............................................................42
Thay đổi metadata của column........................................................................................42
Xóa metadata của column................................................................................................42
Tạo Index cho một Column.............................................................................................42
Xóa Column và Row........................................................................................................43

Xóa Column Family và Keyspaces..................................................................................43

Tham khảo ...................................................................................................43
44
44

DANH MỤC HÌNH

5


DANH MỤC BẢNG

Chương 1.

GIỚI THIỆU

Ngày nay, các dịch vụ trên internet phải xử lý một khối lượng dữ liệu rất lớn.
Hầu hết dữ liệu sẽ được lưu trữ phân tán trên nhiều máy chủ khác nhau. . Vì vậy, các
hệ quản trị cơ sở dữ liệu quan hệ (RDBMS) tỏ ra không còn phù hợp với các dịch vụ
như thế này nữa. Người ta bắt đầu nghĩ tới việc phát triển các DBMS mới phù hợp để
quản lí các khối lượng dữ liệu phân tán này. Các DBMS này thường được gọi là
NoSQL (Not only SQL). Một đại diện nổi bật của các NoSQL là Cassandra.
1.1.

Khái niệm
Cassandra là một quản trị hệ cơ sở dữ liệu phân tán mã nguồn mở được thiết kế

để sử lý một khối lượng lớn dữ liệu giàn trải trên nhiều node mà vẫn đảm bảo tính sẵn
sàng cao (Highly Availability), khả năng mở rộng hay thu giảm số node linh hoạt

(Elastic Scalability) và chấp nhận một số sai sót (Fault Tolerant). Nó được phát triển
bởi Facebook và vẫn còn tiếp tục phát triển và sử dụng cho mạng xã hội lớn nhất thới
giới này. Năm 2008, Facebook chuyển nó cho cộng đồng mã nguồn mỡ và được

6


Apache tiếp tục phát triển đến ngày hôm nay. Cassandra được coi là sự kết hợp của
Amazon’s Dynamo và Google’s BigTable.
1.2.

Các đặc trưng của Cassandra

1.2.1. Tính phân tán
Khả năng phân chia dữ liệu thành nhiều phần đặt trên nhiều node khác nhau
trong khi người dùng vẫn thấy được dữ liệu này là một khối hợp nhất
1.2.2. Tính co giãn (Elastic Scalability)
Khả năng của hệ thống có thể mở rộng số node trong cluster để có thể phục vụ
một số lượng request đến nhiều và thu giảm số node khi số lượng request đến ít.
1.2.3. Tính hướng cột (Column-Oriented)
Các RDBMS hướng dòng (row-oriented) phải định nghĩa trước các cột
(column) trong các bảng (table). Đối với Cassandra các bạn không phải làm điều đó,
đơn giản là thêm vào bao nhiêu cột cũng được tùy theo nhu cầu của bạn.
1.2.4. Tính sẵn sàng cao (Highly Availability)
Dữ liệu được chia làm nhiều bản sao lưu ở nhiều node nên khi client thực hiện
tác vụ đọc/ghi thì Cassandra có thể đáp ứng ngay lập tức bằng cách thực hiện trên bản
sao gần nhất hoặc trên tất cả các bản sao (phụ thuộc vào thông số ConsitencyLevel do
client thiết lập).
1.2.5. Chấp nhận sai (Fault Tolerant)
Dữ liệu của bạn đẽ được sao chép thành nhiều bản trên các node của cluster.

Nếu chẳng may một node nào đó bị hỏng, bạn vẫn có thể truy xuất dữ liệu của bạn trên
các node khác.
1.3.

Mục đích của báo cáo
Mục đích của bài báo cáo là tìm hiểu hệ quản trị cơ sở dữ liệu phân tán

Cassandra ở các mặc:
• Kiến trúc bên trong của Cassandra.
7


•
•
•
•
•

Mô hình dữ liệu trong Cassandra.
Đọc/ghi trong Cassandra.
Index trong Cassandra.
Sử lý giao tác, nhất quán dữ liệu, truy suất đồng thời trong Cassandra.
Ngôn ngữ truy vấn của Cassandra.
Đó là những vấn đề cần phải xem xét khi tìm hiểu một hệ quản trị cơ sở dữ liệu.

Ngoài ra còn có một số vấn đề đặc trưng riêng của hệ phân tán cũng được bàn đến như
phương thức trao đổi thông điệp giữa các node, phương thức phân chia dữ liệu giữa
các node, …
1.4.

Cấu trúc bài báo cáo:
Chương 1 giới thiệu khái niệm, các đặc trưng của Cassandra và mục đính của

bài báo cáo.
Chương 2 trình bày kiến trúc của Cassandra.
Chương 3 trình bày mô hình dữ liệu của cassandra.
Chương 4 trình bày cách quản lý và truy xuất dữ liệu trong cassandra.
Chương 5 trình bày các hoạt động diễn ra trong cassandra.
Chương 6 trình bày ngôn ngữ truy vấn trong Cassandra (CQL) và giao diện lập
trình bằng dòng lệnh (CLI).

8


Chương 2.

KIẾN TRÚC CASSANDRA

Hệ thống Cassandra là hệ thống tập hợp một hoặc nhiều node độc lập kết hợp
với nhau tạo thành một cluster. Trong một cluster Cassandra, tất cả các node đều
ngang hàng với nhau, nghĩa là không có một node đóng vai trò là master điều phối các
request đến các node còn lại.
2.1.

Giao tiếp giữa các node (Gossip)
Cassandra sử dụng một giao thức gọi là gossip để tìm ra thông tin về trạng thái

và vị trí của những node thành viên trong Cassandra cluster. Gossip là một giao thức
giao tiếp ngang hàng (peer to peer). Mỗi node định kì sẽ trao đổi thông tin của chính
nó cho những node khác trong cluster và ngược lại.

Trong Cassandra, gossip chạy mỗi giây và trao đổi thông điệp trạng thái với 3
node khác trong cluster. Thông tin trao đổi bao gồm thông tin về chính nó và về những
node khác mà chúng đã gossip cùng. Nhờ đó, mỗi node sẽ biết nhanh chóng về tất cả
các node còn lại. Thông điệp gossip có một thông số version kết hợp với nó để trong
suốt quá trình trao đổi gossip, những thông tin cũ sẽ được thay thế cập nhật bởi những
thông tin mới hơn.
2.1.1.

Hiểu về cluster membership và seed nodes
Khi một node được khởi động, nó sẽ xem file cấu hình của nó để biết tên của

cluster và những node khác trong cluster, quá trình này gọi là seed nodes. Những cấu
hình này được đặt trong file cassandra.yaml
Để ngăn chặn sự phân vùng trong truyền thông gossip, tất cả các node trong
cluster nên có cùng list của những seed node được list trong file cấu hình. Đây là điều
9


quan trọng nhất cho lần đầu tiên node khởi động.
Để biết được dãy dữ liệu mà node chịu trách nhiệm lưu trữ, nó phải biết token
cửa nó và token của những node khác trong cluster. Khi khởi tạo một cluster mới, bạn
nên khởi tạo token cho toàn bộ cluster và gán token khởi tạo cho mỗi node trước khi
start nó. Mỗi node sau đó sẽ gossip token của nó cho những node khác.
2.1.2.

Hiểu về Failure Detection và Recovery
Failure Detection là phương pháp cho mỗi node để xác định các node khác

trong hệ thống đang hoạt động hay không. Thông tin của Failure Detection dùng bởi
Cassandra để tránh định tuyến những yêu cầu của người dùng đến những node không

hoạt động này. Nó cùng dùng để tránh định tuyến đến những node vẫn còn hoạt động
nhưng có hiệu suất thấp.
Quá trình gossip theo dõi hoạt động của các node dưới dạng trực tiếp (thông
qua những node gossip trực tiếp đến nó) hoặc gián tiếp. Suốt quá trình gossip, mỗi
node sẽ duy trì một khoảng thời gian (interval) để cứ sau một khoảng thời gian đó thì
nó lại theo dõi một lần (quá trình gossip được chạy)
Sự hư hỏng của node có thể là kết quả từ nhiều nguyên nhân như là hư phần
cứng, mạng ngừng hoạt động. Node ngừng hoạt động thường là ngắn thôi nhưng nó
cũng kéo dài trong nhiều interval.Một node ngừng hoạt động nhưng chưa được phát
hiện ra thì những node khác vẫn cứ định kì gossip với nó. Để thay đổi vĩnh viễn
membership giữa các node trong cluster người quản trị phải chỉnh sửa tường minh từ
casssnadra cluster sử dụng tiện ích nodetool
Khi một node hoạt động trở lại từ trạng thái ngừng, nó có thể thiếu những bản
sao dữ liệu mà trong lúc nó ngừng hoạt động được các node khác chuyển đến. Khi
Failure Detection đánh dấu một node là ngừng hoạt động thì việc những bản sao bị
thiếu sẽ được ghi vào những node khác nếu hinted handoff được enable. Mặc dầu vậy,
có thể có một số bản sao bị mất giữa trong khoảng thời gian từ khi một node ngừng
hoạt động đến khi nó được nhận dạng là không hoạt động. Hoặc nếu một node ngừng
hoạt động lâu hơn một khoảng thời gian cấu hình trong max_hint_window_in_ms
hints sẽ không được ghi lại những bản sao bị mất. Vì lý do đó nên cách tốt nhất trong

10


thực tế là chạy tiện ích nodetool repair định kì trên mỗi node để đảm bảo dữ liệu nhất
quán và cũng nên chạy repair sau khi phục hồi lại một node vừa bị ngừng hoạt động.
2.2.

Phân vùng dữ liệu (data partition) trong
Cassandra

2.2.1.

Hiểu về phân vùng dữ liệu
Khi bạn khởi động một Cassandra cluster, bạn phải chọn cách để dữ liệu phân

chia giữa các node trong cluster. Đây được gọi là chọn cách phân vùng cho cluster.
Trong Cassandra, tổng dữ liệu được quản lý bởi cluster được biểu diễn như một
vòng (ring). Vòng được phân chia thành những khoảng bằng nhau cho tổng số node
với mỗi node chịu trách nhiệm cho một hoặc một vài khoảng. Trước khi một node có
thể join vào một vòng, nó phải được gán một token. Token quyết định vị trí của node
trong vòng và khoảng dữ liệu nó sẽ chịu trách nhiệm.
Dữ liệu của Column family được phân vùng dựa vào khóa của dùng (row key).
Ví dụ một cluster với 4 node với row key quản lý bởi cluster được đánh số từ 0-100.
Mỗi node được gán 1 token đại diện cho nó trong vòng. Trong ví dụ này, giá trị token
là 0, 25, 50, 75. Node đầu tiên với token 0 chịu trách nhiệm cho khoảng từ (75-0),
tương tự cho các token tiếp theo.

11


2.2.2.

Các loại phân vùng
Không giống với hầu hết các cấu hình được phép thay đổi trong Cassandra,

partitioner có lẽ không thay đổi nếu không khởi động lại toàn bộ hệ thống Cassandra
của tất cả các node trong cluster. Nó là một phần quan trọng và cấu hình partitioner
đúng trước khi khởi tạo cluster của bạn
Cassandra hỗ trợ một số partitioner, nhưng mặt đinh Random Partitioner là lựa

chọn tốt nhất cho hầu hết các triển khai thực tế của Cassandra
• Random Partitioner
Random Partitioner là loại phân vùng mặc định trong Cassandra. Random
partitioner sử dụng phương pháp băm để quyết định node nào sẽ lưu trữ một dòng
phân biệt của dữ liệu không giống như phương pháp lấy số dư theo node. Phương
pháp băm đảm bảo rằng khi những node được thêm vào hay lấy khỏi cluster thì dữ
liệu vẫn được phân bố đồng đều giữa các node
Để phân tán dữ liệu thông qua tập node, giải thuật hashing tạo một giá trị hash
MD5 của row key trong phạm vi giá trị từ 0 đến 2 127. Mỗi node trong cluster được
gán một token đại diện cho nó. Một node sau đó sẽ lưu trữ một khoảng những giá
trị hash nhỏ hơn token.
Lợi ích chính của cách tiếp cận này là một khi token được khởi tạo thích hợp,
dữ liệu từ tất cả các column family của bạn sẽ được phân tán đồng đều giữa các
node trong cluster mà ko cần tốn nhiều công sức. Ví dụ, một column family có thể
dùng username như là row key và column family khác là timestamp, nhưng row
key từ mỗi column family đơn sẽ vẫn được phân tán đồng đều giúp việc đọc ghi
được phân tán đồng đều giữa các node.
Lợi ích khác của dùng random partitioner là đơn giản hóa load balancing trong
cluster. Bởi vì mỗi phần của range hash sẽ nhận một số bằng nhau của row, dễ dàng
gán một row cho một node mới.
• Ordered Partitioners
Dùng cái này có thể đảm bảo row key được lưu trữ theo thứ tự đã sắp xếp
Dùng cái này có thể cho phép truy vấn một khoảng theo dòng như index truyền
thống. Ví dụ nếu ứng dụng của bạn dùng username để làm row key thì bạn có thể
12


scan dòng cho những user nằm giữa Jake và Joe. Cái này thì không thể trong
random khi mà thứ tự sắp xếp không biết được
Ta có thể thiết kế dữ liệu sao cho vẫn có thể thực hiện những câu truy vấn

khoảng trên tập cột hơn là tập dòng
2.3.

Hiểu về Snitches
Snitch là một thành phần có thể cấu hình của Cassandra dùng để định nghĩa

cách mà những node được nhóm với nhau trong toàn cấu trúc mạng. Cassandra sẽ
dùng thông tin này để định tuyến giữa các node trong cluster sao cho hiệu quả nhất có
thể. Snitch ko áp dụng cho những yêu cầu từ phía người dùng về node.
Snitch được cấu hình trong Cassandra.yaml. Tất cả các node trong cluster nên
dùng cùng một cấu hình snitch
Có

nhiều

loại

snitch

khác

nhau:

SimpleSnitch,

DseSimpleSnitch,

RackInferringSnitch, PropertyFileSnitch, EC2Snitch, EC2MultiRegionSnitch
2.4.

Hiểu về Replica Placement Strategy
Replica Placement là một loại cấu hình khi bạn tạo keyspace quyết định vị trí

của những bản sao cho keyspace phân tán trong cluster.
Một số loại phụ thuộc vào mục đích của bạn và thông tin mà bạn có về nơi
những node được cấp phát.
2.4.1.

SimpleStrategy
Mặc định khi tạo keyspace trong Command Line Interface CLI (Command

Line Interface) và phải khai báo tường minh trong CQL (Cassandra Query Laguage).
SimpleStrategy đặt bản sao đầu tiên lên node được quyết định bởi partitioner. Bản sao
tiếp theo được đặt ở node tiếp theo theo chiều kim đồng hồ mà không cần phải phải
xem xét nó thuộc vị trí nào trong cluster

13


2.4.2.

NetworkTopologyStrategy
Được dùng khi bạn có thông tin về cách các node được nhóm trong cluster của

bạn hoặc bạn có cluster của bạn triển khai trên nhiều cluster. Cái này cho phép bạn đặt
tả có bao nhiêu bản sao bạn muốn trong mỗi cluster.
2.5.

Hiểu về yêu cầu của client trong
Cassandra

Tất cả node trong Cassandra là ngang hàng. Một yêu cầu đọc/ghi của client có

thể đến với mỗi node trong cluster thì đều như nhau. Khi một client kết nối tới node và
đưa cho một yêu cầu đọc/ghi, node đó phục vụ như là một điều phối viên (coordinator)
đến các node còn lại. Công việc của nó giống như một proxy giữa client và các node.
Client gửi yêu cầu đến coordinator và coordinator quyết định node nào trong ring nên
nhận yêu cầu dựa vào cấu hình partitioner và replica placement strategy

14


2.5.1.

Hiểu về yêu cầu ghi

Cho tác vụ ghi, coordinator sẽ gửi cái này đến tất cả các node chứa row được
ghi. Miễn là tất cả các node chứa bản sao hoạt động và sẵn sàng, chúng sẽ nhận tác vụ
ghi bất kể thông số consistent level của client đặc tả gì đi chăng nữa. Consistent level
quyết định có bao nhiêu node bản sao phải phản hồi để xem như là tác vụ đó thành
công hay chưa.
Ví dụ, trong một cluster có 10 node như trên với replication_factor là 3 và tác
vụ ghi đến cả 3 node sở hữu dòng được yêu cầu. Nếu consistent level đặc tả là ONE thì
khi một node ghi xong sẽ phản hồi lại coordinator và coordinator sẽ phản hồi cho
client là thành công
2.5.2.

Hiểu về yêu cầu đọc
Có hai loại request đọc, một là request trực tiếp, hai là read repair request. Số

bản sao trong request trực tiếp được quyết đinh bởi consistent level đặc tả bởi client.

Read repair request được gửi cho những bản sao còn lại những cái mà không nhận
request trực tiếp. Read repair request đảm bảo rằng tất cả các dòng được request nhất
quán với nhau
Vì vậy coordinator sẽ tiếp xúc với bản sao đầu tiên đặc tả bởi consistent level.
15


Coordinator sẽ gửi những request này cho các bản sao. Dòng của mỗi bản sao sẽ được
so sánh trong bộ nhớ để xem xét sự nhất quán dữ liệu của chúng. Nếu chúng không
nhất quán thì dữ liệu của dòng nào gần nhất sẽ được coordinator chuyển lại cho client
sau.
Để đảm bảo rằng tất cả bản sao có phiên bản gần nhất của dữ liệu đọc thường
xuyên. Coordinatior cũng liên lạc và so sánh dữ liệu từ tất cả các bản sao còn lại và
nếu chúng không nhất quán thì việc ghi để update dòng để phản ánh giá trị viết gần
đây nhất. Process này được gọi là read repair. Nó được cấu hình theo cột và được
enable mặc định.
Ví dụ, trong một cluster với replication factor là 3 và consistency level là
QUORUM. Hai trong số ba bản sao của row sẽ tiếp xúc trọn vẹn với read request. Giả
sử những bản sao được tiếp xúc có những phiên bản khác nhau của row, bản sao với
phiên bản mới nhất sẽ được trả về cho client. Trong background, bản sao thứ ba được
kiểm tra tính nhất quán với hai cái đầu tiên và nếu cần, bản sao với phiên bản gần nhất
sẽ cập nhật bản sao thứ ba này.

16


Chương 3.

MÔ HÌNH DỮ LIỆU
CASSANDRA

Mô hình dữ liệu Cassandra là một mô hình động, hướng cột. Không giống với
RDBMS, bạn không cần phải mô hình tất cả các cột yêu cầu bởi ứng dụng của bạn.
Mỗi dòng không yêu cầu phải có cùng số cột. Cột và metadata của chúng có thể được
thêm vào bởi chương trình ứng dụng phía client.
3.1.

So sánh với RDBMS
Trong RDBMS, dữ liệu được lưu trữ trong bảng và những bảng trong một ứng

dụng có mối quan hệ với nhau. Dữ liệu thường được chuẩn hóa sao cho giảm dư thừa
dữ liệu
Xem xét một ví dụ đơn giản. Ứng dụng cho phép người dùng tạo một blog
entry. Trong ứng dụng này blog entries được phân loại bởi các mảng chủ đề (thể thao,
thời trang). Người dùng cũng có thể chọn để subscribe những blog của những người
dùng khác. Trong ví dụ này User ID là khóa chinh trong bảng Users và là khóa ngoại
trong bảng blog và bảng subscriber. Category ID là khóa chính trong bảng category và
là khóa ngoại trong bảng blog_entry. Dùng mô hình quan hệ này, Câu truy vấn SQL
có thể thực hiện kết trên nhiều bảng để trả lời cho những câu hỏi

17


Trong Cassandra. Keyspace là cái chứa đựng dữ liệu ứng dụng của bạn, tương
tự như database hay schema trong RDBMS. Bên trong keyspace là một hoặc nhiều
colum family, cái cũng được hiểu như là các bảng. Column family chứa các column và
một tập những cột có liên quan với nhau được định nghĩa bởi một row key. Mỗi row
trong một column family ko yêu cầu phải có cùng số cột
Cassandra không bắt buộc có mối quan hệ giữa các column family như cách mà
RDBMS làm giữa các bảng. Không có khóa ngoại trong Cassandra. Không hỗ trợ kết

các column family tại thời điểm truy vấn. Mỗi column family sẽ có một tập những cột
cho phép liên kết những bảng lại để lấy thông tin khi câu truy vấn được thực hiện
Cũng với ví dụ trên được thực hiện trong Cassandra. Bạn có một column family
dùng cho dữ liệu người dùng và blog_entry như bên RDBMS. Những column family
khác (làm nhiệm vụ như secondary index) được add thêm vào để hỗ trợ truy vấn được
thực hiện nhanh hơn. Ví dụ để trả lời cho câu truy vấn user nào subscribe blog của tôi
hay chỉ cho tôi những blog entry có chủ đề thời trang. Hay chỉ cho tôi entry gần nhất
của những blog mà tôi đã subscribe bạn cần thiết kế thêm những columm family để hỗ
trợ cho những câu truy vấn đó hoặc đánh secondary index lên những những thuộc tính
tìm kiếm (chỉ mới hỗ trợ gần đây)

18


3.2.

Keyspace
Trong cassandra keyspace để chứa đựng dữ liệu ứng dụng của bạn, tương tự

schema trong RDBMS. Keyspace dùng để nhóm những column family với nhau. Một
cluster có một keyspace cho một ứng dụng.
Replication để điều khiển … Trong ngôn ngữ DDL hỗ trợ trong CLI hay CQL.
Để định nghĩa một keyspace ta dùng như sau
CREATE KEYSPACE keyspace_name WITH
strategy_class = 'SimpleStrategy'
AND strategy_options:replication_factor=2;
19


Or in Cassandra CLI:

CREATE KEYSPACE keyspace_name WITH
placement_strategy = 'SimpleStrategy'
AND strategy_options = [{replication_factor:2}];
3.3.

Column family
Khi so sánh Cassandra với RDBMS, nó tương tự như bảng. Tuy nhiên chúng có

những đặc điểm khác nhau như sau. Trong RDBMS, bạn định nghĩa bảng cùng với cột
của nó (tên cột, kiểu dữ liệu cột) mọi thức đều phải fix trước. Trong Cassandra, bạn
định nghĩa column family. Column family có thể định nghĩa metadata của cột, nhưng
những cột thực tế cái tạo nên một dòng được quyết định bởi client. Mỗi row có thể có
số cột khác nhau
Mặc dù column family rất flexible, nhưng trong thực tế một column family
không phải hoàn toàn là schema-less. Mỗi column family nên được thiết kế để chứa
một kiểu dữ liệu đơn. Có 2 loại column family trong Cassandra là static và dynamic
Static column family dùng cho một tập tĩnh nhưng tên column có quan hệ với
nhau và có nhiều sự tương đồng với RDBMS. Ví dụ column family lưu trữ dữ liệu
người dùng có thể có những cột cho tên người dùng, address, email, phone, …Mặc
dầu dòng được khởi tạo có cùng một tập cột nhưng chúng không yêu cầu có tất cả
những cột được định nghĩa. Static column family điển hình cho loại có metadata của
cột định nghĩa trước

Dinamic column family thể hiện lợi ích của khả năng của Cassandra. Thay vì
việc định nghĩa metadata cho những cột đơn. Dynamic column family định nghĩa
thông tin cho tên cột và giá trị cột (comparator và validator). Nhưng tên cột và giá trị
của nó được set bởi ứng dụng khi cột được insert

20

Cho tất cả column family, mỗi dòng được định danh bởi row key tương tự như
khóa chính trong RDBMS. Column family phân tán dữ liệu dựa trên khóa chính của
nó và được đánh index một cách ngầm định
3.3.1.

Hiểu về column
Column là phần tử nhỏ nhất trong Cassandra. Nó chứa đựng 1 tên, 1 value và

một timestamp

Column phải có tên và tên là một nhãn tĩnh hoặc có thể set động bởi ứng dụng.
Cột có thể được index lên tên của nó. Mặc dầu vậy, có giới hạn trong việc index cột là
chúng không hỗ trợ câu truy vấn truy suất lên dữ liệu có thứ tự, như dữ liệu chuỗi thời
gian. Trong trường hợp này secondary index lên timestamp column sẽ không hiệu quả
bởi bạn không thể sắp thứ tự với secondary index. Trong trường hợp thứ tự sắp xếp là
quan trọng, thì phải bằng tay tạo ra những column family như là một index
Không yêu cầu phần value có giá trị. Thỉnh thoảng tất cả những thông tin bạn
cần để truy vấn nằm ở tên cột
Cassandra dùng timestamp để quyết định thời điểm update cột sau cùng. Nếu
một người dùng update lên cùng một cột đồng thời. Update gần nhất sẽ được sử dụng
3.3.2.

NHỮNG CỘT ĐẶC BIỆT

• Expriring Columnn
Một cột cũng có thời gian hết hạn của nó (TTL). Bất cứ khi nào một cột được
insert, yêu cầu người dùng có thể đặc tả một TTL (tính bằng giây). Những cột mà
có TTL bị quá hạn sẽ đánh dấu bị xóa.
21

Nếu bạn muốn thay đổi TTL của một cột nào đó, bạn phải insert lại cột đó với
một TTL mới. Trong Cassandra tác vụ insert hay update là một, phụ thuộc vào
version trước của cột đã hiện hữu hay chưa => việc update TTL cho một cột với
một giá trị chưa biết đòi hỏi bạn phải đọc lại cột và reinsert với new TTL
• Counter Column
Counter là một đặc tả của cột dùng để lưu trữ một số cái mà sẽ tăng khi một sự
kiện hay process xảy ra. Ví dụ bạn có thể dùng counter column để đếm số lần page
được xem
Counter column family phải dùng CounterColumnType như là validator (kiểu
của giá trị cột)
Điểm khác biệt của cái này với những cái khác là ứng dụng có thể update giá trị
cột bởi tăng hoặc giảm nó. Update thông qua tên cột, giá trị cột (ko có timestamp)
• Supper Column

Column family có thể chứa đựng hoặc là column thông thường hoặc là supper
column (mảng chứa chững super column nó bao gồm tên của super column và một
ánh xan thứ tự các sub-column). Một super column có thể đặc tả một comparator
lên cả super column name cũng như là sub-column name
Super column là cách để nhóm nhiều cột có mối quan hệ với nhau. Ví dụ của
việc sử dụng super column là giả sử bạn muốn tạo một. Thêm 1 ví dụ ở đây
Giới hạn của super column là tất cả sub-column cảu super column phải xếp theo
thứ tự. Bạn không thể tạo secondary index lên sub-column của super-column. Chỉ
nên dùng super column khi số sub-column là nhỏ
3.3.3.

Kiểu dữ liệu
Trong RDBMS, bạn phải đặc tả kiểu dữ liệu cho mỗi cột khi bạn định nghĩa

bảng, và kiểu dữ liệu sẽ rang buộc kiểu dữ liệu được insert vào đó. Tên cột trong
22


RDBMS là một nhãn cố đinh
Trong Cassandra kiểu dữ liệu của giá trị cột được gọi là validator. Kiểu dữ liệu
của tên cột được gọi là comparator. Bạn có thể định nghĩa kiểu dữ liệu khi bạn tạo
column family nhưng điều đó là hok bắt buộc. Mặc định Cassandra lưu trữ tên cột và
giá trị cột dưới dạng hex byte (BytesType)
Một số kiểu dữ kiệu được dùng cho cả 2 loại. Một ngoại lệ là Counter chỉ dùng
cho giá trị cột (không dùng cho tên cột)
3.4.
3.4.1.

Index trong Cassandra
Primary index
Trong Cassandra, primary index cho column family là index của row key. Mỗi

node sẽ bảo trì index này cho dữ liệu nó quản lý. Những row được thiết kế cho node
bởi việc cấu hình partitioner và cấu hình replica placement strategy. Primary index
trong Cassandra cho phép tìm kiếm dòng bởi khóa của nó. Khi mỗi node biết range
khóa mà mỗi node quản lý. Row được yêu cầu có thể cấp phát hiệu quả bằng cách
duyệt qua index dòng chỉ trên relevant relicas
Với randomly partitioner row keys (mặc định trong cassandra) row key được
phân bố bởi MD5 hash và không thể scanned thứ tự giống index B-tree truyền thống.
Sử dụng Ordered partitioner cho phép truy vấn một khoảng các row key. Nhưng không
khuyến khích sử dụng partitioner này bởi vì khó bảo trì việc phân tán dữ liệu thông
qua các node
3.4.2.

Secondary index
Secondary index trong Cassandra muốn nói đến index lên giá trị cột (để phân

biệt chúng với primary index)
Secondary index cho phép truy vấn hiệu quả bằng cách đặc tả những giá trị
dùng vị từ đẳng thức. Câu truy vấn lên giá trị index cũng có thế áp dụng các filter thêm
vào để tập kết quả cho nhữn giá trị khác
Secondary index tốt nhất trong trường hợp khi nhiều dòng chứa đựng giá trị
index. Nhiều giá trị unique tồn tại trong một cột riêng biệt. Nhiều overhead bạn sẽ có
để truy vấn và bảo trì index. Ví dụ bạn có một user table với một triệu người dùng và
23


muốn tìm những user dựa vào state đang sống. Nhiều người dùng sẽ chia sẻ cùng giá
trị cột cho state. Đây là một sự thay thế tốt cho một secondary index. Mặc khác nếu
bạn muốn tìm user theo email (giá trị unique cho mỗi user) => nhiều hiệu quả nếu xây
dựng một dynamic column family như là một index.
Lợi ích khác của secondary index là có thể dễ dàng thao tác và bảo trì index.
Khi bạn tạo secondary index lên cột hiện hữu, nó index dữ liệu ở background
Trong Cassandra CLI bạn có thể tạo một secondary index lên một cột khi định
nghĩa column family
[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}];

Or you can add an index to an existing column family:
[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}];

Bởi vì secondary index được tạo cho state nên giá trị của nó có thể được truy
vấn trực tiếp cho người dùng những người sống ở một state cho trước
[default@demo] get users where state = 'TX';

24


Chương 4.

4.1.

QUẢN LÝ VÀ TRUY XUẤT DỮ LIỆU
Hiểu về ghi trong Cassandra

Cassandra được tối ưu để việc ghi dữ liệu luôn có sự sẵn sàng cao và nhanh
chóng. RDBMS có cấu trúc dữ sao cho dữ liệu dư thừa là ít nhất. Nhiều mẩu thông tin
cần cho câu truy vấn được lưu trữ ở nhiều bảng có quan hệ với nhau. Bởi cái cách lưu
trữ dữ liệu như thế nên việc ghi dữ liệu tốn nhiều chi phí. Server database phải thực
hiện thêm nhiều tác vụ để đảm bảo toàn vẹn dữ liệu thông qua nhiều bảng quan hệ. Vì
vậy RDBMS thường có hiệu suất không cao trong viết
Cassandra viết lần đầu tiên vào commit log (đảm bảo durability). Và sau đó là
viết vào cấu trúc bảng trong bộ nhớ gọi là memtable. Tác vụ viết là thành công khi nó
viết vào commit log và vào memory. Vì vậy có rất ít tác vụ đĩa tại thời điểm đọc ghi
dữ liệu. Việc ghi được thực hiện định kì vào đĩa cho một cấu trúc bảng nhất quán gọi
là SSTable. Memtable và SSTable được bảo trì theo column family. Memtable được tổ
chức bằng việc sắp xếp theo row key và được đẩy xuống SSTable một cách tuần tự

SSTable là inmutable (không thay đổi). Chúng không được viết lại sau khi đã
flush. Có nghĩa rằng một row được lưu trữ thông qua nhiều file trong SSTable. Tại
thời điểm đọc, Một dòng phải được combine từ tất cả các SSTable trên đĩa để sinh ra
dữ liệu được yêu cầu. Để tối ưu process này Cassandra đãdùng một cấu trúc trong bộ
nhớ gọi là bloom filter. Mỗi SSTable có một bloom filter kết hợp với nó. Nó dùng để
25