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

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

LỜI CAM ĐOAN

Tôi cam đoan rằng, ngoại trừ các kết quả tham khảo từ các công trình khác như đã ghi

rõ trong luận văn, các công việc trình bày trong luận văn này là do chính tôi thực hiện

và chưa có phần nội dung nào của luận văn này được nộp để lấy một bằng cấp ở trường này hoặc trường khác

Ngày 6 tháng 1 năm 2008,Phan Nhật Hải – Nguyễn Hoàng Anh

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

KHOA HỆ THỐN THÔNG TIN

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

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

mà bài báo cáo này chưa đề cập đến

MỤC LỤC

TÓM TẮT 2

MỤC LỤC 3

DANH MỤC HÌNH 5

DANH MỤC BẢNG 6

Chương 1 GIỚI THIỆU 6

1.1 Khái niệm 6

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

1.2.1 Tính phân tán 7

1.2.2 Tính co giãn (Elastic Scalability) 7

1.2.3 Tính hướng cột (Column-Oriented) 7

1.2.4 Tính sẵn sàng cao (Highly Availability) 7

1.2.5 Chấp nhận sai (Fault Tolerant) 7

1.3 Mục đích của báo cáo 7

1.4 Cấu trúc bài báo cáo: 8

Chương 2 KIẾN TRÚC CASSANDRA 9

2.1 Giao tiếp giữa các node (Gossip) 9

2.1.1 Hiểu về cluster membership và seed nodes 9

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

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

2.2.1 Hiểu về phân vùng dữ liệu 11

2.2.2 Các loại phân vùng 12

Random Partitioner 12

Ordered Partitioners 12

2.3 Hiểu về Snitches 13

2.4 Hiểu về Replica Placement Strategy 13

2.4.1 SimpleStrategy 13

2.4.2 NetworkTopologyStrategy 14

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

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

2.5.2 Hiểu về yêu cầu đọc 15

Chương 3 MÔ HÌNH DỮ LIỆU CASSANDRA 17

3.1 So sánh với RDBMS 17

3.2 Keyspace 19

3.3 Column family 20

3.3.1 Hiểu về column 21

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

3.3.3 Kiểu dữ liệu 22

3.4 Index trong Cassandra 23

3.4.1 Primary index 23

3.4.2 Secondary index 23

Chương 4 QUẢN LÝ VÀ TRUY XUẤT DỮ LIỆU 25

4.1 Hiểu về ghi trong Cassandra 25

4.1.1 Hiểu về Compaction 26

4.1.2 Quản lý giao tác và truy suất đồng thời 26

4.1.3 Hiểu về Inserts và Updates 27

4.1.4 About Deletes 27

4.1.5 Hiểu về ghi vào Hinted Handoff 28

4.2 Hiểu về đọc trong Cassandra 29

4.3 Hiểu về nhất quán dữ liệu trong Cassandra 30

4.3.1 Tùy chỉnh tính nhất quán cho những request của client 30

Nhất quán ghi 30

4.3.2 Những tính năng chỉnh sauaw tính nhất quán được xây dựng sẵn trong Cassandra .31

Cassandra có một vài tính năng được xây dựng sẵn để đảm bảo rằng dữ liệu vẫn còn nhất quá thông qua nhiều bản sao 31

4.4 Client APIs cho Cassandra 32

4.4.1 Cassandra CLI (Command-line Interface) 32

4.4.2 CQL (Cassandra Query Language) 32

4.4.3 Những client cho Cassandra ở cấp độ cao khác 32

Chương 5 NHỮNG HOẠT ĐỘNG TRONG CASSANDRA 33

5.1 Tùy chỉnh trong Cassandra 33

5.1.1 Tùy chỉnh cache 33

Cách cache hoạt động 33

Cấu hình key cache cho Column Family 33

Cấu hình row cache cho Column Family 34

5.2 Backup và Restore dữ liệu 34

5.2.1 Tạo Snapshot 34

5.2.2 Xóa file Snapshot 35

5.2.3 Cấu hình thông số Incremental Backups 35

5.2.4 Restore từ một Snapshot 36

Chương 6 CLI VÀ CQL 37

6.1 Command-Line Interface (CLI) 37

6.1.1 Tạo một Keyspace 37

6.1.2 Tạo một Column Family 38

6.1.3 Thêm Row và Column 38

6.1.4 Đọc Rows và Columns 39

6.1.5 Index một Column 40

6.1.6 Xóa Rows và Columns 40

6.1.7 Drop một Column Families và Keyspaces 40

6.2 Cassandra Query Language (CQL) 40

6.2.1 Khởi động chương trình CQL(cqlsh) 41

6.2.2 Chạy lệnh CQL bang cqlsh 41

Tạo một Column Family 41

Insert và Retrieve Columns 41

Thêm Column với ALTER COLUMNFAMILY 42

Thay đổi metadata của column 42

Xóa metadata của column 42

Tạo Index cho một Column 42

Xóa Column và Row 43

Xóa Column Family và Keyspaces 43

Tham khảo 43

44

44

DANH MỤC HÌNH

DANH MỤC BẢNG

Ngày nay, các dịch vụ trên internet phải xử lý một khối lượng dữ liệu rất lớn Hầu hết dữ liệu sẽ được lưu trữ phân tán trên nhiều máy chủ khác nhau Vì vậy, các

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

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

để sử lý một khối lượng lớn dữ liệu giàn trải trên nhiều node mà vẫn đảm bảo tính sẵn sàng cao (Highly Availability), khả năng mở rộng hay thu giảm số node linh hoạt (Elastic Scalability) và chấp nhận một số sai sót (Fault Tolerant) Nó được phát triển bởi Facebook và vẫn còn tiếp tục phát triển và sử dụng cho mạng xã hội lớn nhất thới giới này Năm 2008, Facebook chuyển nó cho cộng đồng mã nguồn mỡ và được

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

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

1.2.1 Tính phân tán

Khả năng phân chia dữ liệu thành nhiều phần đặt trên nhiều node khác nhau trong khi người dùng vẫn thấy được dữ liệu này là một khối hợp nhất

1.2.2 Tính co giãn (Elastic Scalability)

Khả năng của hệ thống có thể mở rộng số node trong cluster để có thể phục vụ một số lượng request đến nhiều và thu giảm số node khi số lượng request đến ít

1.2.3 Tính hướng cột (Column-Oriented)

Các RDBMS hướng dòng (row-oriented) phải định nghĩa trước các cột (column) trong các bảng (table) Đối với Cassandra các bạn không phải làm điều đó, đơn giản là thêm vào bao nhiêu cột cũng được tùy theo nhu cầu của bạn

1.2.4 Tính sẵn sàng cao (Highly Availability)

Dữ liệu được chia làm nhiều bản sao lưu ở nhiều node nên khi client thực hiện tác vụ đọc/ghi thì Cassandra có thể đáp ứng ngay lập tức bằng cách thực hiện trên bản sao gần nhất hoặc trên tất cả các bản sao (phụ thuộc vào thông số ConsitencyLevel do client thiết lập)

1.2.5 Chấp nhận sai (Fault Tolerant)

Dữ liệu của bạn đẽ được sao chép thành nhiều bản trên các node của cluster Nếu chẳng may một node nào đó bị hỏng, bạn vẫn có thể truy xuất dữ liệu của bạn trên các node khác

1.3 Mục đích của báo cáo

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

• Kiến trúc bên trong của Cassandra

• Mô hình dữ liệu trong Cassandra.

• Đọc/ghi trong Cassandra

• Index trong Cassandra

• Sử lý giao tác, nhất quán dữ liệu, truy suất đồng thời trong Cassandra

• Ngôn ngữ truy vấn của Cassandra

Đó là những vấn đề cần phải xem xét khi tìm hiểu một hệ quản trị cơ sở dữ liệu Ngoài ra còn có một số vấn đề đặc trưng riêng của hệ phân tán cũng được bàn đến như phương thức trao đổi thông điệp giữa các node, phương thức phân chia dữ liệu giữa các node, …

1.4 Cấu trúc bài báo cáo:

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

Chương 2 trình bày kiến trúc của Cassandra

Chương 3 trình bày mô hình dữ liệu của cassandra

Chương 4 trình bày cách quản lý và truy xuất dữ liệu trong cassandra

Chương 5 trình bày các hoạt động diễn ra trong cassandra

Chương 6 trình bày ngôn ngữ truy vấn trong Cassandra (CQL) và giao diện lập trình bằng dòng lệnh (CLI)

Chương 2 KIẾN TRÚC CASSANDRA

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

2.1 Giao tiếp giữa các node (Gossip)

Cassandra sử dụng một giao thức gọi là gossip để tìm ra thông tin về trạng thái

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

nó cho những node khác trong cluster và ngược lại

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

2.1.1 Hiểu về cluster membership và seed nodes

Khi một node được khởi động, nó sẽ xem file cấu hình của nó để biết tên của cluster và những node khác trong cluster, quá trình này gọi là seed nodes Những cấu

hình này được đặt trong file cassandra.yaml

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

quan trọng nhất cho lần đầu tiên node khởi động.

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

2.1.2 Hiểu về Failure Detection và Recovery

Failure Detection là phương pháp cho mỗi node để xác định các node khác trong hệ thống đang hoạt động hay không Thông tin của Failure Detection dùng bởi Cassandra để tránh định tuyến những yêu cầu của người dùng đến những node không hoạt động này Nó cùng dùng để tránh định tuyến đến những node vẫn còn hoạt động nhưng có hiệu suất thấp

Quá trình gossip theo dõi hoạt động của các node dưới dạng trực tiếp (thông qua những node gossip trực tiếp đến nó) hoặc gián tiếp Suốt quá trình gossip, mỗi node sẽ duy trì một khoảng thời gian (interval) để cứ sau một khoảng thời gian đó thì

nó lại theo dõi một lần (quá trình gossip được chạy)

Sự hư hỏng của node có thể là kết quả từ nhiều nguyên nhân như là hư phần cứng, mạng ngừng hoạt động Node ngừng hoạt động thường là ngắn thôi nhưng nó cũng kéo dài trong nhiều interval.Một node ngừng hoạt động nhưng chưa được phát hiện ra thì những node khác vẫn cứ định kì gossip với nó Để thay đổi vĩnh viễn membership giữa các node trong cluster người quản trị phải chỉnh sửa tường minh từ

casssnadra cluster sử dụng tiện ích nodetool

Khi một node hoạt động trở lại từ trạng thái ngừng, nó có thể thiếu những bản sao dữ liệu mà trong lúc nó ngừng hoạt động được các node khác chuyển đến Khi Failure Detection đánh dấu một node là ngừng hoạt động thì việc những bản sao bị

thiếu sẽ được ghi vào những node khác nếu hinted handoff được enable Mặc dầu vậy,

có thể có một số bản sao bị mất giữa trong khoảng thời gian từ khi một node ngừng hoạt động đến khi nó được nhận dạng là không hoạt động Hoặc nếu một node ngừng

hoạt động lâu hơn một khoảng thời gian cấu hình trong max_hint_window_in_ms

hints sẽ không được ghi lại những bản sao bị mất Vì lý do đó nên cách tốt nhất trong

thực tế là chạy tiện ích nodetool repair định kì trên mỗi node để đảm bảo dữ liệu nhất

quán và cũng nên chạy repair sau khi phục hồi lại một node vừa bị ngừng hoạt động

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

Cassandra 2.2.1 Hiểu về phân vùng dữ liệu

Khi bạn khởi động một Cassandra cluster, bạn phải chọn cách để dữ liệu phân chia giữa các node trong cluster Đây được gọi là chọn cách phân vùng cho cluster

Trong Cassandra, tổng dữ liệu được quản lý bởi cluster được biểu diễn như một vòng (ring) Vòng được phân chia thành những khoảng bằng nhau cho tổng số node với mỗi node chịu trách nhiệm cho một hoặc một vài khoảng Trước khi một node có thể join vào một vòng, nó phải được gán một token Token quyết định vị trí của node trong vòng và khoảng dữ liệu nó sẽ chịu trách nhiệm

Dữ liệu của Column family được phân vùng dựa vào khóa của dùng (row key)

Ví dụ một cluster với 4 node với row key quản lý bởi cluster được đánh số từ 0-100 Mỗi node được gán 1 token đại diện cho nó trong vòng Trong ví dụ này, giá trị token

là 0, 25, 50, 75 Node đầu tiên với token 0 chịu trách nhiệm cho khoảng từ (75-0), tương tự cho các token tiếp theo

2.2.2 Các loại phân vùng

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

Cassandra hỗ trợ một số partitioner, nhưng mặt đinh Random Partitioner là lựa chọn tốt nhất cho hầu hết các triển khai thực tế của Cassandra

• Random Partitioner

Random Partitioner là loại phân vùng mặc định trong Cassandra Random partitioner sử dụng phương pháp băm để quyết định node nào sẽ lưu trữ một dòng phân biệt của dữ liệu không giống như phương pháp lấy số dư theo node Phương pháp băm đảm bảo rằng khi những node được thêm vào hay lấy khỏi cluster thì dữ liệu vẫn được phân bố đồng đều giữa các node

Để phân tán dữ liệu thông qua tập node, giải thuật hashing tạo một giá trị hash MD5 của row key trong phạm vi giá trị từ 0 đến 2127 Mỗi node trong cluster được gán một token đại diện cho nó Một node sau đó sẽ lưu trữ một khoảng những giá trị hash nhỏ hơn token

Lợi ích chính của cách tiếp cận này là một khi token được khởi tạo thích hợp,

dữ liệu từ tất cả các column family của bạn sẽ được phân tán đồng đều giữa các node trong cluster mà ko cần tốn nhiều công sức Ví dụ, một column family có thể

dùng username như là row key và column family khác là timestamp, nhưng row

key từ mỗi column family đơn sẽ vẫn được phân tán đồng đều giúp việc đọc ghi được phân tán đồng đều giữa các node

Lợi ích khác của dùng random partitioner là đơn giản hóa load balancing trong cluster Bởi vì mỗi phần của range hash sẽ nhận một số bằng nhau của row, dễ dàng gán một row cho một node mới

• Ordered Partitioners

Dùng cái này có thể đảm bảo row key được lưu trữ theo thứ tự đã sắp xếp

Dùng cái này có thể cho phép truy vấn một khoảng theo dòng như index truyền

thống Ví dụ nếu ứng dụng của bạn dùng username để làm row key thì bạn có thể

scan dòng cho những user nằm giữa Jake và Joe Cái này thì không thể trong random khi mà thứ tự sắp xếp không biết được

Ta có thể thiết kế dữ liệu sao cho vẫn có thể thực hiện những câu truy vấn khoảng trên tập cột hơn là tập dòng

2.3 Hiểu về Snitches

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

Snitch được cấu hình trong Cassandra.yaml Tất cả các node trong cluster nên dùng cùng một cấu hình snitch

Có nhiều loại snitch khác nhau: SimpleSnitch, DseSimpleSnitch, RackInferringSnitch, PropertyFileSnitch, EC2Snitch, EC2MultiRegionSnitch

2.4 Hiểu về Replica Placement Strategy

Replica Placement là một loại cấu hình khi bạn tạo keyspace quyết định vị trí của những bản sao cho keyspace phân tán trong cluster

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

2.4.1 SimpleStrategy

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

2.4.2 NetworkTopologyStrategy

Được dùng khi bạn có thông tin về cách các node được nhóm trong cluster của bạn hoặc bạn có cluster của bạn triển khai trên nhiều cluster Cái này cho phép bạn đặt

tả có bao nhiêu bản sao bạn muốn trong mỗi cluster

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

Cassandra

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

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

Cho tác vụ ghi, coordinator sẽ gửi cái này đến tất cả các node chứa row được ghi Miễn là tất cả các node chứa bản sao hoạt động và sẵn sàng, chúng sẽ nhận tác vụ

ghi bất kể thông số consistent level của client đặc tả gì đi chăng nữa Consistent level

quyết định có bao nhiêu node bản sao phải phản hồi để xem như là tác vụ đó thành công hay chưa

Ví dụ, trong một cluster có 10 node như trên với replication_factor là 3 và tác

vụ ghi đến cả 3 node sở hữu dòng được yêu cầu Nếu consistent level đặc tả là ONE thì

khi một node ghi xong sẽ phản hồi lại coordinator và coordinator sẽ phản hồi cho client là thành công

2.5.2 Hiểu về yêu cầu đọc

Có hai loại request đọc, một là request trực tiếp, hai là read repair request Số

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

Read repair request được gửi cho những bản sao còn lại những cái mà không nhận request trực tiếp Read repair request đảm bảo rằng tất cả các dòng được request nhất quán với nhau

Vì vậy coordinator sẽ tiếp xúc với bản sao đầu tiên đặc tả bởi consistent level

Coordinator sẽ gửi những request này cho các bản sao Dòng của mỗi bản sao sẽ được

so sánh trong bộ nhớ để xem xét sự nhất quán dữ liệu của chúng Nếu chúng không nhất quán thì dữ liệu của dòng nào gần nhất sẽ được coordinator chuyển lại cho client sau

Để đảm bảo rằng tất cả bản sao có phiên bản gần nhất của dữ liệu đọc thường xuyên Coordinatior cũng liên lạc và so sánh dữ liệu từ tất cả các bản sao còn lại và nếu chúng không nhất quán thì việc ghi để update dòng để phản ánh giá trị viết gần đây nhất Process này được gọi là read repair Nó được cấu hình theo cột và được enable mặc định

Ví dụ, trong một cluster với replication factor là 3 và consistency level là QUORUM Hai trong số ba bản sao của row sẽ tiếp xúc trọn vẹn với read request Giả

sử những bản sao được tiếp xúc có những phiên bản khác nhau của row, bản sao với phiên bản mới nhất sẽ được trả về cho client Trong background, bản sao thứ ba được kiểm tra tính nhất quán với hai cái đầu tiên và nếu cần, bản sao với phiên bản gần nhất

sẽ cập nhật bản sao thứ ba này

Chương 3 MÔ HÌNH DỮ LIỆU

CASSANDRA

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

là khóa ngoại trong bảng blog_entry Dùng mô hình quan hệ này, Câu truy vấn SQL

có thể thực hiện kết trên nhiều bảng để trả lời cho những câu hỏi

Trong Cassandra Keyspace là cái chứa đựng dữ liệu ứng dụng của bạn, tương

tự như database hay schema trong RDBMS Bên trong keyspace là một hoặc nhiều colum family, cái cũng được hiểu như là các bảng Column family chứa các column và một tập những cột có liên quan với nhau được định nghĩa bởi một row key Mỗi row trong một column family ko yêu cầu phải có cùng số cột

Cassandra không bắt buộc có mối quan hệ giữa các column family như cách mà RDBMS làm giữa các bảng Không có khóa ngoại trong Cassandra Không hỗ trợ kết các column family tại thời điểm truy vấn Mỗi column family sẽ có một tập những cột cho phép liên kết những bảng lại để lấy thông tin khi câu truy vấn được thực hiện

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

3.2 Keyspace

Trong cassandra keyspace để chứa đựng dữ liệu ứng dụng của bạn, tương tự schema trong RDBMS Keyspace dùng để nhóm những column family với nhau Một cluster có một keyspace cho một ứng dụng

Replication để điều khiển … Trong ngôn ngữ DDL hỗ trợ trong CLI hay CQL

Để định nghĩa một keyspace ta dùng như sau

CREATE KEYSPACE keyspace_name WITH

strategy_class = 'SimpleStrategy'

AND strategy_options:replication_factor=2;

số cột khác nhau

Mặc dù column family rất flexible, nhưng trong thực tế một column family không phải hoàn toàn là schema-less Mỗi column family nên được thiết kế để chứa một kiểu dữ liệu đơn Có 2 loại column family trong Cassandra là static và dynamic

Static column family dùng cho một tập tĩnh nhưng tên column có quan hệ với nhau và có nhiều sự tương đồng với RDBMS Ví dụ column family lưu trữ dữ liệu người dùng có thể có những cột cho tên người dùng, address, email, phone, …Mặc dầu dòng được khởi tạo có cùng một tập cột nhưng chúng không yêu cầu có tất cả những cột được định nghĩa Static column family điển hình cho loại có metadata của cột định nghĩa trước

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

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

Không yêu cầu phần value có giá trị Thỉnh thoảng tất cả những thông tin bạn cần để truy vấn nằm ở tên cột

Cassandra dùng timestamp để quyết định thời điểm update cột sau cùng Nếu một người dùng update lên cùng một cột đồng thời Update gần nhất sẽ được sử dụng

Nếu bạn muốn thay đổi TTL của một cột nào đó, bạn phải insert lại cột đó với một TTL mới Trong Cassandra tác vụ insert hay update là một, phụ thuộc vào version trước của cột đã hiện hữu hay chưa => việc update TTL cho một cột với một giá trị chưa biết đòi hỏi bạn phải đọc lại cột và reinsert với new TTL

• Counter Column

Counter là một đặc tả của cột dùng để lưu trữ một số cái mà sẽ tăng khi một sự kiện hay process xảy ra Ví dụ bạn có thể dùng counter column để đếm số lần page được xem

Counter column family phải dùng CounterColumnType như là validator (kiểu của giá trị cột)

Điểm khác biệt của cái này với những cái khác là ứng dụng có thể update giá trị cột bởi tăng hoặc giảm nó Update thông qua tên cột, giá trị cột (ko có timestamp)

• Supper Column

Column family có thể chứa đựng hoặc là column thông thường hoặc là supper column (mảng chứa chững super column nó bao gồm tên của super column và một ánh xan thứ tự các sub-column) Một super column có thể đặc tả một comparator lên cả super column name cũng như là sub-column name

Super column là cách để nhóm nhiều cột có mối quan hệ với nhau Ví dụ của việc sử dụng super column là giả sử bạn muốn tạo một Thêm 1 ví dụ ở đây

Giới hạn của super column là tất cả sub-column cảu super column phải xếp theo thứ tự Bạn không thể tạo secondary index lên sub-column của super-column Chỉ nên dùng super column khi số sub-column là nhỏ

3.3.3 Kiểu dữ liệu

Trong RDBMS, bạn phải đặc tả kiểu dữ liệu cho mỗi cột khi bạn định nghĩa bảng, và kiểu dữ liệu sẽ rang buộc kiểu dữ liệu được insert vào đó Tên cột trong