BÀI TẬP LỚN MÔN CƠ SỞ DỮ LIỆU NÂNG CAO SO SÁNH CƠ SỞ DỮ LIỆU AMAZON DYNAMO VÀ APACHE CASSANDRA

CHƯƠNG 1: TÌM HIỂU HỆ CƠ SỞ DỮ LIỆU CASSANDRA VÀ AMAZON
DYNAMO 3
1. Giới thiệu về cassandra và Amazon Dynamo 3
1.1. Tổng quan về Cassandra 3
1.2. Tổng quan về Amazon Dynamo 4
CHƯƠNG 2: APACHE CASSANDRA 5
1. So sánh cassandra và cơ sở dữ liệu quan hệ 5
2. Cấu trúc của Cassandra 7
2.1. Sự giao tiếp giữa các nút 7
2.2. Phần vùng dữ liệu 8
2.2.1. Phân vùng trong cluster trung tâm Multi-Data 9
2.2.2. Các loại phân vùng (partitioner) 10
2.3. Bản sao trong cassandra (Cassandra Replication) 12
2.3.1. Chiến lược cho bản sao 12
2.3.2. Snitches 14
2.4. Các request của client trong Cassandra 16
2.4.1. Request ghi 16
2.4.2. Request đọc dữ liệu 18
3. Các kiểu dữ liệu 19
3.1. Keyspace 19
3.2. Column family 20
3.3. Cột (Column) 21
3.4. Các cột đặc biệt trong cassandra 22
3.4.1. Cột Expiring 22
3.4.2. Cột counter 22
3.4.3. Cột super 22
3.5. Kiểu dữ liệu trong cassandra 23
4. Quản lý và truy cập dữ liệu trong Cassandra 24
4.1. Ghi dữ liệu trong Cassandra 24
4.2. Nén dữ liệu 24
4.3. Kiểm soát các toàn tác và truy cập đồng thời 25

1
4.4. Chèn và cập nhật 25
4.5. Xoá dữ liệu 25
4.6. Phương thức ghi Hinted Handoff (trở về trạng thái trước đó) 26
4.7. Đọc dữ liệu 26
4.8. Tính nhất quán của dữ liệu 27
5. Cassandra API 27
5.1. Các API của một số ngôn ngữ bậc cao: 28
5.2. Cassandra CLI 28
6. Sử dụng ngôn ngữ truy vấn Cassandra (CQL – Cassandra Query Language) 33
7. Công cụ DataStax OpsCenter 36
CHƯƠNG 3: AMAZON DYNAMODB 41
1. Tổng quan về Amazon DynamoDB 41
2. Cấu trúc Amazon dynamo 42
3. Mô hình dữ liệu của Amazon DynamoDB 44
4. Tạo bảng và quản lý dữ liệu với công cụ Dynamo monitor 48
CHƯƠNG 4: SO SÁNH CASSANDRA VÀ AMAZON DYNAMO DB 50
1. Chi phí sử dụng: 50
2. Thông số kỹ thuật: 50
TÀI LIỆU THAM KHẢO 52
2
CHƯƠNG 1: TÌM HIỂU HỆ CƠ SỞ DỮ LIỆU CASSANDRA VÀ AMAZON
DYNAMO
1. Giới thiệu về cassandra và Amazon Dynamo
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. 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ụ này. 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). Đại diện nổi bật
của các NoSQL là Cassandra và Amazon Dynamo.

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. Đầu năm 2010, Cassandra đã trở thành một dự án lớn của Apache.
Ngày nay có hàng trăm tổ chức triển khai hệ cơ sở dữ liệu này trong sản xuất, như
Netflix, Twitter, Rackspace, Cisco Còn đối với Amazon Dynamo, tất nhiên được ra đời
sớm hơn cassandra (chính thức từ năm 2000) và do Amazon phát triển, sử dụng trong
nhiều sản phẩm của mình như hệ thống BookShop, Amazon Cloud

1.1. Tổng quan về Cassandra
Cassandra có thể quản lý được một số lượng lớn các dữ liệu có cấu trúc, bán cấu
trúc và phi cấu trúc. Cassandra cung cấp một lược đồ quan hệ dữ liệu động kèm theo sự
linh hoạt và hiệu suất cao nhất.
Sức mạnh của Cassandra ở tính co giãn và khả năng mở rộng. Đó là khả năng
đọc/ghi tăng tuyến tính theo số lượng máy và không có thời gian chết (downtime) hay sự
3
gián đoạn ứng dụng đang chạy của bạn. Cassandra chấp nhận sai sót (Fault Tolerant), dữ
liệu của bạn sẽ được sao chép thành nhiều bản trên các server. Nếu chẳng may 1 server
nào đó bị hỏng, bạn vẫn có thể truy xuất dữ liệu của trên các server khác.
Hệ cơ sở dữ liệu này hoạt động theo nguyên tắc hướng cột (Column-Oriented).
Nghĩa là: đối với 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). Nhưng 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.
Cassandra còn thể hiện ở tính sẵn sàng cao (Highly Availability). Khi thực hiện tác
vụ đọc/ghi, Cassandra có thể 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.
Điều này phụ thuộc vào thông số ConsitencyLevel do bạn thiết lập.
Hệ cơ sở dữ liệu Cassandra chạy trên nền Java, vì vậy trước khi cài đặt, ta cần cài
đặt phiên bản Java phù hợp với bản Cassandra định cài trên máy. Hiện nay, Cassandra đã
phát triển đến phiên bản mới nhất là Cassandra 1.2 . Ở phiên bản mới Hệ cơ sở dữ liệu
này đã cải tiến hơn nữa tính sẵn sàng, bằng việc có thể điều hướng, thống nhất các hoạt

động. Ngoài ra còn tích hợp bộ nhớ đệm cho phép điều chỉnh chính xác hiệu suất đọc/ghi
cho khối lượng và mô hình dữ liệu cụ thể.
1.2. Tổng quan về Amazon Dynamo
Amazon Dynamo DB là hệ quản trị cơ sở dữ liệu NoSQL có hiệu suất tốt và khả
năng mở rộng liên tục. Amazon Dynamo có khả năng tự động phân phối dữ liệu và lưu
lượng truy cập trên các bảng dữ liệu một cách phù hợp nhất theo yêu cầu của người sử
dụng. Tất các dữ liệu được lưu trữ trên ổ đĩa Solid State Disks (SDDs), đảm bảo tốc độ xử
lý nhanh. Ngoài ra, giống như các hệ cơ sở dữ liệu NoSQL khác Dynamo DB còn tự động
nhân rộng dữ liệu để đảm bảo tính sẵn sàng và tránh rủi ro.
Tuy nhiên, Amazon không chỉ sử dụng CSDL DynamoDB cho các dịch vụ hãng.
Mà kết hợp DynamoDB với các cơ sở dữ liệu và dịch vụ khác của hãng để tạo thành một
Multi – Store. DynamoDB cùng với các dịch vụ cơ sở dữ liệu khác như Amazon S3,
Amazon RDS tạo thành một cơ sở dữ liệu khổng lồ phục vụ cho hoạt động kinh doanh
của hãng (bookshop, shoping, movie store, appstore ). Tất nhiên, các cơ sở dữ liệu này
có mối quan hệ mật thiết để dễ dàng truy xuất và trao đổi thông tin với nhau.
4
CHƯƠNG 2: APACHE CASSANDRA
1. So sánh cassandra và 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 trên một quy mô rất
lớn và khá khác nhau so với cơ sở dữ liệu quan hệ. Trong một cơ sở dữ liệu quan hệ, dữ
liệu được lưu trữ trong các bảng và các bảng là những dữ liệu có liên quan đến nhau. Dữ
liệu thường được chuẩn hóa để giảm bớt các mục không cần thiết, và các bảng được nối
với nhau bằng các khóa chung để đáp ứng một truy vấn nhất định.
Ví dụ: Ta xem xét một ứng dụng đơn giản cho phép người dùng tạo ra các mục
blog. Trong ứng dụng này, các mục blog được phân loại theo khu vực, chủ đề (thể thao,
thời trang ). Người dùng cũng có thể chọn để đăng ký vào các blog của user khác. Trong
ví dụ này, ID của user là khóa chính trong bảng user và các khóa ngoài là trong các bảng
blog và subscriber (thuê bao). Tương tự như vậy, ID là khóa chính của bảng danh mục
(category) và khóa ngoài nằm trong bảng blog_entry. Sử dụng mô hình quan hệ này, các
truy vấn SQL có thể kết nối các giá trị của bảng để trả lởi câu hỏi “Những user nào đăng

nhập vào blog của tôi?” hoặc “cho tôi xem tất cả các blog về thời trang”
Dữ liệu trong một csdl quan hệ
5
Trong cassandra, keyspace là tập hợp các dữ liệu của ứng dụng, tương tự như lược
đồ của cơ sở dữ liệu quan hệ. Bên trong keyspace là các gia đình cột, tương tư như một
bảng của cơ sở dữ liệu quan hệ. Gia đình cột chứa tập hợp những cột liên quan được xác
định bởi row key. Mỗi hàng trong gia đình cột không cần thiết phải có cùng một tập hợp
cột.
Cassandra không thực hiện việc liên kết giữa các gia đình cột theo cách mà cơ sở
dữ liệu quan hệ sử dụng giữa các bảng, không có dạng khóa ngoài và không hỗ trợ truy
vấn vào gia đình cột. Mỗi một gia đình cột là tập hợp các cột được tập hợp lại với nhau để
đáp ứng một truy vấn cụ thể.
Ví dụ: Với ứng dụng Blog ở trên, chúng ta có thể tạo ra một gia đình cột. Sau đó
có thể thêm vào các cột để hỗ trợ truy vấn như “Những user truy cập vào blog của tôi?”,
“cho tôi xem tất cả các blog về thời trang?”, “cho tôi xem những mục gần đây nhất mà
blog của tôi truy cập?”.
6
2. Cấu trúc của Cassandra
Hệ cơ sở dữ liệu Cassandra là tập các nút độc lập được nhóm lại với nhau tạo
thành một Cluster. Trong các Cluster này tất cả các nút có vai trò ngang nhau, nghĩa là
không có nút chủ hay nút trung tâm. Một nút tham gia vào một Cluster căn cứ vào nội
dung và cấu hình của nút đó.
2.1. Sự giao tiếp giữa các nút
Cassandra sử dụng một giao thức gọi là Gossip để tìm hiểu về vị trí, trạng thái của
các nút khác tham gia trong một Cluster. Gossip là một giao thức truyền thống peer-to-
peer; trong đó các nút định kỳ trao đổi thông tin trạng thái với nhau và về các nút khác mà
chúng biết. Trong Cassandra, giao thức Gossip mỗi một lần xử lý sẽ chạy nút 2 và trao
đổi thông điệp với nút thứ 3 khác trong Cluster. Các nút sẽ trao đổi thông tin về bản thân
nó và những nút khác mà nó biết vì vậy tất cả các nút trong Cluster nhanh chóng được xử
lý. Mỗi một Gossip đều có một phiên bản liên quan đến nó, vì vậy quá trình trao đổi,

thông tin được ghi đè bằng các trạng thái hiện tại cho mỗi nút cụ thể.
- Về Cluster thành viên và nút hạt giống
Khi bắt đầu từ nút đầu tiên, nút này sẽ căn cứ vào cấu hình file của chính nó để xác
định tên của Cluster và nút hạt giống Node(s), sau đó nó tiếp tục liên hệ để lấy thông tin
các nút khác trong Cluster. Các điểm liên kết của các Cluster được cấu hình trong file có
tên là Cassandra.yaml, file này tồn tại trong nút.
Để trách cho các phân vùng trong Gossip giao tiếp, tất cả các nút trong cùng một Cluster
đều có danh sách giống như trong nút hạt giống để lắng nghe các cấu trúc file của chúng.
Đây là vấn đề then chốt đầu tiên của một nút khi bắt đầu. Theo mặc định, một nút sẽ nhớ
một nút khác và tiếp tục khởi động đến các nút tiếp theo.
Để biết phạm vi dữ liệu mà nó chịu trách nhiệm, một nút cũng phải biết mã thông báo
(token) riêng của mình và các nút khác trong Cluster. Khi khởi tạo một Cluster mới, nên
tạo ra một mã (token) để đảm bảo tính toàn vẹn cho Cluster và chỉ định một mã thông báo
ban đầu. Mỗi nút sau đó sẽ Gossip mã cho những nút khác.
- Về phát hiện lỗi và khôi phục
Phát hiện lỗi là một phương thức xác định mang tính nội bộ, từ trạng thái của
Gossip, mà các một nút khác trong hệ thống có thể đi lên hoặc đi xuống. Thông tin phát
7
hiện lỗi cũng được Cassandra sử dụng để tránh các truy cập định tuyến không tới được
bất kỳ nút nào cố định (Cassandra cũng có thể tránh được truy cập đến những nút hoạt
động kém).
Gossip theo dõi heartbeats từ những nút khác bao gồm cả trực tiếp và gián tiếp.
Thay vì tạo ra một ngưỡng cố định để đánh dấu các nút, Cassandra sử dụng cơ chế phát
hiện riêng là để tính toán tiêu chuẩn cho mỗi nút, nó dựa vào các điều kiện như tài khoản
mạng, khối lượng công việc và những điều kiện khác ảnh hưởng đến heartbeats.
Trong suốt quá trình trao đổi, mỗi nút sẽ duy trì một cửa sổ có thành trượt thời gian
inter-arrival là thông báo từ những nút khác trong cùng một cluster. Giá trị này dựa trên
sự phân phối của thời gian inter-arrival trên tất cả các nút trong một cluster. Trong
cassandra thành phần phi_convict_threshold là để điều chỉnh độ nhậy của việc phát hiện
lỗi này.

Một nút có thể bị lỗi do nhiều nguyên nhân khác nhau như lỗi phần cứng, mất
mạng Những nút bị lỗi đó xẩy ra trong một thời gian ngắn nhưng cũng có thể dài. Rất
hiếm khi một nút bị lỗi lại biểu thị sự khởi đầu trong cluster, và do đó việc phải loại bỏ
hoàn toàn nút đó ra khỏi vòng. Các nút khác vẫn sẽ định kỳ tiếp nhận thông tin từ nút lỗi
để xem nó có trở lại hoạt động không. Để thay đổi vĩnh viễn một thành viên trong cluster,
phải sử dụng một công cụ là nodetool utility.
Khi một nút sau khi bị lỗi lại quay trở lại, nó có thể bị nhỡ một số các thông tin
trong quá trình nó bị lỗi. Tuy nhiên, nếu còn trong một khoảng thời gian cho phép nó có
thể lấy lại thông tin bị mất từ các bản sao. Nếu khoảng thời gian bị lỗi của nó quá dài
(max_hint_window_in_ms, mặc định là 1 giờ), bản sao sẽ không còn lưu lại. Vì thế phải
thường xuyên chạy nodetool để sửa chữa tất các nút đảm bảo sự tin cậy của dữ liệu, và
cũng để sửa chữa các nút khi hồi phục sau một khoảng thời gian dài.
2.2. Phần vùng dữ liệu
Khi bắt đầu một cluster, ta phải chọn việc sẽ phân bố dữ liệu như thế nào trên các
nút trong cluster. Trong cassadra, dữ liệu quản lý bằng cluster, được biễu diễn trong một
không gian vòng. Vòng được chia thành các khoảng bằng số của nút, mỗi một nút biểu
diễn cho một hoặc nhiều khoảng của các dữ liệu tổng thể. Trước khi một nút có thể tham
gia vòng, nó phải được gắn một mã (token). Các mã này sẽ xác định vị trí của nút trên
vòng và khoảng dữ liệu mà nó biểu diễn.
8
Cột dữ liệu gia đình (column family) được phân vùng trên các nút dựa theo row
key. Để xác định nút, nơi có bản sao đầu tiên của hàng, thông điệp sẽ chạy theo chiều
kim đồng hồ của vòng đến khi nó định vị được nút có giá trị token lơn hơn giá trị của row
key. Mỗi nút có trách nhiệm đối với vùng giữa nó và nút trước đó. Với các nút được sắp
xếp theo thứ tự token, nút cuối cùng được coi như là tiền thân của nút đầu tiên; vì vậy đây
chính là biểu diễn của một vòng.
Phân vùng dữ liệu trong cassandra
Xét ví dụ, một cluster có 4 nút đơn giản, nơi mà tất cả các row key được quản lý
bởi một cụm số từ 1 – 100. Mỗi nút được gán một token biểu diễn cho một điểm trong
khoảng đó. Trong ví dụ này, token có giá trị là 0, 25, 50 và 75. Nút đầu tiên, với token

bằng 0, chịu trách nhiệm về trong phạm vi gói (75-0). Nút với mã token thấp nhất cũng
chấp nhận row key ít hơn token thấp nhất và nhiều hơn token cao nhất.
2.2.1. Phân vùng trong cluster trung tâm Multi-Data
Trong phát triển trung tâm Multi-Data (đa dữ liệu), vị trí bản sao được tính cho
mỗi trung tâm dữ liệu khi sử dụng NetworkTopologyStrategy. Trong mỗi trung tâm dữ
liệu (hoặc nhóm sao chép), bản sao đầu tiên cho một hàng cụ thể được xác định bởi một
giá trị token đã gán cho nút. Việc bổ sung một bản sao trong cùng một trung tâm dữ liệu
được thực hiện bằng cách đi theo chiều kim đồng hồ đến khi nó đạt được nút đầu tiên
trong rack khác.
Nếu không tính toán những token cho các phân vùng để dữ liệu được phân bổ đều,
thì dữ liệu sẽ không được phân bố đồng đều trong trung tâm dữ liệu.
9
Mục đích của việc phân vùng là đảm bảo các nút ở mỗi trung tâm dữ liệu được gán
giá trị token để phân chia khoảng một cách đồng đều. Mỗi một trung tâm dư liệu được
phân chia như thể nó là một vòng riêng, tuy nhiên những token đã được gán trong toàn bộ
các cluster phải không xung đột với nhau (mỗi nút phải có một token duy nhất). Hãy xem
những tính toán token cho cluster chiến lược của trung tâm đa dữ liệu và làm thế nào để
tạo ra các token cho cluster của trung tâm này.
2.2.2. Các loại phân vùng (partitioner)
Trong cassandra phân vùng không thể thay đổi được nếu không tải lại toàn bộ dữ
liệu. Vì vậy, điều quan trọng là chọn và cấu hình các phân vùng phải chính xác trước khi
khởi tạo cluster.
Cassandra cung cấp một số phân vùng bên ngoài danh mục, tuy nhiên cách lựa
chọn các phân vùng ngẫu nhiên là lựa chọn tốt nhất khi triển khai cassandra.
Phân vùng ngẫu nhiên (random partitioner)
Phân vùng ngẫu nhiên là phân vùng mặc định trong cassandra, và trong hầu hết các
trường hợp là sự lựa chọn đúng.
Phân vùng này sử dụng một thuật toán băm phù hợp để xác định nút, nút này sẽ
lưu trữ một row cụ thể. Thuật toán băm này sẽ đảm bảo rằng khi có một nút được thêm
vào cluster, mức độ ảnh hưởng là ít nhất.

Để phân phối dữ liệu một cách đồng đều qua số lượng các nút, thuật toán băm sẽ
tạo ra giá trị băm (MD5) của row key. Giá trị băm là từ 0 đến 2**127. Mỗi nút trong
cluster được gán một token đại diện cho một giá trị băm trong phạm vi này. Một nút sau
10
đó sẽ sở hữu các row với một giá trị băm ít hơn số token của chính nó. Đối với việc phát
triển một trung tâm dữ liệu đơn lập, các token được tính toán bằng cách chia phạm vi băm
bởi số lượng các nút trong cluster. Đối với trung tâm đa dữ liệu, token được tính toán 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 bản
sao).
Lợi ích của phương pháp này là một khi token được gắn một cách phù hợp, dữ liệu
từ tất cả các column families được phân tán đều trên toàn cụm và không thể đều hơn được
nữa. Ví dụ, một column family có thể sử dụng trường tên như là row key và một column
family timestamps khác, nhưng các row key từ mỗi column family riêng lẻ vẫn được
truyền bá một cách đồng đều. Điều đó nghĩa là việc đọc/ghi tới một cluster vẫn được phân
tán một cách đồng đều.
Một lợi ích nữa của việc sử dụng phân vùng ngẫu nhiên là đơn giản hóa trong việc
cân bằng tải của một cluster. Bởi vì mỗi phần của phạm vi băm sẽ nhận được một lượng
row trung bình tương đương, điều này dễ dàng hơn để gắn một cách chính xác các token
cho nút mới.
Phân vùng có sẵn (Ordered Partitioners)
Việc sử dụng phần vùng có sẵn, đảm bảo rằng row key được lưu trữ trong thứ tự
sắp xếp. Trừ khi đối với trường hợp cần thiết, nếu không ta nên chọn phân vùng ngẫu
nhiên.
Sử dụng phần vùng sẵn có cho phép khoảng quét hàng cao, có nghĩa là quét như
việc 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ư một row key, bạn có thể quét rows người sử dụng với tên rơi vào
giữa hai tên Jake – Joe. Kiểu truy vấn này không thể phân vùng row key một cách ngẫu
nhiên, kể từ khi các key được lưu trữ trong thứ tự của bảng băm MD5 của chúng.
Việc sử dụng phân vùng có sẵn được khuyến khích sử dụng trong các trường hợp
sau:

- Việc ghi liên tục vào CSDL có thể là nguyên nhân gây ra lỗi. Nếu ứng dụng có xu
hướng chuyên ghi hoặc cập nhật liên tiếp một khối dữ liệu hàng trong một thời gian, sau
đó dữ liệu được ghi không được phân phối trên cluster, tất cả chúng sẽ đi đến một nút.
- Trong trường hợp cần quản lý cao hơn việc load cluster cân bằng. Một phần vùng có sẵn
đòi hỏi người quản lý phải tính toán phạm vi token dưa trên sự ước lượng trong việc phần
11
phối row key. Trong thực tế, điều này đòi hỏi các token của nút phải di chuyển một cách
tích cực xung quanh để thích ứng với phấn dữ liệu mà nó đã tải.
- Trong trường hợp cân bằng load dữ liệu không đồng đều cho nhiều column family. Nếu
ứng dụng có nhiều column family, rất có thể những column family này có row key khác
nhau và khác nhau về dữ liệu phân tán. Một phân vùng có sẵn sẽ tốt hơn là cân bằng cho
một column family có thể là nguyên nhân gây ra điểm lỗi và phân phối không đồng đều
cho các cloumn family khác cùng cluster.
2.3. Bản sao trong cassandra (Cassandra Replication)
Cassandra replication 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 tạo một key space (không gian khóa) trong
casandra, phải xác định chiến lược cho các bản sao, nghĩa là số lượng các bản sao và các
bản sao sẽ được phân phối như thế nào trên các nút trong một cluster. Chiến lược này dựa
trên cấu hình của cluster để xác định vùng vật lý của nút và khu vực xung quanh. Tổng số
các bản sảo trên cluster thường được gọi giống như replication factor (hệ số sao chép).
Một hệ số sao chép là 1 có nghĩa là mỗi một row chỉ có một bản sao. Nếu hệ số sao chép
là 2 có nghĩa là mỗi một hàng có 2 bản sao. Tất cả các bản sao đều quan trọng; không
phân biệt bản sao chính primary hay master. Như một quy tắc chung, hệ số nhân bản
không được vượt quá số lượng các nút trong cluster. Tuy nhiên, nó cũng có thể tăng hệ số
nhân bản lên trước và sau đó thêm vào các nút tương ứng. Khi hệ số nhân bản vượt quá số
nút, việc ghi vào sẽ bị từ chối, nhưng phần đọc vẫn thực hiện miễn là consistency level
(mức độ nhất quán) có thể đáp ứng được. Về chiến lược cho bản sao, vị trí bản sao được
xác định dựa vào keyspace được phân phối trên các cluster. Vị trí bản sao được thiết lập
khi khởi tạo keyspace. Có một số chiến lược cho bản sao, những chiến lược này dựa trên
mục tiêu của người sử dụng và thông tin về khu vực nút được đặt.

2.3.1. Chiến lược cho bản sao
- Chiến lược đơn giản (Simple Strategy)
Chiến lược này chính là chế độ mặc định trong cassandra, khi khởi tạo một keyspace ta sử
dụng cassandra CLI. Chiến lược đơn giản đặt các bản sao đầu tiên trên một nút được xác
định bằng cách phân vùng. Bản sao bổ sung được đặt trên các nút tiếp theo, theo chiều
kim đồng hồ mà không xét các rack hoặc dữ liệu của các nút trong khu vực đó.
12
Chiến lược Network Topology
Đây là chiến lược nhân rộng các bản sao tại những vị trí mong muốn khi có các thông tin
về các nút thuộc một nhóm trong trung tâm dữ liệu, hoặc có người sử dụng có kế hoạch
triển khai trên nhiều trung tâm dữ liệu. Chiến lược Network Topology cho phép xác định
số bản sao mong muốn tại mỗi trung tâm dữ liệu.
Ví dụ khi quyết định có bao nhiêu bản sao để cấu hình trong mỗi trung tâm dữ liệu, ta
xem xét có thể đáp ứng để đọc dữ liệu của ta hay không, mà không phải đi qua một trung
tâm dữ liệu khác có độ trễ và bị lỗi.
Có hai cách phổ biến để cấu hình các cụm trung tâm dữ liệu là:
- Đặt 2 bản sao trong mỗi trung tâm dữ liệu. Cách cấu hình này đảm bảo cho mỗi nhóm
trong trường hợp có một nút lỗi, mà vẫn hoạt động được, mức nhất quán (consistency
level) ở đây được gọi là ONE.
- Đặt 3 bản sao trong mỗi trung tâm dữ liệu. Cách cầu hình này đảm bảo cho sự truy cập
vẫn diễn ra bình thường khi nó có một hoặc hai nút lỗi. Mức nhất quán ở đây là LOCAL-
QUORUM.
- Phương pháp bất đối xứng (Asymmetrical), cách này tùy thuộc vào từng trường hợp sử
dụng cụ thể. Ví dụ: có thể đặt ba bản sao cho mỗi trung tâm dữ liệu để phục vụ cho ứng
dụng đòi hỏi thời gian thực, và sau đó có thể đặt một bản sao duy nhất trong một trung
tâm dữ liệu được thiết kế để chạy các phân tích. Trong cassandra, nhóm trung tâm dữ liệu
là đồng nghĩa với nhóm bản sao, tức nó là một nhóm các nút có cùng cấu hình để thực
hiện mục đích sao chép. Nó không phải là một trung tâm dữ liệu vật lý.
Với chiến lược Network Topology, 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 sao chép). Bản sao đầu tiên trên một trung tâm dữ liệu được đặt

13
theo các phân vùng (giống như chiến lược đơn giản). Bản sao bổ sung trong cùng một
trung tâm dữ liệu được xác định bằng cách đi theo chiều kim đồng hồ cho đến khi một nút
trong một rack khác từ bản sao 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. Chiến lược này ưu tiên đặt các bản sao trên
các rack riêng biệt. Các nút trong cùng một rack (hoặc nhóm tương tự mang tính vật lý)
có thể dễ dàng cùng bị lỗi do các vấn đề mạng, nguồn điện
Dưới đây là một ví dụ về việc làm thế nào chiến lược Network Topology đặt các bản sao
tại 2 trung tâm dữ liệu với hệ số bản sao là 4 (hai bản sao trong trung tâm dữ liệu 1 và 2
bản sao trong trung tâm dữ liệu 2).

2.3.2. Snitches
Snitches là một thành phần cấu hình trong cluster của cassandra được sử dụng để xác định
các nút nào được nhóm lại với nhau trong network topology (giống như 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 nút một cách hiệu
quả. Sniches không làm ảnh hưởng đến các request giữa ứng dụng khách và cassandra (nó
không kiểm soát nút mà client kết nối).
14
Snitches được cấu hình cho một cluster được lưu trong file cassandra.yaml. Tất cả các nút
trong cluster được sử dụng cùng một cấu hình snitches. Khi gắn mã token, thì xen kẽ giữa
các rack. Ví dụ: rack 1, rack2, rack 3, rack 1, rack 2, rack 3 và cứ như vậy.
Các snitches:
Snitches đơn giản (simple Snitches)
Đây là snitches mặc định, nó thích hợp khi không có rack hoặc thông tin dữ liệu
sẵn có. Nếu ta chỉ phát triển trung tâm dữ liệu duy nhất thì thường dùng loại này (hoặc
một khu vực riêng trong khu vực công cộng). Nếu sử dụng snitches, ta cho hệ số bản sao
(replication = <#>) khi xác định strategy_options keyspace. Snitches này không nhận biết
trung tâm dữ liệu hoặc thông tin rack.
Rack Inferring Snitches
Snitches này đưa ra cấu trúc mạng trên cơ sở phân tích địa chỉ IP của nút. Nó giả

định rằng các octet thứ hai sẽ xác định trung tâm dữ liệu nơi một nút được đặt, và octet
thứ ba sẽ xác định các rack.
15
PropertyFileSnitch
PropertyFileSnitch xác định vị trí của các nút bằng cách người dùng tự định nghĩa
chi tiết của mạng đặt trong file thuộc tính cassandra-topology.properties. Snitch loại này
tốt nhất khi các nút IP là không thống nhất hoặc đòi hỏi nhóm bản sao phức tạp. Nếu sử
dụng snitch này, ta có thể xác định tên trung tâm dữ liệu mà có thể theo ý muốn người sử
dụng. Chỉ cần chắc chắn tên trung tâm dữ liệu được xác định trong file cassandra-
topology.properties tương ứng với tên của trung tâm dữ liệu trong strategy_options
keyspace.
Dynamic Snitching
Theo mặc định, tất cả snitches đều sử dụng một lớp snitch động để giám sát độ trễ
trong việc đọc dữ liệu và có khi nó được sử dụng để request từ các nút kém hoạt động.
Các snitch được kích hoạt theo mặc định, và được khuyến khích sử dụng trong hầu hết
các hoạt động. Ngưỡng của Dynamic snitch có thể được cấu hình trong file cấu hình
cassandra.yaml của nút.
2.4. Các request của client trong Cassandra
Tất các nút trong cassandra là ngang nhau. Một client có các request đọc hoặc ghi
có thể đí đến bất kể một nút nào trong cluster. Khi client kết nối tới một nút và thực hiện
các request đọc hoặc ghi, thì nút đó sẽ đáp ứng như vai trò là một điều phối viên cho
những hoạt động cụ thể của client.
Công việc điều phối này giống như một proxy giữa client và nút sở hữu những dữ liệu
đang được request. Nút điều phối sẽ xác định các nút trong vòng nhận request dựa vào các
phân vùng được cấu hình của cluster và chiến lược đặt bản sao.
2.4.1. Request ghi
Để ghi dữ liệu, điều phối viên sẽ gửi dữ liệu ghi cho tất cả các bản sao mà row của
chính nó đang được ghi. Miễn là tất cả các nút bản sao là ở phía trên và đang hoạt động,
dữ liệu sẽ được ghi bất kể mức nhất quán (consistency level) đã được client quy định.
Mức nhất quán trong chế độ ghi xác định có bao nhiêu bản sao tại các nút phải respond

các request nếu thông điệp thành công, như vậy việc ghi vào đã thành công.
Ví dụ: Trong một trung tâm dữ liệu đơn lập có 10 nút với hệ số bản sao là 3, tức là một
lệnh ghi sẽ đi tới 3 nút mà sở hữu request row. Mức độ nhất quán của lệnh ghi được client
quy định là ONE, thì nút đầu tiên sẽ hoàn tất việc ghi và trả lời lại cho điều phối viên, sau
16
đó trả lại thông điệp thành công cho client. Mức nhất quán là ONE có nghĩa vị trí của 2
trên 3 bản sao có thể bị nhỡ lệnh ghi nếu chúng xẩy ra tại thời điểm request đã được tạo.
Nếu một bản sao bỏ lỡ một lệnh ghi, thì một hàng sẽ được tạo ra, sau đó cassandra sẽ tạo
ra cơ chế sửa chữa.
- Request ghi đối với trung tâm đa dữ liệu (Multi-Data Center)
Trong trung tâm đa dữ liệu, cassandra tối ưu hóa hiệu suất ghi bằng cách chọn một nút
điều phối trong mỗi trung tâm dữ liệu từ xa để xử lý các request tới các bản sao trong
trung tâm dữ liệu của nó. Các nút điều phối liên lạc với client chỉ để chuyển tiếp các
request ghi vào một nút trong mỗi trung tâm dữ liệu từ xa.
17
2.4.2. Request đọc dữ liệu
Đối với đọc dữ liệu, có 2 loại, đọc yêu cầu mà một nút điều phối có thể gửi tới một bản
sao là đọc trực tiếp yêu cầu và đọc yêu cầu sửa chữa. Số lượng các bản sao liên đã liên lạc
với một yêu cầu đọc trực tiếp được xác định bởi mức nhất quán được client quy định. Đọc
yêu cầu sửa chữa được gửi đến bất kỳ bản sao bổ sung nào mà không nhận được yêu cầu
đọc trực tiếp. Đọc yêu cầu sửa chữa đảm bảo rằng hàng yêu cầu tạo ra trên tất cả các bản
sao.
Vì vậy, địa chỉ bản sao của nút điều phối đầu tiên được quy định bởi mức độ nhất quán.
Các điều phối viên sẽ gửi yêu cầu tới các bản sao mà hiện tại đang đáp ứng tốt nhất các
yêu cầu. Các nút đã liên lạc sẽ đáp ứng các yêu cầu dữ liệu; nhưng nếu có nhiều nút được
liên lạc, thì các hàng từ mỗi bản sao mà có dữ liệu gần đây nhất (dựa trên timestamp)
được sử dụng để điều phối chuyển tiếp các kết quả lại cho client.
Để đảm bảo tất cả các bản sao có phiên bản mới nhất, điều phối viên 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 mà sở hữu hàng ở chế độ backgroud, và nếu
chúng không phù hợp, lệnh ghi sẽ được thực hiện để cập nhật dữ liệu được ghi gần đây

nhất. Quá trình này chính là quá trình đọc sửa chữa. Đọc sửa chữa có thể cấu hình cho
mỗi column family (sử dụng chức năng đọc, sửa, thay đổi) và được kích hoạt theo mặc
định.
Ví dụ, trong một cluster với hệ số bản sao là 3, và lệnh đọc có mức độ nhất quán là
QUORUM, 2 trong số 3 bản sao cho hàng được kết nối để thực hiện các yêu cầu đọc. Giả
sử các bản sao đã kết nối có các phiên bản khác nhau của hàng, bản sao với phiên bản gần
đây nhất sẽ trả lại dữ liệu yêu cầu trong lệnh đọc. Trong background, 3 bản sao đã được
kiểm tra tính nhất quán với 2 bản sao đầu tiên, và nếu cần thiết, bản sao có dữ liệu gần
nhất sẽ truyền dữ liệu để các bản sao khác cập nhật.
18
3. Các kiểu dữ liệu
Cơ sở dữ liệu cassandra có cấu trúc dữ liệu hướng cột và lược đồ động. Tức là
không giống như cơ sở dữ liệu quan hệ, chúng ta không cần định dạng tất cả các cột dữ
liệu mà ứng dụng đòi hỏi lên trước, mỗi một hàng không cần phải có các cột giống nhau.
Cột và dữ liệu của nó có thể được thêm vào bởi ứng dụng mà không bị gián đoạn.
3.1. Keyspace
Trong cassandra, keyspace là không gian lưu trữ dữ liệu, giống như lược đồ trong
cơ sở dữ liệu quan hệ. Keyspace được sử dụng với chức năng nhóm các gia đình cột lại
với nhau. Thông thường một ứng dụng có một keyspace.
Các bản sao được kiểm soát trên một keyspace, vì vậy dữ liệu có các bản sao khác
nhau thì yêu cầu phải nằm trên keyspace khác nhau. Keyspaces không được thiết kế để sử
dụng như lớp bản đồ trong mô hình dữ liệu, nó chỉ như là một cách để kiểm soát việc sao
chép cho một tập các gia đình cột.
Câu lệnh để tạo một keyspace trong cassandra.
CREATE KEYSPACE keyspace_name WITH
placement_strategy = 'SimpleStrategy'
AND strategy_options = [{replication_factor:2}];
19
3.2. Column family
Khi so sánh Cassandra với cơ sở dữ liệu quan hệ, gia đình cột giống như một bảng trong

cơ sơ dữ liệu quan hệ, nó cũng bao gồm các hàng, các cột. Tuy nhiên, một gia đình cột về
cơ bản khá khác so với cơ sở dữ liệu quan hệ.
Trong một cơ sở dữ liệu quan hệ, ta phải xác định các bảng, trong đó định nghĩa các cột,
và dữ liệu của chúng, từ đó có một lược đồ quan hệ, mà đòi hỏi mỗi hàng chứa cùng một
tập hợp cột cố định.
Gia đình cột trong Cassandra, có thể gọi là siêu dư liệu về các cột, tức là mỗi hàng có thể
chứa các bộ phận khác nhau của cột. Như vậy, có thể nói rằng gia đình cột rất linh hoạt,
trong thực tế gia đình cột không hoàn toàn là một lược đồ yếu. Mỗi gia đình cột được
thiết kế chứa một loại dữ liệu duy nhất. Có hai mẫu cột gia đình điển hình trong
Cassandra, đó là cột gia đình tĩnh và cột gia đình động.
Một gia đình cột tĩnh là sử dụng một tập hợp có tên cột tương đối tĩnh và tương tự như
một bảng dữ liệu quan hệ. Ví dụ: Một cột gia đình lưu trữ dữ liệu người dùng có thể có
các cột cho tên người dùng, địa chỉ, email, số điện thoại. Mặc dù nói chung các hàng sẽ có
cùng một tập hợp các cột, nhưng chung không đòi hỏi phải định nghĩa tất cả các cột. Cột
gia đình tĩnh thường mỗi cột được định nghĩa trước.
Một gia đình cột động, là các cột được tùy ý theo yêu cầu của ứng dụng. Một gia đình cột
động cho phép chúng ta trước khi tính toán kết quả và lưu dữ chúng trong một hàng duy
nhất để có thể truy vấn dữ liệu một cách hiệu quả. Mỗi hàng là một bản sao của dữ liệu,
được sắp xếp. Ví dụ: Một gia đình cột theo dõi người đăng nhập vào blog cá nhân của họ.
20
Thay vì xác định dữ liệu cho từng cột, gia đình cột động xác định loại thông tin cho tên
cột và giá trị (so sánh và xác nhận), nhưng tên cột và giá trị thực tế được tạo bởi ứng dụng
khi một cột được insert dữ liệu.
Trong tất cả các cột gia đình, mỗi một hàng được xác định bởi row key của nó, tương tự
như các khóa chính trong bảng quan hệ. Một cột gia đình luôn được phân vùng trên row
key của nó và row key thường mặc nhiên là chỉ mục.
3.3. Cột (Column)
Cột là đơn vị nhỏ nhất của Cassandra. Nó là một bộ chứa tên, giá trị và timestamp.
Một cột phải có tên và tên có thể là một nhãn tĩnh (như “tên” hoặc “tên emal”), hoặc nó
có thể tự động được thiết lập theo yêu cầu của ứng dụng.

Cột có thể được lập chỉ mục theo tên của chúng. Tuy nhiên, một hạn chế là chỉ số cột sẽ
không hỗ trợ các truy vấn yêu cầu truy cập dữ liệu, chẳng hạn như dữ liệu chuỗi thời gian.
Trong trường hợp này, một chỉ số phụ dựa trên cột timestamp sẽ không đầy đủ , bởi vì ta
không kiểm soát sự sắp xếp của các chỉ số phụ. Đối với trường hợp việc sắp xếp là quan
trọng, ta sẽ duy trì một gia đình cột như là một “chỉ số” mà có thể tạo ra cách khác để tra
cứu dữ liệu trong thứ tự sắp xếp.
Cassandra không đòi hỏi một cột phải có giá trị. Đôi khi tất cả các thông tin ứng dụng,
cần để đáp ứng một truy vấn có thể được lưu trữ trong tên cột riêng của chính nó. Ví dụ,
nếu bạn đang sử dụng một gia đình cột như là một khung nhìn để tra cứu các hàng trong
gia đình cột khác, ta cần phải lưu trữ các row key mà bạn đang tìm kiếm, giá trị có thể là
rỗng.
Cassandra sử dụng timestamp để xác định những cột được cập nhật gần đây nhất.
Timestamp được tạo ra bởi các ứng dụng khách. Các timestamp mới nhất luôn được ưu
21
tiên khi truy vấn dữ liệu, do đó nếu nhiều client đồng thời cập nhật các cột trong một
hàng, bản cập nhật gần nhất là một trong những bản sẽ tồn tại cuối cùng.
3.4. Các cột đặc biệt trong cassandra
Cassandra có ba cột đặc biệt là Counter, Expiring, Super.
3.4.1. Cột Expiring
Một cột cũng có thể đến ngày hết hạn tùy thuộc vào giá trị TTL (time to live). Bất cứ một
cột nào được tạo ra đều có thể chỉ định một TTL (thời gian sống) tùy chọn, có thể xác
định trong một vài giây. Cột TTL được đánh dấu là bị xóa sau khi hết khoảng thời gian đã
quy định cho nó. Một khi đã được đánh dấu, chúng sẽ tự động bị loại.
3.4.2. Cột counter
Cột này sử dụng để lưu trữ số lượt xuất hiện của một sự kiện hoặc một quá trình. Ví dụ:
Có thể sử dụng một cột truy cập để đếm số lần một trang được xem.
Cột column sẽ xác định số lần truy cập khác nhau, ứng dụng client cập nhật giá trị cột
bằng cách tăng hoặc giảm. Các ứng dụng client có thể cập nhật một cột counter bằng tên
cái mà nó định đếm và đặt giá trị tăng hoặc giảm, không đòi hỏi timestamp.
3.4.3. Cột super

Gia đình cột có thể bao gồm cột bình thường hoặc cột super, loại cột thêm vào mức lồng
nhau trong cấu trục gia đình cột bình thường. Cột super bao gồm tên cột và bản đồ lệnh
cho các cột con. Một super có thể xác định lệnh so sánh cho tên của nó và cho cả tên cột
con.
Ngoài ra, có thể hiểu một cột super là cách để nhóm nhiều cột dựa trên giá trị tìm kiếm.
Ví dụ: Ta muốn tạo ra hai cái nhìn cụ thể về blog và bloger.
22
Một hạn chế của việc sử dụng cột super là chỉ có thể đọc được một giá trị trong cột con
của nó và không thể tạo ra được một chỉ mục thứ hai trong cột con. Vì vậy, sử dụng cột
super tốt nhất trong trường hợp số lượng cột con là tương đối nhỏ.
3.5. Kiểu dữ liệu trong cassandra
Trong cơ sở dũ liệu quan hệ, chung ta phải chỉ định một kiểu dữ liệu cho mỗi cột. Và hạn
chế các loại dữ liệu khác chèn vào cột đó. Ví dụ: Nếu chúng ta định nghĩa một cột kiểu số
nguyên, ta sẽ không thể chèn được một dữ liệu là ký tự. Tên cột trong cơ sở dữ liệu quan
hệ thường cố định và làm cơ sở để xác định lược đồ quan hệ.
Trong cassandra, các kiểu dữ liệu cho cột được xác định từ trước. Và không yêu cầu
người dùng trước khi tạo cột phải định nghĩa kiểu dữ liệu. Cassandra lưu trữ tên cột và giá
trị dưới dạng mảng hex byte (kiểu byte). Đây là kiểu mặc định khi người sử dụng không
định kiểu cho dữ liệu.
Các kiểu dữ liệu trong cassandra:
Internal Type CQL Name Description
BytesType blob Arbitrary hexadecimal bytes (no validation)
AsciiType ascii US-ASCII character string
UTF8Type text, varchar UTF-8 encoded string
IntegerType varint Arbitrary-precision integer
LongType int, bigint 8-byte long
UUIDType uuid Type 1 or type 4 UUID
DateType timestamp Date plus time, encoded as 8 bytes since epoch
BooleanType boolean true or false
FloatType float 4-byte floating point

DoubleType double 8-byte floating point
23
Internal Type CQL Name Description
DecimalType decimal Variable-precision decimal
CounterColumnTyp
e
counter Distributed count
4. Quản lý và truy cập dữ liệu trong Cassandra
Phần này cung cấp thông tin về truy cập và quản lý dữ liệu trong Cassandra thông
qua một ứng dụng của máy khách. Cassandra cung cấp rất nhiều tiện ích cho người
dùng và các giao diện lập trình ứng dụng (API) có thể được sử dụng để phát triển các ứng
dụng tận dụng Cassandra cho việc lưu trữ và phục hồi dữ liệu.
4.1. Ghi dữ liệu trong Cassandra
Cassandra được tối ưu hóa cho việc ghi các dữ liệu có sẵn một cách nhanh chóng và mang
lại hiêu quả cao. Cơ sở dữ liệu quan hệ thường được cấu trúc dạng bảng để hạn chế tối
thiểu việc sao chép dữ liệu. Các phần của thông tin cần thiết để đáp ứng một truy
vấn được lưu trữ trong các bảng liên quan tuân theo một cấu trúc được định sẵn. Do
dữ liệu được cấu trúc trong một cơ sở dữ liệu quan hệ nên việc ghi dữ liệu sẽ phức tạp
hơn, như là việc máy chủ cơ sở dữ liệu phải kèm thêm việc đảm bảo toàn vẹn dữ
liệu trên các bảng có liên kết. Kết quả là, cơ sở dữ liệu quan hệ thường không có hiệu suất
tốt cho việc ghi dữ liệu.
Cassandra được tối ưu hóa thông qua việc ghi dữ liệu. Đầu tiên Cassandra ghi vào một
nhật ký uỷ thác (để lưu trữ lâu dài), và sau đó ghi vào một cấu trúc bảng trong bộ nhớ
được gọi là một Memtable. Việc ghi thành công một khi nó được ghi vào nhật ký uỷ
thác và bộ nhớ, do đó rất tối thiểu đĩa I/O tại thời điểm ghi. Ghi theo đoạn trong bộ nhớ
và định kỳ ghi vào đĩa để được một cấu trúc bảng liên tục gọi là một SSTable (chuỗi bảng
được sắp xếp). Memtables và SSTables được duy trì cho mỗi Column family. Memtables
được tổ chức trong việc sắp xếp bởi khoá của hàng và chuyển vào SSTables tuần
tự (không tìm kiếm ngẫu nhiên như trong cơ sở dữ liệu quan hệ).
4.2. Nén dữ liệu

Bên dưới, Cassandra định kỳ kết hợp SSTables lại với nhau thành SSTables lớn hơn bằng
cách sử dụng một quá trình được gọi là nén. Nén kết hợp các mảng hàng với nhau, loại bỏ
các tombstones hết hạn (cột đã bị xoá), và xây dựng lại các chỉ số sơ cấp và thứ cấp. Hợp
nhất này đạt hiệu quả cao nhất khi SSTables được sắp xếp theo khoá hàng. Một khi một
24
SSTable mới sáp nhập hoàn tất, SSTables đầu vào được đánh dấu đã cũ và
cuối cùng được xoá bởi bộ thu dọn JVM (Java Virtual Machine).
Dữ liệu nén được đọc theo hai cách.Trong khi quá trình nén đang diễn ra, việc đọc dữ liệu
vẫn có thể thực hiện với hiệu suất cao mà không cần thông quan bộ nhớ tạm (việc này
tạm thời làm tăng dung lượng đĩa I/O cần dùng). Tuy nhiên, sau khi quá trình nén đã được
hoàn thành, bộ nhớ tạm được dùng để cải thiện hiệu suất đọc và khi đó cũng có ít các tập
tin SSTable trên đĩa cần được kiểm tra để hoàn thành việc đọc hơn, khả năng đọc sẽ tốt
hơn.
4.3. Kiểm soát các toàn tác và truy cập đồng thời
Không giống như các cơ sở dữ liệu quan hệ, Cassandra không cung cấp đầy đủ các giao
dịch toàn tác ACID. Không có khóa truy cập (có nghĩa là khoá khả năng truy cập của đối
tượng đang thao tác) hoặc giao dịch toàn tác khi đồng thời cập nhật nhiều hàng hoặc cột
(giao dịch toàn tác – transaction, khi một lệnh trong giao dịch thất bại, có thể quay lại tình
trạng dữ liệu khi bắt đầu giao dịch)
4.4. Chèn và cập nhật
Các cột với số lượng lớn có thể được chèn vào cùng một lúc. Khi chèn hoặc cập
nhật các cột trong một Column family, ứng dụng cụ thể hoá các khoá dòng
để xác định cột nào được cập nhật. Khoá dòng tương tự như một khóa chính ở chỗ
nó phải là duy nhất cho mỗi hàng trong một Column family. Tuy
nhiên, không giống như một khóa chính, chèn một khoá hàng trùng lặp sẽ không bị cản
trở như khi thêm một khoá chính trùng lặp, mà nó sẽ được xử lý là UPSERT (kết hợp của
Update và Insert - cập nhật nếu cột đó đã tồn tại hoặc thêm mới nếu cột đó chưa tồn tại).
Cột chỉ ghi đè nếu các timestamps trong bản ghi mới sớm hơn so với cột hiện có,
timestamps chính xác là cần thiết nếu được thường xuyên cập nhật (ghi đè). Timestamps
được cung cấp bởi khách hàng. Do đó, các đồng hồ của tất cả các máy khách

hàng nên được đồng bộ bằng cách sử dụng NTP – Network Time Protocol (giao thức thời
gian mạng).
4.5. Xoá dữ liệu
Khi xóa một hàng hoặc một cột trong Cassandra, có một số điều cần lưu ý rằng có thể
khác với những gì người ta mong đợi ở một cơ sở dữ liệu quan hệ.
Dữ liệu bị xoá sẽ không bị loại bỏ khỏi đĩa ngay lập tức, do trong Cassandra dữ liệu luôn
luôn nằm trên đĩa dưới dạng SStable. Một khi dữ liệu dạng SStable đã được ghi trên đĩa
thì ngôn ngữ xử lí dữ liệu cũng không có tác động gì tới nó được nữa. Có nghĩa là 1 cột bị
xoá sẽ không bị loại bỏ ngay mà thay vào đó 1 nhãn đánh dấu được gọi là tombstone chỉ
trạng thái của cột (là đã xoá). Các cột được đánh dấu bằng tombstone sẽ được duy trì
25