hệ cơ sở dữ liệu phân tán cassandra

1
HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG
KHOA QUỐC TẾ VÀ ĐÀO TẠO SAU ĐẠI HỌC
*********
BÀI TẬP NHÓM
HỆ CƠ SỞ DỮ LIỆU PHÂN TÁN CASSANDRA
Nhóm thực hiện:
Nguyễn Trường Giang
Nguyễn Hồng Hạnh
Đỗ Việt Phương
Đỗ Thị Nhẫn
Môn:
Các hệ thống phân tán
Lớp:
Truyền dữ liệu và mạng máy tính
M11CQCT01-B
Giáo viên hướng dẫn:
TS. Hà Hải Nam
Hà Nội, tháng 06 - 2012
2
MỤC LỤC
MỤC LỤC 2
MỞ ĐẦU 5
1. Những đặc trưng của Cassandra 6
1.1 Khái niệm 6
1.2 Phân tán và không tập trung hóa 6
1.3 Khả năng mở rộng mềm dẻo 6
1.4 Tính sẵn sàng cao và khả năng chịu lỗi 7
1.5 Tính nhất quán tùy chỉnh 7
1.6 Hướng dòng – Row oriented 8
1.7 Schema – Free (không bị ràng buộc về lược đồ) 8

1.8 Hiệu năng cao 9
2. Kiến trúc Cassandra 10
2.1 Kết nối giữa các nút (giao thức Gossip) 10
2.2 Các thành viên của cụm và các nút hạt giống 10
2.3 Trạng thái dò thất bạo và sự phục hồi 10
2.4 Phân vùng dữ liệu trong Cassandra 11
2.4.1 Giới thiệu về Phân vùng trong cụm Trung tâm đa dữ liệu 12
2.4.2 Hiểu biết về các loại phân vùng 14
2.5 Nhân bản trong Cassandra. 16
Chiến lược xác định vị trí nhân bản 16
2.6 Kiến trúc liên kết mạng 17
2.7 Snitches 20
Các dạng Snitch 21
2.8 Yêu cầu từ phía Client trong Cassandra 23
2.8.1 Yêu cầu ghi 23
3
Truy vấn ghi tới trung tâm đa dữ liệu 24
2.8.2 Truy vấn đọc 25
2.9 Lập kế hoạch triển khai cụm Cassandra 26
2.9.1 Lựa chọn phần cứng cho cài đặt doanh nghiệp 26
2.9.2 Lập kế hoạch cho một cụm Amazon EC2 29
2.9.3 Lựa chọn tùy chọn cấu hình nút 31
3. Mô hình dữ liệu Cassandra 35
3.1 So sánh mô hình dữ liệu Cassandra với cơ sở dữ liệu quan hệ 35
3.2 Keyspaces 37
3.3 Column Families 37
3.4 Columns 39
3.5 Các column đặc biệt (Counter, Expiring, Super) 40
3.5.1 Expiring Columns 40
3.5.2 Counter Columns 40

3.5.3 Super Columns 41
3.6 Các kiểu dữ liệu (Comparators và Validators) 42
3.6.1 Validators 43
3.6.2 Comparators 43
3.7 Nén column family 43
3.7.1 Khi nào sử dụng nén 44
3.7.2 Cấu hình nén cho một Column Family 44
3.8 Chỉ mục trong Cassandra 45
3.8.1 Chỉ mục chính 45
3.8.2 Chỉ mục thứ cấp 46
3.8.3 Tạo và sử dụng chỉ mục thứ cấp 46
3.9 Thiết kế mô hình dữ liệu 47
4
3.9.1 Dựa trên các truy vấn 47
3.9.2 Phi chuẩn hóa để tối ưu 48
3.9.3 Lập kế hoạch cho việc ghi trùng lặp 48
3.9.4 Sử dụng các khóa dòng tự nhiên hoặc thay thế 48
3.9.5 Các kiểu UUID cho tên cột 49
KẾT LUẬN 50
TÀI LIỆU THAM KHẢO 50
5
MỞ ĐẦU
Ngày nay, các dịch vụ trên Internet phải xử lí 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. Các cơ sở dữ liệu quan hệ
đang được triển khai hiện nay giải quyết rất tốt nhiệm vụ lưu trữ dữ liệu nhất định nào đó,
nhưng vì tính tập trung đó mà chúng có thể gây ra vấn đề khi mở rộng. Và, người sử dụng
thường muốn tìm cách để bớt các thao tác join nữa các bảng, tức là phi chuẩn hóa dữ liệu
– việc lưu trữ nhiều bản sao lưu của dữ liệu phá vỡ hoàn toàn thiết kế ban đầu, cả trong cơ
sở dữ liệu và ứng dụng. Hơn nữa, chúng ta thường xuyên cần tìm đường xung quanh các
giao dịch phân tán - nơi rất dễ hình thành nên các nút cổ chai. Những hoạt động này

thường không được hỗ trợ trực tiếp trong bất cứ cơ sở dữ liệu quan hệ nào. 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. Một đại
diện nổi bật của các NoSQL là Cassandra.
Cassandra là hệ cơ sở dữ liệu phân tán mã nguồn mở được bắt đầu bởi Facebook.
Năm 2008, Facebook chuyển nó cho cộng đồng mã nguồn mỡ và được 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. Cassandra là một mô hình cơ sở dữ liệu phân tán hoàn toàn, có khả
năng chịu lỗi cực tốt. Một tính chất nữa là nó rất linh hoạt, tốc độ đọc/ghi tăng tuyến tính
khi bổ sung thêm hạ tầng mới.
Trong bài tiểu luận này, nhóm xin trình bày về những đặc trưng của hệ cơ sở dữ
liệu phân tán Cassandra. Tiếp theo là phần kiến trúc và mô hình dữ liệu mà Cassandra sử
dụng.
6
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 nhất tại một số sites
trên Web".
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ơn
sử 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 nặng của yêu cầu
7
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
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ỏ
8
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 dòng – Row oriented
Cassandra thường được gọi là cơ sở dữ liệu hướng dòng, và điều này không sai.
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 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ấn
9
phứ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.
10
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
Cassandra 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
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ạo 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
11
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 nodetool để thêm hoặc loại bỏ các nút trong một cụm Cassandra.
Khi 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 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.
2.4 Phân vùng dữ liệu trong Cassandra
Khi bạn khởi động một cụm Cassandra, bạn 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 được 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.
12
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 (75-0). 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.
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.
13
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.
14
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
15

đó 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 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.
16
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 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.
17
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 đượ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.
18
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.
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):
19
20
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
21
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.
22
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.
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: cassandra-
topology.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, us-east 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.
23
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 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.
24
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 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.
25
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.
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