Tìm hiểu về CSDL cassandra



TÌM HIỂU VỀ

CASSANDRA

THÁNG 6/2016


Mục Lục
1. Những đặc trưng của Cassandra.............................................................................................1
1.2 Phân tán và không tập trung hóa.......................................................................................1
1.3 Khả năng mở rộng mềm dẻo.............................................................................................1
1.4 Tính sẵn sàng cao và khả năng chịu lỗi............................................................................2
1.5 Tính nhất quán tùy chỉnh..................................................................................................2
1.6 Hướng cột – Column oriented...........................................................................................3
1.7 Schema – Free (không bị ràng buộc về lược đồ)..............................................................3
1.8 Hiệu năng cao....................................................................................................................4
2. Kiến trúc Cassandra................................................................................................................4
2.1 Kết nối giữa các nút (giao thức Gossip)............................................................................4
2.2 Các thành viên của cụm và các nút hạt giống...................................................................4
2.3 Trạng thái dò thất bại và sự phục hồi................................................................................5
2.4 Phân vùng dữ liệu trong Cassandra...................................................................................6
2.4.1 Giới thiệu về Phân vùng trong cụm Trung tâm đa dữ liệu.........................................7
2.4.2 Hiểu biết về các loại phân vùng.................................................................................8
2.5 Nhân bản trong Cassandra..............................................................................................10
2.6 Kiến trúc liên kết mạng...................................................................................................11
2.7 Snitches...........................................................................................................................13
2.8 Yêu cầu từ phía Client trong Cassandra..........................................................................15
2.8.1 Yêu cầu ghi..............................................................................................................16
2.8.2 Truy vấn đọc............................................................................................................17

3. Mô hình dữ liệu Cassandra...................................................................................................18
3.1 So sánh mô hình dữ liệu Cassandra với cơ sở dữ liệu quan hệ.......................................18
3.2 Keyspaces........................................................................................................................20
3.3 Column Families.............................................................................................................21
3.4 Columns..........................................................................................................................22
3.5 Các column đặc biệt (Counter, Expiring, Super)............................................................23
3.5.1 Expiring Columns....................................................................................................23
3.5.2 Counter Columns.....................................................................................................23
3.5.3 Super Columns.........................................................................................................24
3.6 Các kiểu dữ liệu (Comparators và Validators)................................................................25
3.6.1 Validators.................................................................................................................26
3.6.2 Comparators.............................................................................................................26
3.7 Nén column family..........................................................................................................26
3.7.1 Khi nào sử dụng nén................................................................................................27
3.7.2 Cấu hình nén cho một Column Family....................................................................27
3.8 Thiết kế mô hình dữ liệu.................................................................................................28
3.8.1 Dựa trên các truy vấn...............................................................................................28
3.8.2 Phi chuẩn hóa để tối ưu................................................................................................28
3.8.3 Lập kế hoạch cho việc ghi trùng lặp........................................................................29
3.8.4 Sử dụng các khóa dòng tự nhiên hoặc thay thế........................................................29
3.8.5 Các kiểu UUID cho tên cột......................................................................................29
KẾT LUẬN...............................................................................................................................30


1. Những đặc trưng của Cassandra
1.1 Khái niệm
"Apache Cassandra là một mã nguồn mở, phân tán, không tập trung hóa, khả
năng mở rộng cao, tính sẵn sàng cao, chịu lỗi, tính nhất quán, cơ sở dữ liệu hướng cột
dựa trên cơ sở thiết kế phân tán trên Dynamo của Amazon và mô hình dữ liệu của nó
trên Bigtable của Google. Được tạo ra bởi Facebook, nó được sử dụng phổ biến trong

một số website trên Internet".
1.2 Phân tán và không tập trung hóa
Cassandra là phân tán, có nghĩa là nó có khả năng chạy trên nhiều máy trong khi
xuất hiện trước người sử dụng như một thể thống nhất.
Thực tế Cassandra không tập trung hóa có nghĩa là không có điểm lỗi duy nhất
nào. Tất cả các nút trong một cluster Cassandra hoạt động như nhau. Điều này đôi
khigọi là “máy chủ đối xứng”. Bởi vì tất cả chúng đều làm những việc như nhau, và
không có một máy chủ đặc biệt được phối điều phối các hoạt động, như với mô hình
chủ /tớ trong MySQL, Bigtable, và những nhiều hệ cơ sở dữ liệu khác.
Do đó, đặc điểm không tập trung hóa có hai ưu điểm quan trọng: nó đơn giản
hơnsử dụng hơn mô hình chủ /tớ, và nó giúp bạn tránh việc hệ thống ngừng hoạt động.
Vì các node là giống nhau nên việc thao tác và duy trì lưu trữ không tập trung hóa dễ
dàng hơn so với mô hình chủ/tớ. Điều đó có nghĩa bạn không cần bất kỳ kiến thức đặc
biệt để mở rộng, thiết lập 50 nút không khác nhau nhiều lắm so với thiết lập một nút.
Hơn nữa, trong một thiết lập master/slave, master có thể trở thành một điểm lỗi duy
nhất (SPOF). Để tránh điều này, bạn thường cần phải tăng thêm tính phức tạp để môi
trường có nhiều master. Bởi vì tất cả các bản sao trong Cassandra đều đồng nhất, một
nút bị lỗi sẽ không làm gián đoạn dịch vụ. Theo một cách ngắn gọn hơn, bởi vì
Cassandra được phân phối và không tập trung, nó không có điểm lỗi duy nhất, và hỗ
trợ sẵn sàng cao.
1.3 Khả năng mở rộng mềm dẻo
Khả năng mở rộng là một tính năng kiến trúc của một hệ thống cho phép nó có
thể tiếp tục phục vụ số yêu cầu lớn hơn với hoạt động ít bị suy giảm. Mở rộng theo
chiều dọc - chỉ đơn giản thêm khả năng phần cứng và bộ nhớ máy tính hiện tại - là
cách dễ nhất để đạt được điều này. Mở rộng theo chiều ngang, có nghĩa là thêm nhiều
máy chứa tất cả hoặc một phần dữ liệu để không có máy nào phải chịu toàn bộ gánh
1


nặng của yêu cầu phục vụ. Nhưng sau đó phần mềm bản thân nó phải có một cơ chế

nội bộ để giữ dữ liệu của nó đồng bộ với các nút khác trong cluster.
Khả năng mở rộng mềm dẻo, đề cập đến một đặc tính đặc biệt của mở rộng theo
chiều ngang. Nó có nghĩa là cluster của bạn có thể mở rộng quy mô và giảm quy mô
xuống một cách liền mạch. Để làm điều này, các cụm phải có khả năng chấp nhận các
nút mới có thể bắt đầu tham gia bằng cách nhận được một bản sao của một số hoặc tất
cả dữ liệu và bắt đầu phục vụ yêu cầu người sử dụng mới mà không có sự gián đoạn
lớn hoặc cấu hình lại toàn bộ cluster.Bạn không cần phải khởi động lại quá trình của
bạn.Bạn không cần thay đổi các truy vấn ứng dụng của bạn. Bạn không phải tự cân
bằng lại các dữ liệu. Chỉ cần thêm một máy - Cassandra sẽ tìm thấy nó và làm nó hoạt
động. Mở rộng quy mô xuống, tất nhiên, có nghĩa là loại bỏ một số khả năng xử lý của
cluster. Bạn có thể phải làm điều này nếu bạn di chuyển một phần ứng dụng của bạn
sang nền tảng khác, hoặc nếu ứng dụng của bạn bị giảm số lượng người dùng và bạn
cần phải bắt đầu bán bớt phần cứng.Chúng ta hãy hy vọng điều đó không xảy
ra.Nhưng nếu có, bạn sẽ không cần phải phá vỡ toàn hệ thống để có quy mô nhỏ lại.
1.4 Tính sẵn sàng cao và khả năng chịu lỗi
Trong thuật ngữ kiến trúc nói chung, tính sẵn sàng của một hệ thống được đánh
giá dựa trên khả năng đáp ứng các yêu cầu của hệ thống đó. Nhưng máy tính có thể
mắc phải rất nhiều kiểu lỗi, từ lỗi phần cứng đến việc đứt mạng. Và đa số các máy tính
không thể tránh khỏi các loại lỗi này. Tất nhiên, có một số máy tính phức tạp có thẻ tự
mình làm giảm thiểu các lỗi này, vì chúng có nhiều phần cứng thay thế, và có khả
năng gửi thông báo về các sự kiện lỗi để tự chuyển đổi các thành phần phần cứng của
mình. Nhưng bất cứ ai có thể vô tình làm hỏng một cáp Ethernet, và nó sẽ cô lập một
trung tâm dữ liệu duy nhất. Vì vậy, để một hệ thống được đánh giá là có tính sẵn sàng
cao, nó thường phải bao gồm nhiều máy tính nối mạng,và phần mềm mà họ đang chạy
phải có khả năng điều hành trong một cluster và có một vài cơ chế nhận diện lỗi ở các
node thông qua yêu cầu tới các phần khác của hệ thống. Cassandra có tính sẵn sàng
cao. Bạn có thể thay thế các nút lỗi trong cluster mà không gây ra thời gian chết, và
bạn có thể sao chép dữ liệu đến nhiều trung tâm dữ liệu cung cấp cải thiện hiệu năng
và giảm thời gian dừng nếu một trung tâm dữ liệu phải đối mặt với một thảm họa như
hỏa hoạn hoặc lũ lụt.

1.5 Tính nhất quán tùy chỉnh
2


Tính nhất quán cơ bản có nghĩa là thao tác đọc luôn được trả về giá trị bản ghi
mới nhất. Hãy xem xét việc hai khách hàng đang cố gắng để đặt cùng một mặt hàng
vào giỏhàng của họ trên một trang web thương mại điện tử. Nếu tôi đặt mặt hàng cuối
cùng trong kho vào giỏ hàng của tôi ngay lập tức sau khi bạn làm việc đó, bạn sẽ nhận
có hàng được thêm vào giỏ hàng của bạn, và tôi cần phải được thông báo rằng mặt
hàng này đã hết. Điều này được đảm bảo để xảy ra khi trạng thái của thao tác ghi là
nhất quán giữa tất cả các nút có dữ liệu đó.
Tuy nhiên, việc mở rộng quy mô lưu trữ dữ liệu nghĩa là chúng ta phải đánh đổi
giữa tính nhất quán, tính sẵn sàng và khả năng chịu lỗi (chúng ta chỉ có thể lựa chọn 2
trong 3 đặc điểm này). Và Cassandra đã ưu tiên tính sẵn sàng hơn là tính nhất quán. Vì
thế, Cassandra có đặc điểm là “tùy chỉnh tính nhất quán”, tức là nó cho phép người
dùng điều chỉnh mức độ nhất quán theo yêu cầu, trong sự cân nhắc với mức độ sẵn
sàng. Mức độ nhất quán là một thiết lập mà client phải chỉ ra trên mỗi thao tác và cho
phép bạn quyết định bao nhiên bản sao trong cluster phải nhận biết thao tác ghi hay
đáp ứng lại thao tác đọc để được xem là thành công.
1.6 Hướng cột – Column oriented
Nó không có quan hệ, và nó thể hiện cấu trúc dữ liệu của mình trong những
hashtable đa chiều rải rác. Rải rác nghĩa là với một dòng bất kỳ, bạn có thể có một
hoặc nhiều cột, nhưng mỗi dòng không cần phải có tất cả các cột giống nhau như trong
cơ sở dữ liệu quan hệ. Mỗi dòng có một khóa riêng làm cho dữ liệu của nó có thể truy
cập được. Cassandra lưu trữ dữ liệu trong bảng băm đa chiều nên bạn có thể không cần
phải quyết định trước cấu trúc dữ liệu của mình nên như thế nào, hoặc các bản ghi cần
những trường gì… Điều này rất có lợi nếu bạn vừa mới bắt đầu phát triển ứng dụng,
việc thêm vào hoặc loại bỏ các chức năng là khá thường xuyên. Tuy nhiên, điều này
không có nghĩa là bạn hoàn toàn không phải suy nghĩ gì về cấu trúc dữ liệu. Cassandra
khiến bạn có suy nghĩ khác đi về nó. Thay vì thiết kế một mô hình dữ liệu ban đầu và

sau đó thiết kế các truy vấn xung quanh mô hình đó như trong hệ cơ sở dữ liệu quan
hệ, bạn có thể tự do nghĩ về các truy vấn trước, và sau đó cung cấp dữ liệu để trả lời
những truy vấn đó.
1.7 Schema – Free (không bị ràng buộc về lược đồ)
Cassandra yêu cầu bạn định nghĩa một container gọi là keyspace chứa các
column family. Keyspace thực chất chỉ là một namespace logic để giữ các column
3


family và thuộc tính cầu hình cụ thể. Ngoài ra, các bảng dữ liệu rải rác bên bạn có thể
chỉ cần đưa dữ liệu vào đó, sử dụng cột mình muốn, và không cần phải định nghĩa
trước các cột. Thay vì mô hình hóa dữ liệu bằng các công cụ mô hình hóa đắt tiền, và
viết những câu truy vấnphức tạp, Cassandra cho phép bạn mô hình hóa các truy vấn
mình cần, và sau đó cung cấp dữ liệu cho nó.
1.8 Hiệu năng cao
Cassandra được thiết kế nhằm mục đích tận dụng được ưu điểm của các máy đa
xử lý/ đa lõi, và để chạy trên nhiều nhiều máy ở nhiều trung tâm dữ liệu với khối
lượng dữ liệu khổng lồ. Cassandra có thể hoạt động tốt thậm chí dưới tải công việc
cao. Thao tác ghi trong Cassandra cũng được thực hiện rất nhanh chóng. Khi bạn thêm
nhiều server, bạn có thể duy trì tất cả đặc tính mong muốn của Cassandra mà không
phải hy sinh hiệu năng hoạt động.
2. Kiến trúc Cassandra
Cassandra được thể hiện là một tập hợp của các nút độc lập được cấu hình lại với
nhau thành một cụm (Cluster).Trong một cụm, tất cả các nút là ngang hàng, có nghĩa
là không có nút chính hoặc nút trung tâm quản lý các tiến trình. Một nút có thể tham
gia một cụm Cassandra dựa trên các khía cạnh nhất định trong cấu hình của nó. Phần
này giải thích những khía cạnh của kiến trúc cụm Cassandra.
2.1 Kết nối giữa các nút (giao thức Gossip)
Cassandra sử dụng một giao thức gọi là tin đồn (Gossip) để khám phá vị trí và
thông tin trạng thái về các nút khác tham gia trong một cụm Cassandra. Gossip là một

giao thức truyền thông ngang hàng, trong đó các nút định kỳ trao đổi thông tin trạng
thái về bản thân và về các nút khác mà chúng biết.
Trong Cassandra, quá trình Gossip chạy mỗi giây và mỗi nút trao đổi các thông
báo trạng thái của nó tối đa với 3 nút khác trong cluster. Các nút thông tin trao đổi về
bản thân và về các nút khác mà họ nó đã được biết, do đó, tất cả các nút nhanh chóng
tìm hiểu về tất cả các nút khác trong cụm (cluster). Một Gossip có một phiên bản liên
kết với nó, do đó trong quá trình trao đổi tin đồn, với mỗi nút cụ thể thông tin cũ hơn
bị ghi đè bằng các trạng thái hiện tại cập nhật của nó.
2.2 Các thành viên của cụm và các nút hạt giống
Khi một nút bắt đầu, nó nhìn vào tập tin cấu hình của nó để xác định tên của cụm
assandra chứa nó và nút được gọi là hạt giống để liên hệ, có được thông tin về các nút
4


khác trong cluster. điểm liên lạc của các cụm được cấu hình trong file cassandra.yaml
cho mỗi nút.
Để ngăn chặn sự đứt đoạn trong truyền thông tin đồn (gossip), tất cả các nút
trong cluster phải có cùng một danh sách các nút hạt giống được liệt kê trong tập tin
cấu hình của nó. Điều này là quan trọng nhất khi một nút khởi động. Theo mặc định,
một nút sẽ nhớ các nút khác, nó đã có giao tiếp kể cả khi khởi động lại.
Chú ý: Các nút hạt giống được thiết kế không có mục đích nào khác hơn khởi
động quá trình loan tin đồn cho các nút mới gia nhập nhóm.
2.3 Trạng thái dò thất bại và sự phục hồi
Dò thất bại là thông qua trạng thái của tin đồn (gossip), từ 1 nút xác định xem các
nút khác trong hệ thống đang online hay offline. Thông tin dò thất bại cũng được sử
dụng trong Cassandra để tránh định tuyến các yêu cầu từ máy khách đến các nút không
thể truy cập được. (Cassandra cũng có thể tránh được các yêu cầu định tuyến các nút
còn sống,nhưng hoạt động kém, qua dynamic snitch).
Trong quá trình truyền tải các bản tin từ các nút khác cả trực tiếp (các nút giao
tiếp trực tiếp đến nó) và gián tiếp (thông tin có được khi nghe qua 2 nút, 3 nút …),

Cassandra sử dụng một cơ chế tính toán một ngưỡng cho mỗi nút dựa vào điều kiện
mạng, khối lượng công việc, hoặc các điều kiện khác mà có thể ảnh hưởng đến quá
trình truyền tải. Trong quá trình trao đổi tin đồn, mỗi nút duy trì một cửa sổ trượt báo
các thông báo tin đồn từ các nút khác trong cluster. Trong Cassandra, cấu hình
phi_convict_threshold điều chỉnh độ nhạy cho việc dò thất bại. Các giá trị mặc định là
fine cho hầu hết các tình huống, nhưng DataStax đề nghị tăng đến 12 cho Amazon
EC2 do tắc nghẽn mạng thường xuyên xảy ra trên nền tảng đó.
Node có thể thất bại do nhiều nguyên nhân khác nhau như thất bại phần cứng,
mất mạng… Để chính thức thay đổi nút thành viên trong một cluster, các quản trị viên
sử dụng tiện ích nodetKhi một node trở lại trực tuyến sau khi không hoạt động, nó có
thể đã bỏ lỡ việc sao chép các dữ liệu mà nó duy trì. Một khi quá trình dò thất bại đánh
dấu một nút là offline, nếu như hinted handoff được kích hoạt thì quá trình ghi nhớ
được thực hiện bởi các bản sao khác. Tuy nhiên, nó có thể xảy ra tình huống việc ghi
bị bỏ lỡ giữa khoảng thời gian của một nút thực sự offline cho tới khi nó bị phát hiện
là offline. Hoặc nếu một nút không hoạt động lâu hơn max_hint_window_in_ms (mặc
định là một giờ), gợi ý sẽ không còn được lưu lại. Vì lý do đó, tốt nhất là thường
5


xuyên chạy nodetool sửa chữa tất cả các nút để đảm bảo chúng toàn vẹn dữ liệu, và
cũng chạy repair sau khi hồi phục một nút đã offline trong một thời gian dài.ool để
thêm hoặc loại bỏ các nút trong một cụm Cassandra.
2.4 Phân vùng dữ liệu trong Cassandra
Khi khởi động một cụm Cassandra, phải chọn cách thức dữ liệu sẽ được chia trên
các nút trong cluster. Điều này thực hiện bằng cách chọn một phân vùng cho cluster.
Trong Cassandra, tổng số dữ liệu được quản lý bởi 1 cụm được đại diện như là
một không gian hoặc vòng tròn. Vòng tròn được chia tương ứng với phạm vi và số
lượng các nút, mỗi nút chịu trách nhiệm cho một hoặc nhiều vùng của toàn bộ dữ liệu.
Trước khi một nút có thể tham gia vòng, nó phải được gán một thẻ bài. Thẻ bài xác
định vị trí của nút trên vòng tròn và phạm vi của dữ liệu nó chịu trách nhiệm. Các cột

dữ liệu được phân chia qua các nút dựa trên khóa hàng. Để xác định các nút bản sao
đầu tiên của một dòng còn sống, vòng tròn được quay theo chiều kim đồng hồ cho đến
khi nó định vị các nút với một giá trị thẻ lớn hơn giá trị khóa hàng. Mỗi nút có trách
nhiệm đối với 1 khu vực xác định trong vòng tròn giữa bản thân và nút chịu trách
nhiệm ở khu vực liền kề nó.Với các nút được sắp xếp theo thứ tự thẻ bài, nút cuối
cùng được coi là tiền thân của nút đầu tiên.
Ví dụ, hãy xem xét một cụm đơn giản gồm 4 nút, nơi tất cả các dữ liệu được
quản lý bởi 1 cụm được đánh số trong khoảng từ 0 đến 100. Mỗi nút được gán một thẻ
bài đại diện cho một điểm trong phạm vi này. Trong ví dụ đơn giản này, các thẻ có giá
trị là 0,25, 50, và 75. Nút đầu tiên, với token 0, chịu trách nhiệm về phạm vi gói (750). Nút với thẻ bài thấp nhất cũng chấp nhận khóa hàng ít hơn so với các mã thẻ bài
thấp nhất và nhiều hơn với các mã thẻ bài cao nhất.

6


2.4.1 Giới thiệu về Phân vùng trong cụm Trung tâm đa dữ liệu
Trong triển khai trung tâm đa dữ liệu, vị trí bản sao được tính cho mỗi trung tâm
dữ liệu dựa vào chính sách NetworkTopologyStrategy. Trong mỗi trung tâm dữ liệu
(hoặc nhóm nhân bản), bản sao đầu tiên cho một hàng cụ thể được xác định bởi giá trị
thẻ bài gán cho một nút. Các bản sao trong cùng một trung tâm dữ liệu được xác định
bằng việc dịch chuyển vòng theo chiều kim đồng hồ cho đến khi nó tìm được nút đầu
tiên trong bánh răng (rack) khác. Nếu bạn không tính toán thẻ phân vùng để đảm bảo
dữ liệu được phân bố đều cho mỗi trung tâm dữ liệu, bạn có thể gặp phải tình trạng
phân phối dữ liệu không đồng đều trong mỗi trung tâm dữ liệu.

Mục đích là để đảm bảo rằng các nút tại mỗi trung tâm dữ liệu đều được phân
chia thẻ bài trên phạm vi tổng thể. Nếu không, bạn có thể gặp tình trạng các nút trong
mỗi trung tâm dữ liệu sở hữu một số lượng không cân xứng các khóa hàng. Mỗi trung
tâm dữ liệu phải được phân chia một cách độc lập, tuy nhiên việc gán thẻ bài trong
phạm vi 1 cụm không được xung đột với nhau (mỗi node phải có một thẻ duy nhất).

Xem Calculating Tokens for a Multi-Data Center Cluster cho các chiến lược về việc
làm thế nào để sinh các thẻ cho các cụm trung tâm đa dữ liệu.

7


2.4.2 Hiểu biết về các loại phân vùng
Không giống như hầu hết các lựa chọn cấu hình khác trong Cassandra, phân
vùng chỉ có thể thay đổi được khi tải lại tất cả các dữ liệu. Bởi vậy cần lựa chọn và cấu
hình phân vùng chính xác trước khi khởi tạo cluster. Cassandra cung cấp một số phân
vùng out-of-the-box, nhưng các phân vùng ngẫu nhiên là sự lựa chọn tốt nhất khi triển
khai Cassandra. Phân vùng ngẫu nhiên RandomPartitioner là phân vùng đã mặc định
cho một cụm Cassandra, và trong hầu hết các trường hợp là sự lựa chọn đúng. Việc
phân vùng ngẫu nhiên sử dụng hàm băm phù hợp để xác định xem nút nào sẽ lưu trữ
hàng nào. Không giống như việc sử dụng modulus-by-node-count, hàm băm phù hợp
đảm bảo rằng khi các nút được thêm vào cluster, số lượng dữ liệu bị ảnh hưởng là ít
nhất. Để phân phối các dữ liệu đều qua các nút, một thuật toán băm tạo ra một giá trị
MD5 hash của khóa hàng. Phạm vi có thể của giá trị băm là từ 0 đến 2 ** 127. Mỗi nút
trong cụm được gán một thẻ bài đại diện một giá trị hash trong phạm vi này. Một nút
sau đó sở hữu các hàng với một giá trị hash ít hơn số thẻ bài của nó. Đối với việc triển
khai trung tâm dữ liệu đơn lẻ, các thẻ bài được tính bằng cách chia phạm vi băm bởi số
lượng các nút trong cluster. Đối với việc triển khai nhiều trung tâm dữ liệu, thẻ được

8


tính cho mỗi trung tâm dữ liệu (khoảng băm nên được chia đều cho các nút trong mỗi
nhóm nhân bản).
Lợi ích chính của phương pháp này là một khi thẻ của bạn được đặt phù hợp, dữ
liệu từ tất cả các cột được phân bố đều trên toàn cụm mà không tốn nhiều thời gian xử

lý. Ví dụ, một cột có thể được sử dụng tên người dùng như là khóa hàng và một nhãn
thời gian cột, các khóa hàng từ mỗi cột riêng lẻ vẫn luân chuyển đồng đều. Điều này
có nghĩa là đọc và viết các yêu cầu của cluster cũng sẽ được phân bố đều. Một lợi ích
của việc sử dụng phân vùng ngẫu nhiên là đơn giản hóa việc cân bằng tải tại mỗi cụm.
Bởi vì mỗi một phần trong phạm vi băm sẽ nhận được một số lượng trung bình cộng
các hàng, nó làm cho việc gán thẻ bài cho các nút mới được dễ dàng hơn. Phân vùng
theo thứ tự Việc phân vùng theo thứ tự đảm bảo rằng các khóa hàng được lưu trữ theo
thứ tự sắp xếp. DataStax khuyến cáo bạn lựa chọn cách phân vùng ngẫu nhiên trên một
phân vùng trừ khi ứng dụng của bạn thực sự cần cách phân vùng khác.
Sử dụng một phân vùng đã được sắp xếp cho phép quét số lượng hàng lớn, có
nghĩa là bạn có thể quét các hàng như thể bạn đang di chuyển con trỏ thông qua một
chỉ số truyền thống. Ví dụ, nếu ứng dụng của bạn có tên người sử dụng như là khóa
hàng, bạn có thể quét hàng cho người sử dụng có tên ở giữa Jake và Joe. Đây là loại
truy vấn sẽ không thực hiện được với các phân vùng có khóa hàng ngẫu nhiên, vì các
khóa được lưu trữ trong thứ tự của bảng băm MD5 của nó (không phải theo tuần tự).
Phân vùng theo thứ tự không được khuyến khích vì những lý do sau: Việc tuần tự ghi
dữ liệu có thể gây ra điểm nóng. Nếu ứng dụng của bạn có xu hướng ghi hoặc cập nhật
một khối liên tục các hàng tại một thời điểm mà việc viết không được phân phối trên
cluster, đều thực hiện trên một nút. Điều này thường xuyên là một vấn đề với các ứng
dụng xử lý dữ liệu nhãn thời gian.
Cần phí quản lý cao để cân bằng tải trong cluster. Một phân vùng theo thứ tự yêu
cầu quản trị viên tự tính toán phạm vi thẻ bài dựa trên các ước tính của họ về phân
phối khóa hàng. Trong thực tế, điều này đòi hỏi các nút tích cực di chuyển thẻ bài để
thích ứng với phân phối thực tế của dữ liệu khi nó được tải.
Cân bằng tải không đồng đều giữa các cột liên quan. Nếu ứng dụng của bạn có
nhiều cột, rất có thể là những cột có khóa hàng khác nhau và phân phối dữ liệu khác
nhau. Một phân vùng theo thứ tự có thể dẫn đến phân phối không đồng đều cho các
cột trong cùng một cụm. Với Cassandra, có ba sự lựa chọn trong việc xây dựng phân
9

vùng theo thứ tự: ByteOrderedPartitioner – khóa hàng được lưu trữ theo thứ tự các raw
byte thay vì chuyển đổi chúng sang các chuỗi mã hóa. Tokens được tính bằng cách
nhìn vào các giá trị thực tế của dữ liệu, sử dụng hệ thập lục phân cho các ký tự đầu
trong khóa. Ví dụ, nếu bạn muốn hàng phân vùng theo thứ tự bảng chữ cái, bạn có thể
chỉ định thẻ A bằng cách sử dụng hệ thập lục phân đại diện là 41.
OrderPreservingPartitioner – khóa hàng được lưu trữ theo thứ tự dựa trên mã UTF-8.
Yêu cầu khóa hàng phải mã hóa theo UTF-8.
CollatingOrderPreservingPartitioner – khóa hàng được lưu trữ theo thứ tự dựa
trên tiếng Anh Mỹ. Cũng yêu cầu các khóa hàng phải mã hóa theo UTF-8
2.5 Nhân bản trong Cassandra.
Nhân bản là quá trình lưu trữ các bản sao của dữ liệu trên nhiều nút để đảm bảo
độ tin cậy và khả năng chịu lỗi. Khi bạn tạo một keyspace (không gian khóa) trong
Cassandra, bạn phải có chính sách quyết định vị trí các bản sao: số lượng bản sao và
cách những bản sao được phân phối trên các nút trong cluster. Chiến lược nhân bản
dựa trên cấu hình của cụm để giúp xác định vị trí vật lý của các nút và khoảng cách
giữa chúng. Tổng số bản sao trên cluster thường được gọi là nhân tố nhân bản. Một
nhân tố nhân bản của 1 có nghĩa là chỉ có một bản sao của mỗi hàng. Một nhân tố nhân
bản của 2 có nghĩa là có hai bản sao cho mỗi hàng. Tất cả các bản sao được quan trọng
như nhau, không có bản sao nào được coi là chính, phụ về cách đọc và ghi khi xử lý
các request Như một quy luật chung, các nhân tố nhân bản không được vượt quá số
lượng các nút trong cluster. Tuy nhiên, có thể để tăng nhân tố nhân bản, và sau đó
thêm số lượng mong muốn của các nút sau đó. Khi nhân tố nhân bản vượt quá số
lượng các nút, lệnh ghi sẽ bị từ chối, nhưng lệnh đọc sẽ được phục vụ miễn là đáp ứng
được mức độ nhất quán (consistency level).
Chiến lược xác định vị trí nhân bản. Replica placement strategy (chiến lược xác
định vị trí bản sao) cách thức phân phối không gian khóa giữa các bản sao trên cluster.
chiến lược xác định vị trí bản sao được thiết lập khi bạn tạo một keyspace. Có một số
chiến lược để lựa chọn dựa trên mục tiêu của bạn và các thông tin bạn có về vị trí các
nút.

Chiến lược đơn giản SimpleStrategy là cách mặc định khi tạo một keyspace bằng
cách sử dụng Cassandra CLI. Công cụ khác, chẳng hạn như CQL, yêu cầu bạn phải
xác định rõ ràng một chiến lược. SimpleStrategy đặt bản sao đầu tiên trên một nút
10


được xác định bằng partitioner (cách phân vùng). Bản sao bổ sung được đặt trên các
nút tiếp theo trong vòng theo chiều kim đồng hồ mà không xem xét vị trí các nút hoặc
vị trí trung tâm dữ liệu.

2.6 Kiến trúc liên kết mạng
NetworkTopologyStrategy là chiến lược nhân bản được ưa thích khi bạn có
thông tin về cách thức các nút được nhóm lại trong trung tâm dữ liệu của bạn, hoặc
bạn có (hoặc kế hoạch có) cluster triển khai trên nhiều trung tâm dữ liệu. Chiến lược
này cho phép bạn xác định có bao nhiêu bản sao bạn muốn trong mỗi trung tâm dữ
liệu.
Khi quyết định có bao nhiêu bản sao để cấu hình trong mỗi trung tâm dữ liệu,
xem xét chính là (1) đảm bảo dữ liệu được đọc tốt tại mỗi trung tâm dữ liệu, không có
trễ, và (2) kịch bản khi thất bại.
Hai cách phổ biến nhất để cấu hình các cụm trong nhiều trung tâm dữ liệu là: 
Tạo hai bản sao trong mỗi trung tâm dữ liệu. Cấu hình này đảm bảo khi 1 nút đơn lẻ
trong 1 nhóm nhân bản bị lỗi vẫn cho phép đọc được dữ liệu (ở một mức độ nhất quán
ONE).
 Tạo ba bản sao trong mỗi trung tâm dữ liệu. Cấu hình này sử dụng phục vụ
các nhu cầu truy cập thời gian thực.
Trong Cassandra khái niệm trung tâm dữ liệu và nhóm nhân bản là tương tự
nhau, nhóm nhân bản là nhóm các nút được cấu hình lại với nhau phục vụ cho việc
nhân bản.
11

Với NetworkTopologyStrategy, vị trí bản sao được xác định độc lập trong mỗi
trung tâm dữ liệu (hoặc nhóm nhân bản). Bản sao đầu tiên tại mỗi trung tâm dữ liệu
được đặt theo các phân vùng (giống như với SimpleStrategy). Bản sao sau đó trong
cùng một trung tâm dữ liệu được xác định bằng cách tiến theo chiều kim đồng hồ cho
đến khi một nút ở 1 rack khác từ nhân bản trước đó được tìm thấy. Nếu không có nút
như vậy, bản sao bổ sung sẽ được đặt trong cùng một rack. NetworkTopologyStrategy
ưu tiên đặt các bản sao lên các rack riêng biệt nếu có thể. Các nút trong cùng một rack
(hoặc tương đương nhóm vật lý) có thể dễ dàng lỗi cùng 1 thời gian do nguồn, lỗi phần
cứng hoặc các vấn đề mạng.
Dưới đây là một ví dụ về cách NetworkTopologyStrategy đặt bản sao giữa hai
trung tâm dữ liệu với 4 nhân tố nhân bản (hai bản sao ở Trung tâm dữ liệu 1 và hai bản
sao trong Trung tâm dữ liệu 2):

12


2.7 Snitches
Snitch là một thành phần cấu hình của một cụm Cassandra được sử dụng để xác
định các nút được nhóm lại với nhau như thế nào trong cấu trúc liên kết mạng tổng thể
(rack và các nhóm trung tâm dữ liệu). Cassandra sử dụng thông tin này để định tuyến
các yêu cầu từ 1 nút một cách hiệu quả nhất có thể. Snitch không ảnh hưởng đến các
yêu cầu giữa các ứng dụng của khách hàng và Cassandra (Nó không kiểm soát client
đang kết nối đến nút nào).
Snitches được cấu hình cho một cụm Cassandra trong file cấu hình
cassandra.yaml. Tất cả các nút trong một cluster nên sử dụng cùng một cấu hình
snitch. Khi gán thẻ bài, gán chúng luân phiên (so le) cho các Rack, ví dụ: rack1, rack2,
rack3, rack1, rack2, rack3...

13

Các dạng Snitch
SimpleSnitch (Snitch đơn giản)
SimpleSnitch (mặc định) là thích hợp nếu bạn không có thông tin về rack hoặc
trung tâm thông tin dữ liệu có sẵn. Triển khai trung tâm dữ liệu duy nhất (hoặc một
vùng trong đám mây công cộng) thường rơi vào loại này. Nếu sử dụng snitch, dùng
replication_factor = <#> khi xác định phạm vi khóa của bạn. Snitch này không xác
định được thông tin về trung tâm dữ liệu hoặc rack.
DseSimpleSnitch
DseSimpleSnitch được sử dụng khi triển khai DataStax Enterprise (DSE). Nó
phù hợp với cấu hình Hadoop điều phối phân tích dữ liệu và các ứng dụng thời gian
thực. Nó có thể được sử dụng cho các cụm DSE hỗn hợp nằm trong một trung tâm dữ
liệu vật lý.
Nó cũng có thể được sử dụng cho cụm DSE đa dữ liệu có chính xác 2 trung tâm
dữ liệu, với tất cả các nút phân tích trong cùng một trung tâm dữ liệu và tất cả các nút
Cassandra thời gian thực trong một trung tâm dữ liệu còn lại. Nếu sử dụng snitch, sử
dụng Analytics hoặc Cassandra là tên trung tâm dữ liệu mặc định khi định nghĩa
khoảng không gian khóa.
RackInferringSnitch
RackInferringSnitch xác đinh cấu trúc liên kết của mạng bằng cách phân tích địa
chỉ IP của các nút. Snitch này giả định rằng các octet thứ hai xác định các trung tâm dữ
liệu chứa nút đó, và các octet thứ ba xác định các rack.
14


PropertyFileSnitch
PropertyFileSnitch xác định vị trí của các nút bằng cách sử dụng định nghĩa của
người dùng trong file: cassandra-topology.properties. Snitch này là tốt nhất khi IP của
các nút là không thống nhất hoặc bạn có yêu cầu nhân bản phức tạp. Xem Cấu hình

PropertyFileSnitch để biết thêm thông tin. Dùng Snitch này bạn có thể đặt tên trung
tâm dữ liệu của mình theo tên mong muốn được định nghĩa trong flie: cassandratopology.properties.
EC2Snitch
EC2Snitch dùng cho triển khai các cụm trên Amazon EC2, nơi mà tất cả các
cluster dàn trải trên nhiều vùng. Thay vì sử dụng địa chỉ IP của nút để suy ra vị trí nút,
Snitch này sử dụng API AWS để yêu cầu khu vực và phạm vi còn trống cho 1 nút.
Khu vực này được coi là trung tâm dữ liệu và các phạm vi còn trống chính là các rack
trong trung tâm dữ liệu. Ví dụ, nếu một nút ở trung tâm dữ liệu có tên us-east-1a, useast thì vị trí rack là 1a.
Dynamic Snitching (Snitching động)
Theo mặc định, tất cả snitches cũng sử dụng một lớp snitch động giám sát độ trễ
khi đọc, định tuyến các yêu từ client tránh xa các nút hiệu năng thấp. Snithc động được
kích hoạt theo mặc định, và được khuyến khích sử dụng trong tất cả các phạm vi.
Snitching động được cấu hình trong file cassandra.yaml cho mỗi nút.
2.8 Yêu cầu từ phía Client trong Cassandra
Các nút trong Cassandra là ngang hàng. 1 client đọc hay viết các yêu cầu có thể
làm việc với bất kỳ nút nào trong cụm. Khi một client kết nối đến một nút và đưa ra
các yêu cầu đọc hoặc viết, nút đóng vai trò là điều phối viên cho các hoạt động đó.
Điều phối viên hoạt động như một proxy giữa các ứng dụng khách hàng và các
nút (hoặc bản sao) chứa các dữ liệu được yêu cầu. Điều phối viên xác định nút nào

15


trong vòng sẽ nhận được các yêu cầu dựa trên cấu hình phân vùng cụm và chiến lược
đặt vị trí bản sao.
2.8.1 Yêu cầu ghi
Để ghi dữ liệu, điều phối viên gửi yêu cầu ghi cho tất cả các bản sao sở hữu hàng
đang được ghi. Miễn là tất cả các nút sao đang hoạt động và rảnh, chúng sẽ ghi dựa
vào consistency level trong yêu cầu của client. Mức độ nhất quán ghi xác định có bao
nhiêu nút nhân bản phải đáp ứng yêu cầu thì việc ghi mới được coi là thành công.

Ví dụ, trong một trung tâm dữ liệu của 1 cụm có 10 nút với nhân tố nhân bản là
3, yêu cầu ghi sẽ đi đến tất cả 3 nút sở hữu hàng yêu cầu. Nếu mức độ thống nhất ghi
theo quy định của cliet là ONE, nút đầu tiên hoàn tất việc ghi sẽ báo về cho điều phối
viên, sau điều phối viên sẽ nhắn tin thành công lại cho client. Một mức độ nhất quán
ONE có nghĩa rằng nó có thể có 2 trong 3 bản sao có thể bỏ lỡ việc ghi nếu chúng
đang down tại thời điểm yêu cầu được đưa ra. Nếu 1 bản sao bỏ việc ghi, hàng dữa
liệu đó sẽ được thực hiện phù hợp sau đó thông qua một cơ chế tự sửa lỗi của
Cassandra.

Truy vấn ghi tới trung tâm đa dữ liệu
Trong sự triển khai trung tâm đa dữ liệu, Cassandra tối ưu hiệu năng ghi bằng
việc chọn một nút điều phối trong mỗi trung tâm dữ liệu từ xa để xử lý những truy vấn
tới các bản sao trong trung tâm dữ liệu. Nút điều phối được liên hệ bởi ứng dụng
Client chỉ yêu cầu chuyển tiếp truy vấn ghi tới mỗi nút trong trung tâm dữ liệu từ xa.
Nếu sử dụng mức độ nhất quán là 1 hoặc LOCAL_QUORUM, thì chỉ những nút trong
cùng trung tâm dữ liệu với nút điều phối phải phản hồi lại truy vấn của Client là truy
16


vấn thành công. Theo cách này thì vị trí địa lý không ảnh hưởng tới thời gian phản hồi
truy vấn Client.

2.8.2 Truy vấn đọc
Đối với truy vấn đọc, có hai loại truy vấn đọc mà điều phối có thể gửi tới một
bản sao; một truy vấn đọc trực tiếp và một truy vấn sửa đọc nền. Số lượng bản sao
được liên hệ bởi một truy vấn đọc trực tiêp được xác định bởi mức độ nhất quán được
đưa ra bởi Client. Truy vấn sửa đọc nền được gửi tới bất cứ bản sao bổ sung nào mà
không nhận truy vấn trực tiếp. Truy vấn sửa đọc đảm bảo rằng hàng được truy vấn
được thực hiện nhất quán ở tất cả các bản ghi.
Do đó, trước tiên nút điều phối lên hệ với các bản sao được chỉ định bởi mức độ

nhất quán. Nút điều phối sẽ gửi những truy vấn tới bản sao mà đang phản hồi nhanh
chóng nhất. Những nút được liên hệ sẽ phản hồi với dữ liệu đã truy vấn; nếu nhiều nút
được liên hệ, thì các hàng ở mỗi bản sao được so sánh trong bộ nhớ để xem liệu chúng
có nhất quán. Nếu chúng không nhất quán, thì bản sao có dữ liệu gần dây nhất (dựa
vào khoảng thời gian) sẽ được nút điều phối sử dụng để chuyển tiếp kết quả về cho
Client.
Để đảm bảo rằng tất cả các bản sao đều có phiên bản gần đây nhất của dữ liệu
đọc thường xuyên, thì nút điều phối cũng liên hệ và so sánh dữ liệu ở các bản sao mà
không được truy vấn đọc trực tiếp xem có nhất quán và không bị lỗi thời. Nếu bị lỗi
thời thì sẽ được cập nhật những giá trị được ghi gần đây nhất. Tến trình này đuợc gọi
là sửa đọc. Sửa đọc có thể được cấu hình đối với mỗi họ cột ( sử dụng
read_repair_chance), và được cho phép mặc định.

17


Ví dụ, trong một cụm với số lượng bản sao là 3, và mức độ nhất quán là
QUORUM, 2 trong 3 bản sao được liên hệ để thực hiện yêu cầu đọc trực tiếp. Giả định
rằng các bản sao được liên hệ có những phiên bản của các hàng khác nhau, thì bản sao
có phiên bản gần đây nhất sẽ trả lại dữ liệu được truy vấn. Bản sao thứ ba được kiểm
tra tính nhất quán so với hai bản sao trước, và nếu cần thiết, bản sao gần đây nhất sẽ
sinh ra một lệnh ghi để cập nhật những phiên bản lỗi thời.

3. Mô hình dữ liệu Cassandra
Mô hình dữ liệu Cassandra là một lược đồ động, mô hình dữ liệu hướng cột. Tức
là, không giống cơ sở dữ liệu quan hệ, người sử dụng không cần mô hình hóa tất cả
các cột mà ứng dụng cần đến, vì mỗi dòng không cần phải có cùng một tập hợp các cột
giống nhau. Cột và siêu dữ liệu của nó có thể được thêm vào bởi ứng dụng khi cần mà
không làm dừng chương trình.
3.1 So sánh mô hình dữ liệu Cassandra với cơ sở dữ liệu quan hệ

Mô hình dữ liệu Cassandra được thiết kế cho dữ liệu phân tán với quy mô rất lớn.
Mặc dù nhu cầu so sánh Cassandra với cơ sở dữ liệu quan hệ là rất tự nhiên, nhưng
chúng hoàn toàn khác nhau. Trong cơ sở dữ liệu quan hệ, dữ liệu được lưu trong các
bảng, các bảng này tạo thành một ứng dụng mà chúng thường liên quan đến nhau. Dữ
liệu được chuẩn hóa để giảm các bản ghi dư thừa, và các bảng được kết nối bằng khóa
để thỏa mãn một truy vấn nào đấy. Ví dụ, xem xét một ứng dụng cho phép người dùng
tạo các bài blog. Trong ứng dụng này, bài blog được phân loại theo chủ đề (thể thao,
thời trang …).

18


Người dùng có thể chọn đăng kí xem blog của những người khác. Trong ví dụ
này, user id là khóa chính trong bảng user, và là khóa ngoại trong các bảng blog và
subcriber.
Tương tự, category id là khóa chính của bảng category và là khóa ngoại trong
bảng blog_entry. Sử dụng mô hình quan hệ, các truy vấn SQL có tể thực hiện join
nhiều bảng để trả lời câu hỏi “những người dùng nào đăng kí xem blog của tôi”, hay
“cho tôi xem tất cả các blog viết về thời trang” hay “cho tôi xem các bài viết mới nhất
của các blog mà tôi đăng kí”.

Trong Cassandra, keyspace là nơi chứa tất cả dữ liệu ứng dụng, tương tự với một
cơ sở dữ liệu hay lược đồ trong một cơ sở dữ liệu quan hệ. Bên trong keyspace là một
hoặc nhiều đối tượng column family tương tự như các bảng. Các column family chứa
các cột và một tập các cột được xác định bởi một row key do ứng dụng cung cấp. Mỗi
dòng là trong một column family không nhất thiết phải có cùng các cột.
Cassandra không áp đặt quan hệ giữa các column family như cách mà cơ sở dữ
liệu quan hệ thực hiện với các bảng: không có khóa ngoại trong Cassandra, và việc
join các column family khi truy vấn không được hỗ trợ. Mỗi column family có một tập
các cột tự chứa được dự định để được truy nhập cùng nhau để thỏa mãn các truy vấn

nào đó từ ứng dụng.
Ví dụ, sử dụng vó dụ ứng dụng blog ở trên, bạn có thể có một column family cho
user và blog entry như trong mô hình quan hệ. Sau đó, các column family khác có thể
được thêm vào để hỗ trợ truy vấn mà ứng dụng cần thực hiện. Ví dụ, để trả lời truy vấn
“những người dùng nào đăng kí xem blog của tôi” ”, hay “cho tôi xem tất cả các blog
19


viết về thời trang” hay “cho tôi xem các bài viết mới nhất của các blog mà tôi đăng
kí”, bạn có thể cần thiết kế các column family bổ sung để hỗ trợ những truy vấn này.
Chú ý rằng cần thực hiện một số phi chuẩn hóa đối với dữ liệu.

3.2 Keyspaces
Trong Cassandra, keyspace là nơi chưa dữ liệu cho ứng dụng của bạn, giống như
lược đồ trong một cơ sở dữ liệu quan hệ. keyspace được dùng để nhóm các column
family lại với nhau. Thường thì một cluster có một column family cho một ứng dụng.
Việc nhân bản được điều khiển trên cơ sở keyspace, vì dữ liệu có những yêu cầu nhân
bản khác nhau nên đặt ở những keyspace khác nhau. Keyspace không được thiết kế để
sử dụng như một lớp bản đồ quan trọng trong mô hình dữ liệu, mà nó chỉ như một
cách để điều khiển việc nhân bản dữ liệu cho một tập các column family.
Các lệnh của ngôn ngữ định nghĩa dữ liệu (DDL) cho việc định nghĩa và thay đổi
keyspace được cung cấp trong rất nhiều giao diện khách hàng khác nhau như
Cassandra CLI và CQL. Ví dụ, để định nghĩa có một keyspace trong CQL:
CREATE KEYSPACE keyspace_name WITH
strategy_class = 'SimpleStrategy'
AND strategy_options:replication_factor=2;
Hoặc trong Cassandra CLI:
CREATE KEYSPACE keyspace_name WITH
20

placement_strategy = 'SimpleStrategy'
AND strategy_options = [{replication_factor:2}];
3.3 Column Families
Khi so sánh Cassandra với cơ sở dữ liệu quan hệ, column family giống như bảng
trong đó nó chứa các cột và dòng. Tuy nhiên, một column family cần thay đổi lớn
trong suy nghĩ của những người quen thuộc với thế giới quan hệ.
Trong cơ sở dữ liệu quan hệ, bạn định nghĩa ra các bảng có các cột cố định. Bảng
xác định tên cột, và kiểu dữ liệu của nó, và sau đó ứng dụng cung cấp các dòng để
hoàn thiện schema đó: mỗi dòng chứa cùng một số cột cố định như nhau.
Trong Cassandra, bạn định nghĩa các column family. Các column family có thể
(và nên) định nghĩa metadata về các cột, nhưng các cột thực sự tạp thành một dòng
được xác định bởi ứng dụng. Mỗi dòng có thể có số lượng cột khác nhau.
Mặc dù các column family rất linh hoạt, nhưng trong thực thế mỗi column family
không hoàn toàn không có lược đồ. Mỗi column family nên được thiết kế để chứa một
kiểu dữ liệu. Có 2 kiểu mẫu thiết kế column family phổ biến trong Cassandra: các
column family động và tĩnh.
Một column family tĩnh sử dụng một tập tương đối cố định các tên cột cột và
giống với cơ sở dữ liệu quan hệ hơn. Ví dụ, một column family lưu trữ dữ liệu người
dùng có thể có các cột tên người dùng, địa chỉ, email, số điện thoại… Mặc dù các dòng
sẽ có cùng một tập cột, chúng không bắt buộc phải có giá trị xác định cho tất cả các
cột. Column family tĩnh thường có metadata được đĩnh nghĩa trước cho mỗi cột.

Một column family động tận dụng được ưu điểm trong khả năng của Cassandra
để dùng các tên cột bất kỳ mà ứng dụng cung cấp để lưu trữ dữ liệu. Một column
family động cho phép bạn tính toán trước các tập kết quả và lưu chúng trong một dòng
đơn để truy vấn dữ liệu hiệu quả. Mỗi dòng là một snapshot của dữ liệu thỏa mãn một
truy vấn cụ thể.
21

Ví dụ, một column family theo dõi người sử dụng đăng kí xem một blog của
người dùng nào đó.

Thay vì định nghĩa metadata cho các cột riêng lẻ, một column family động định
nghĩa kiểu thông tin cho các tên giá giá trị của cột, nhưng tên và giá trị thực sự của cột
được đặt ởi ứng dụng khi một cột được thêm vào.
Với tất cả các column family, mỗi dòng là duy nhất và được xác định bằng khóa
của dòng đó, giống như khóa chính trong bảng quan hệ. Một column family luôn được
phân chia theo khóa dòng của nó, và khóa dòng luôn luôn được đánh chỉ mục ẩn. Khóa
dòng không được phép để trống.
3.4 Columns
Cột là đơn vị dữ liệu nhỏ nhất trong Cassandra. Nó là một bộ gồm có tên, giá trị,
và một nhãn thời gian.

Một cột phải có tên, và tên có thể là một nhãn tĩnh (như “tên”, hay “email”) hoặc
nó có thể được đặt tự động khi cột được tạo ra bởi ứng dụng. Cột có thể được đánh chỉ
mục theo tên của nó. Tuy nhiên, một hạn chế của các chỉ mục cột là chúng không hỗ
trợ các truy vấn yêu cầu truy nhập đến dữ liệu có thứ tự, như các dữ liệu chuỗi thời
gian. Trong trường hợp này, chỉ mục thứ cấp trên một cột nhãn thời gian là không đủ
vì bạn khong thể diều khiển thứ tự sắp xếp của cột với một chỉ mục thứ cấp. Với
những trường hợp thứ tự sắp xếp là quan trọng, việc duy trì thủ công một column
family như một chỉ mục là một cách khác để tra cứu cột dữ liệu được sắp xếp theo thứ tự.
Một cột không nhất thiết phải có một giá trị. Đôi khi tất cả thông tin ứng dụng
cần để thỏa mãn một truy vấn nào đó có thể được lưu trữ ngay ở tên của cột. Ví dụ,
nếu bạn đang sử dụng một column family như một cái nhìn cụ thể hóa dể truy vấn các
22


dòng từ các column family khác, tất cả những gì bạn cần là lưu trữ khóa dòng mà bạn

đang tìm kiếm,giá trị có thể trống.
Cassandra sử dụng cột nhãn thời gian để xác định cập nhật gần nhất của một cột.
Nhãn thời gian được cung cấp bởi ứng dụng. Nhãn thời gian gần nhất luôn đạt dược
khi yêu cầu dữ liệu, nếu nhiều phiên cùng cập nhật một cột trong một dòng cùng một
lúc thì cập nhập mới nhất là cập nhật sẽ được tồn tại.
3.5 Các column đặc biệt (Counter, Expiring, Super)
3.5.1 Expiring Columns
Một cột có thể có một ngày hết hạn tùy chọn gọi là TTL (time to live). Mỗi khi
một cột được thêm vào, ứng dụng yêu cầu có thể chỉ ra một giá trị TTL tùy chọn, được
định nghĩa bằng giây, cho cột đó. Các cột TTL được đánh dấu xóa sau khi thời gian
yêu cầu hết hạn. Một khi chúng được đánh dấu xóa, chúng sẽ tự động bị loại bỏ khỏi
các quá trình sửa hay nén thông thường.
Bạn có thể sử dụng CLI hay CQL để thiết lập TTL cho một cột. Nếu bạn muốn
thay đổi TTL của một cột có hạn, bạn phải thêm lại cột đó với giá trị TTL mới. Trong
Cassandra việc thêm một cột thực sự là thao tác thêm hoặc cập nhât, phụ thuộc vào
phiên bản trước của cột đó đã tồn tại hay chưa. Điều này có nghĩa là để cập nhật TTL
cho một cột với một giá trị không xác định, bạn phải đọc cột và sau đó thêm lại cột đó
với một giá trị TTL mới.
Các cột TTL có độ chính xác đến một giây, được tính toán trên server. Do đó,
một giá trị TTL rất nhỏ có lẽ không có mấy ý nghĩa. Hơn nữa, các đồng hồ trên server
phải được đồng bộ hóa; nếu không độ chính xác có thể bị giảm vì thời gian hết hạn
được tính toán trên máy chủ chính nhận thao tác thêm cột đầu tiên, nhưng sau đó lại
được đọc ra bởi các máy khác trên cluster.
Một cột có hạn có thêm 8 byte mào đầu trong bộ nhớ hay ổ đĩa (để ghi TTL và
thời gian hết hạn) so với các cột chuẩn.
3.5.2 Counter Columns
Counter là một kiểu cột đặc biệt được sử dụng để lưu trữ một số có giá trị đếm tự
tăng khi có sự xuất hiện của một sự kiện hoặc tiến trình cụ thể nào đó. Ví dụ, bạn có
thể sử dụng cột counter để đếm số lần một trang được xem.
Các counter column family phải sử dụng CounterColumnType là kiểu dữ liệu

cho cột. Điều này có nghĩa là hiện tại, các cột counter chỉ có thể được lưu trữ trong các
23