1

HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNGKHOA 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ínhM11CQCT01-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ếtdữ 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ụngthườ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ácgiao 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àythườ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áckhố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 đạidiệ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ụcphá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ínhkhi 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êncơ 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 Bigtablecủa Google. Được tạo ra bởi Facebook, nó được sử dụng phổ biến nhất tại một số sitestrê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 khixuấ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ấtnào. Tất cả các nút trong một cluster Cassandra hoạt động như nhau. Điều này đôi khigọilà “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ớ trongMySQL, Bigtable, và những nhiều hệ cơ sở dữ liệu khác.

Do đó, đặc điểm không tập trung hóa có hai ưu điểm quan trọng: nó đơn giản hơnsử dụng hơn mô hình chủ /tớ, và nó giúp bạn tránh việc hệ thống ngừng hoạt động. Vì cácnode 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ơnso 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, trongmộ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ềumaster. 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ônglà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ệucủ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 theochiề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útmớ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ặccấ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ạnkhô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ủacluster. 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 sangnề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ảibắ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ảirấ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àmgiả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ôngbá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ấtcứ 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 duynhấ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 baogồ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ànhtrong 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ácphầ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ệucung 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 đốimặ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ớinhấ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 trongkho 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 đượcthê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 đổigiữ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 2trong 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 đachiề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 quanhệ. 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ảiquyế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ữngtrườ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êmvà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ĩalà 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ó suynghĩ 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áctruy vấn xung quanh mô hình đó như trong hệ cơ sở dữ liệu quan hệ, bạn có thể tự donghĩ 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 columnfamily. 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 đưadữ 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. Thayvì 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ấpdữ liệu cho nó.

1.8 Hiệu năng caoCassandra đượ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ácghi 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ệunăng hoạt động.

10

2. Kiến trúc CassandraCassandra đượ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ộtcụ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ảithí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ộtgiao thức truyền thông ngang hàng, trong đó các nút định kỳ trao đổi thông tin trạng tháivề 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ôngbá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ảnthâ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ểuvề 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ằngcá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ụmCassandra 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útkhác trong cluster. điểm liên lạc của các cụm được cấu hình trong file cassandra.yaml chomỗ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 trongcluster 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ìnhcủ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ácnú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ể truycậ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ếptrực tiếp đến nó) và gián tiếp (thông tin có được khi nghe qua 2 nút, 3 nút …), Cassandrasử 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ốilượ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ềuchỉ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ìnhhuống, nhưng DataStax đề nghị tăng đến 12 cho Amazon EC2 do tắc nghẽn mạng thườngxuyê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ấtmạ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ệcsao 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ởicá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ảngthờ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ộtnú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ấtcả 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ộtnú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ẽ đượcchia 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ùngcho 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ộtkhô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ácnú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 khimộ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ủanú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ácnú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áchnhiệ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ảnlý 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 đạidiệ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ớithẻ 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âmdữ liệu dựa vào chính sách NetworkTopologyStrategy. Trong mỗi trung tâm dữ liệu (hoặcnhó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àigá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ệcdịch chuyển vòng theo chiều kim đồng hồ cho đến khi nó tìm được nút đầu tiên trongbá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 chomỗ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 đềutrong 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 chiathẻ 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ỗitrung 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 1cụm không được xung đột với nhau (mỗi node phải có một thẻ duy nhất). XemCalculating 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ùngchỉ 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ìnhphâ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ùngout-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 khaiCassandra.

Phân vùng ngẫu nhiên

RandomPartitioner là phân vùng đã mặc định cho một cụm Cassandra, và tronghầ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àmbă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ụngmodulus-by-node-count, hàm băm phù hợp đảm bảo rằng khi các nút được thêm vàocluster, 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úttrong 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 khaitrung 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ượngcá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 chomỗ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ânbả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ờigian 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ĩalà đọ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ằngtả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 trungbì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ânvù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ạncó 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ưutrữ 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ó xuhướ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ộtvấ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êucầ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ốikhó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 ứngvớ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 trongcù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ạnmuố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êntiế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) trongCassandra, 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áchnhữ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êncấ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 2có 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 requestNhư 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úttrong cluster. Tuy nhiên, có thể để tăng nhân tố nhân bản, và sau đó thêm số lượng mongmuố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ốikhô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 đượcthiế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êucủ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ảnSimpleStrategy 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àngmộ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ềukim đồ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ôngtin 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ặckế 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ạnxá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, xemxé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 đơnlẻ 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ấtquá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 nhucầ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ómnhâ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âmdữ 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 theocác phân vùng (giống như với SimpleStrategy). Bản sao sau đó trong cùng một trung tâmdữ 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 ở 1rack 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 saolê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ómvậ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âmdữ 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 trongTrung 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ácyê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ầugiữ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ặctrung 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ùngtrong đám mây công cộng) thường rơi vào loại này. Nếu sử dụng snitch, dùngreplication_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 Cassandrathờ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 Analyticshoặ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 địachỉ 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ủangười dùng trong file: cassandra-topology.properties. Snitch này là tốt nhất khi IP của cácnú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ìnhPropertyFileSnitch để biết thêm thông tin. Dùng Snitch này bạn có thể đặt tên trung tâmdữ 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áccluster 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. Khuvự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 trongtrung 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 đượckí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ácyê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òngsẽ 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ảnsao.

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àoconsistency level trong yêu cầu của client. Mức độ nhất quán ghi xác định có bao nhiêunú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 theoquy đị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ĩarằ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ệnphù 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ệcchọ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ácbả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êucầ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úttrong 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ảnhồ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ảnsao; 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ênhệ 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ởiClient. 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 truyvấ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ấtquá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 nhanhchó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àokhoả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 đọcthườ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 chophé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ả địnhrằ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

26

nhất quán so với hai bản sao trước, và nếu cần thiết, bản sao gần đây nhất sẽ sinh ra mộtlệnh ghi để cập nhật những phiên bản lỗi thời.

2.9 Lập kế hoạch triển khai cụm Cassandra

Khi lập kế hoạch triển khai cụm Cassandra, cần có một ý tưởng tốt về khối lượngban đầu của dữ liệu mà chúng ta cần lưu trữ và ước lượng tốt khả năng tải của ứng dụng.

2.9.1 Lựa chọn phần cứng cho cài đặt doanh nghiệp

Với bất cứ ứng dụng nào, việc lựa chọn phần cứng thích hợp phục thuộc vào việclựa chọn cân bằng của những tài nguyên sau: bộ nhớ, CPU, ổ cứng, số lượng nút và mạng.

• Bộ nhớ:

Nút Cassandra có càng nhiều bộ nhớ thì hiệu năng đọc càng tốt. Nhiều RAM hơn chophép kích cỡ Cache lớn hơn và giảm truy nhập vào / ra ổ cứng đối với lệnh đọc. Nhiềubộ nhớ RAM hơn cũng cho phép bảng bộ nhớ tổ chức nhiều dữ liệu ghi gần đây hơn.Bảng bộ nhớ càng lớn thì càng ít số lượng bảng SS bị đẩy vào ổ cứng và ít file quyetstrong suốt quá trình đọc. Số lương RAM lý tưởng phụ thuộc vào kích thước dự đoántrước được của dữ liệu nóng.

27

- Đối với phần cứng chuyên dụng, RAM có kích thước tối thiểu là 8GB là cần thiết.DataStax được tư vấn từ 16GB-32GB.- Khoảng trống heap JAVA nên được thiết lập tối đa là 8GB hoặc bằng ½ bộ nhớRAM, thậm chí thấp hơn.- Đối với môi trường ảo sử dụng tối thiểu là 4GB, như Amazon EC2.• CPU

Cassandra có tính đồng thời cao và sử dụng nhiều lõi CPU nhất có thể.

- Đối với phần cứng chuyên dụng, bộ vi xử lý 8 lõi là điểm tuyệt vời giữa hiệu năng vàgiá- Đối với những môi trường ảo, xem xét việc sử dụng một nhà cung cấp mà cho phépCPU có cơ chế truyền loạt như Rackspace Cloud Servers.• Ổ cứng

Cassandra ghi dữ liệu vào ổ cứng với 2 mục đích:

- Tất cả dữ liệu được ghi vào tệp lưu vết lâu dài- Khi các ngưỡng được đạt tới, Cassandra đẩy cấu trúc dữ liệu trong bộ nhớ vào cáctệp dữ liệu SSTable để lưu trữ lâu dài.

Bản ghi cam kết nhận được tất cả các lệnh ghi đến một nút Cassandra, nhưng chỉ đọctrong suốt thời gian nút khởi động. Bản ghi cam kết được giải phóng sau khi dữ liệutương ứng được đẩy vào. Nguợc lại, Các lệnh ghi SSTable (tập tin dữ liệu) được xảyra một cách không đồng bộ và được đọc trong suốt thời gian Client tìm kiếm. Ngoàira, SSTable định kỳ được gắn kết lại. Sự gắn kết lại cải thiện hiệu năng bằng việc nốivà ghi lại dữ liệu và bỏ qua dữ liệu cũ. Tuy nhiên, trong suốt quá trình gắn kết lại(hoặc sửa nút) sự tận dụng đĩa và kích thước thư mục dữ liệu có thể tăng lên đáng kể.Với lý do này, DataStax tư vấn để trống ra một số lượng khoảng trống đĩa rảnh rỗi chomỗi nút (50% [trường hợp xấu nhất] cho gắn kết lại từng cấp, 10% cho gắn kết lại sanlấp).

• Số lượng nútSố lượng lớn dữ liệu trên mỗi đĩa trong mảng không quan trọng bằng kích thướctổng mỗi nút. Việc sử dụng số lượng lớn của các nút nhỏ hơn tốt hơn việc sử dụngít các nút lớn hơn bởi vì sự cố thắt nút cổ chai trêncác nút lớn trong suốt quá trìnhgắn kết.

• MạngVì Cassandra là nơi lưu trữ dữ liệu phân tán, nên nó đặt tải trên mạng để xử lý cáctruy vấn đọc/ghi và các bản sao dữ liệu qua các nút mạng. Cassandra phải chắc

28

chắn rằng mạng có thể xử lý được giao thông mạng để tránh hiện tượng thắt nút cổtrai.

- Băng thông là 1000Mbit/s hoặc lớn hơn- Kết nối với giao diện Thrift (listen_address) tới NIC (Card giao diện mạng).- Kết nối giao diện máy chủ RPC (rpc_address) tới NIC khác.

Cassandra rất hiệu quả với những truy vấn định tuyến tới các nút bản sao mà gầnnhất về mặt vị trí địa lý với các nút điều phối để xử lý truy vấn. Cassandra sẽ nhặt nút bảnsao ở cùng giá nếu có thể và sẽ lựa chọn nút bản sao được đặt ở trong cùng trung tâm dữliệu so với những nút bản sao nằm ở trung tâm dữ liệu từ xa.

Cassandra sử dụng những cổng sau đây. Nếu sử dụng một tường lửa, thì phải chắcchắn rằng các nút trong một cụm có thể chuyển tới nút khác qua những cổng này.

Cổng Mô tả

Các cổng công cộng

22 SSH (mặc đinh)

Cổng đặc trưng OpsCenter

8888 Cổng website OpsCenter

Cổng nội bộ các nút

Cổng đặc trưng Cassandra

1024+ Cổng kết nối lại/quay vòng lặp JMX

7000 Cổng nội bộ các nút Cassandra

9160 Cổng giám sát JMX Cassandra

Cổng đặc trưng OpsCenter

50031 OpsCenter HTTP proxy đối với Job Tracker

61620 Cổng giám sát các nút nội bộ OpsCenter

61621 Cổng agent OpsCenter

• NútNhìn chung, khi bạn có tường lửa giữa các máy, rất khó để chạy JMX qua mộtmạng và bảo trì an ninh. Bởi vì kết nối JMX qua cổng 7199, bắt tay hai bên và

29

sau đó sử dụng bất cứ cồng nào trong dãy 1024+. Thay vì đó sử dụng SSH đểthực thi lệnh kết nối từ xa tới JMX cục bộ hoặc sử dụng DataStax OpsCenter.

2.9.2 Lập kế hoạch cho một cụm Amazon EC2

Các cụm Cassandra có thể được triển khai trên các hạ tầng đám mây như AmazonEC2.

Đối với các cụm Cassandra trên EC2, sử dụng trường hợp lớn hoặc rất lớn với nơilưu trữ cục bộ. RAID0, đặt cả thư mục dữ liệu và bản ghi cam kết trên cùng đĩa RAID0.Trong thực tế điều này đã chứng minh là tốt hơn đặc bản ghi cam kết trên đĩa gốc (nơi màtài nguyên dùng chung). Đối với dữ liệu dự phòng, xem xét việc triển khai cụm Cassandraqua nhiều vùng sẵn có và sử dụng đĩa EBS để lưu các tệp dữ liệu dự phòng Cassandra.

Đĩa EBS không được tư vấn để lưu trữ dữ liệu Cassandra – vì hiệu năng mạng vàtruy nhập vào ra đĩa không phù hợp với Cassandra vì những lý do sau:

- Đĩa EBS tranh đấu trực tiếp về thông lượng mạng với những gói tin chuẩn. Có nghĩalà thông lượng EBS có khả năng lỗi nếu bạn bão hòa một liên kết mạng.- Đĩa EBS có hiệu năng không tin cậy. Hiệu năng I/O có thể chậm một cách đặc biệt,gây ra cho hệ thống đọc và ghi lại đến tận khi toàn bộ cụm trở thành không phản hồi.- Việc tăng thêm công suất bằng cách tăng số lượng đĩa EBS cho mỗi máy chủ khôngmở rộng.

DataStax cung cấp một hình ảnh máy Amazon (AMI) cho phép bạn nhanh chóngtriển khai cụm Cassandra nhiều nút trên Amazon EC2. DataStax AMI khởi tạo tất cả cácnút trong một vùng sẵn có sử dụng SimpleSnitch.

Nếu bạn muốn một cụm EC2 mà mở rộng nhiều vùng và khu vực sẵn có, thì khôngsử dụng DataStaxAMI. Thay vì đó , khởi tạo EC2 cho mỗi nút Cassandra và sau đó cấuhình cụm như là một cụm trung tâm đa dữ liệu.

Tính toán dung lượng đĩa sử dụng

Để tính toán số lượng dữ liệu mà các nút Cassandra lưu trữ, tính toán dung lượngđĩa có thể sử dụng trên mỗi nút, và sau đó nhân với số lượng nút trong cụm. Nhớ rằngtrong một cụm, phạn sẽ có bản ghi cam kết và các thư mục dữ liệu trên các đĩa khác nhau.Tính toán này là cho việc ước lượng dung lượng sử dụng của khối lượng dữ liệu.

Bắt đầu với dung lượng thô của ổ đĩa vật lý:

raw_capacity = disk_size * number_of_disks

30

Tính toán cho hao phí định dạng hệ thống tập tin (khoảng 10%) và mức RAID đangsử dụng. Ví dụ, sử dụng RAID-10, tính toán sẽ là:

(raw_capacity * 0.9) / 2 = formatted_disk_space

Trong hoạt động thông thường, Cassandra thường xuyên yêu cầu dung lượng ổ đĩacho sự gắn kết lại và các hoạt động sửa chữa. Đối với hiệu suất tối ưu, DataStax khuyếncáo rằng bạn không nên dùng hết dung lượng ổ đĩa của bạn, nhưng có thể chạy ở 50-80%công suất. Vậy, tính toán cho không gian đĩa như sau (ví dụ sử dụng 50% công suất):

formatted_disk_space * 0.5 = usable_disk_space

Tính toán kích thước dữ liệu người dùng

Như với tất cả các hệ thống lưu trữ dữ liệu, kích thước của dữ liệu thô sẽ lớn hơnkhi dữ liệu được nạp vào trong Cassandra do hao phí lưu trữ. Trung bình, dữ liệu thô sẽlớn gấp khoảng 2 lần kích thước trên đĩa sau khi đã tải vào cơ sở dữ liệu, nhưng có thểnhỏ hơn hoặc lớn hơn nhiều phụ thuộc vào đặc trưng của dữ liệu và các thuộc tính cột.Tính toán trong phần này là tính toán cho dữ liệu ở trên đĩa chứ không phải dữ liệu lưutrong bộ nhớ.

- Hao phí cột: Mỗi cột trong Cassandra yêu cầu sử dụng 15 byte hao phí. Vì mỗi dòngtrong một cột thuộc tính có thể có tên các cột khác nhau cũng như giá trị của cột khácnhau, siêu dữ liệu được lưu trữ trong mỗi cột. Đối với cột đếm và cột hết hiệu lực,thêm 8 bít mở rộng. Vì thế tổng kích thước của một cột thông thường là:

total_column_size = column_name_size + column_value_size + 15- Hao phí dòng: Giống như cột, mỗi dòng cũng có hao phí khi lưu trữ trong ổ đĩa. Mỗidòng trong Cassandra có 23 byte hao phí.- Khóa chính: Mỗi cột cũng duy trì một chỉ số chính. Chi phí khóa chính trở nên quantrọng khi bạn có nhiều hàng gầy . Kích thước của khóa chính được ước lượng như sau(theo byte):

primary_key_index = number_of_rows * (32 + average_key_size)- Chi phí bản sao: Các yếu tố bản sao đóng vai trò quan trọng trong trường hợp xácđịnh bao nhiêu dung lượng đĩa được sử dụng. Đối với bản sao bằng 1 thì không có chiphí cho bản sao. Nếu số lượng bản sao lớn hơn 1, thì yêu cầu lưu trữ dữ liệu tổng baogồm cả chi phí bản sao:

replication_overhead = total_data_size * (replication_factor - 1)

31

2.9.3 Lựa chọn tùy chọn cấu hình nút

Một phần chính của kế hoạch triển khai cụm Cassandra là hiểu và thiết lập cácthuộc tính cấu hình nút khác nhau. Trong phần này giải thích các quyết định cấu hìnhkhác nhau cần được thực hiện trước khi triển khai một cụm Cassandra, hoặc là cụm trungtâm đa dữ liệu hoặc là đa nút hoặc đơn nút.

Những thuộc tính này được đề cập trong phần này được thiết lập trong file cấuhình cassandra.yaml. Mỗi nút nên được cấu hình đúng trước khi khởi động nó lần đầutiên.

Thiết lập nơi lưu trữ:

Mặc định, một nút được cấu hình lưu trữ dữ liệu nó quản lý trong/var/lib/cassandra. Trong triển khai một cụm, bạn nên thay đổi commitlog_directory đểnó ở trên các thiết bị ổ đĩa khác hơn là data_file_directories.

Thiết lập Gossip

Thiết lập gossip kiểm soát sự tham gia một nút trong một cụm và làm thế nào biếtđược một nút thuộc một cụm.

Thuộc tính Mô tả

Cluster_name Tên của cụm nơi mà nút tham gia. Tên chung cho mỗi núttrong một cụm

Listen_address Địa chỉ IP hoặc tên máy chủ mả các nút Cassandra khác sẽsử dụng để kết nối tới nút này. Nên được thay đổi từlocalhost thành địa chỉ công cộng đối với máy chủ.

Seeds Một danh sách các địa chỉ Ip các nút khởi tạo của quá trìnhGossip. Mỗi nút phải có cùng một danh sách các seed.Trong các cụm trung tâm đa dữ liệu, danh sách seed baogồm các nút đến từ mỗi trung tâm dữ liệu.

Storage_port Cổng giao tiếp giữa các nút ( mặc định là 7000),

Initial_token Được sử dụng để định nghĩa dãy các dữ liệu mà nút chịutrách nhiệm.

32

Thanh lọc trạng thái Gossip trên mỗi nút

Thông tin Gossip được lưu trữ cục bộ bởi mỗi nút để sử dụng ngay lập tức trong lần khởiđộng kế tiếp mà không có bất cứ sự chờ đợi Gossip. Để làm sạch lịch sử gossip trong mỗilần khởi động nút (ví dụ, địa chỉ IP nút thay đổi), thì thêm dòng sau đây vào filecassandra-env.sh. File nà được đặt trong /usr/share/cassandra hoặc<install_location>/conf.

-Dcassandra.load_ring_state=false

Cài đặt phân vùng

Khi bạn triển khai một cụm Cassandra, bạn cần phải chắc chắn rằng mỗi nút là chịu tráchnhiệm cho một số lượng dữ liệu. Điều này còn được gọi là cân bằng tải.Điều này đượcthực hiện bằng cách cấu hình các phân vùng cho mỗi nút, và việc gán một cách chính xáccho các nút giá trị initial_token.

DataStax khuyến cáo sử dụng RandomPartitioner (mặc định) đối với tất cả các triển khaicụm. Giả định sử dụng phân vùng này, mỗi nút trong cụm được gán một token mà biểudiện một giá trị băm trong dãy từ 0 tới 2**127.

Đối với các cụm trong đó tất cả các nút nằm trong trung tâm dữ liệu đơn, bạn có thể tínhtoán các token bằng việc chia dãy cho tổng số nút trong cụm. Trong triển khai trung tâmđa dữ liệu, token nên được tính toán để mỗi trung tâm dữ liệu được cân bằng tải. XemCalculating Tokens đối với các phương pháp khác nhau để sinh token cho mỗi nút trongcác cụm trung tâm đa dữ liệu và đơn dữ liệu.

Cấu hình thông tin

Thông tin (Snitch) cho biết vị trí của các nut trong topo mạng. Điều này ảnh hưởng đếnnơi mà những bản sao được đặt cũng như cách các truy vấn được định tuyến giữa các bảnsao như thế nào. Thuộc tính endpoint_snitch cấu hình thông tin cho nút. Tát cả các nútnên có cùng một cấu hình thông tin.

Đối với các cụm trung tâm đơn dữ liệu (hoặc nút đơn), sử dụng mặc định SimpleSnitch làđủ. Tuy nhiên, nếu ban lập kế hoạch để mở rộng các cụm của bạn ở các thời điểm sau đóthành nhiều trung tâm dữ liêu và nhiều giá dữ liệu, thì ban nên chọn trước các kiểu cấuhình thông tin về trung tâm dữ liệu và rách từ khi bắt đầu.

Cấu hình PropertyFileSnitch

33

PropertyFileSnitch cho phép bạn định nghĩa tên trung tâm dữ liệu và tên giá là bất cứ cáigì mà bạn muốn. Việc sử dụng thông tin này yêu cầu bạn định nghĩa chi tiết mạng chomỗi nút trong cụm trong file cấu hình cassandra-topology.properties. File này được đặttrong /etc/cassandra/conf/cassandra.yaml đối với chương trình cài đặt đã được đóng góihoặc trong <install_location>/conf/cassandra.yaml đối với chương trình cài đặt ở dạngnhị phân.

Ví dụ, giả sử bạn có một địa chỉ IP không đồng nhất và hai trung tâm dữ liệu vật lý vớihai giá trong mỗi trung tâm, và một trung tâm dữ liệu lô gic thứ 3 để sao chép dữ liệuphân tích:

# Data Center One

175.56.12.105=DC1:RAC1

175.50.13.200=DC1:RAC1

175.54.35.197=DC1:RAC1

120.53.24.101=DC1:RAC2

120.55.16.200=DC1:RAC2

120.57.102.103=DC1:RAC2

# Data Center Two

110.56.12.120=DC2:RAC1

110.50.13.201=DC2:RAC1

110.54.35.184=DC2:RAC1

50.33.23.120=DC2:RAC2

50.45.14.220=DC2:RAC2

50.17.10.203=DC2:RAC2

# Analytics Replication Group

172.106.12.120=DC3:RAC1

172.106.12.121=DC3:RAC1

34

172.106.12.122=DC3:RAC1

# default for unknown nodes

default=DC3:RAC1

35

3. Mô hình dữ liệu CassandraMô hình dữ liệu Cassandra là một lược đồ động, mô hình dữ liệu hướng cột. Tức

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

3.1 So sánh mô hình dữ liệu Cassandra với cơ sở dữ liệu quan hệMô hình dữ liệu Cassandra được thiết kế cho dữ liệu phân tán với quy mô rất lớn.

Mặc dù nhu cầu so sánh Cassandra với cơ sở dữ liệu quan hệ là rất tự nhiên, nhưng chúnghoàn toàn khác nhau. Trong cơ sở dữ liệu quan hệ, dữ liệu được lưu trong các bảng, cácbảng này tạo thành một ứng dụng mà chúng thường liên quan đến nhau. Dữ liệu đượcchuẩn hóa để giảm các bản ghi dư thừa, và các bảng được kết nối bằng khóa để thỏa mãnmột truy vấn nào đấy. Ví dụ, xem xét một ứng dụng cho phép người dùng tạo các bàiblog. Trong ứng dụng này, bài blog được phân loại theo chủ đề (thể thao, thời trang …).Người dùng có thể chọn đăng kí xem blog của những người khác. Trong ví dụ này, userid là khóa chính trong bảng user, và là khóa ngoại trong các bảng blog và subcriber.Tương tự, category id là khóa chính của bảng category và là khóa ngoại trong bảngblog_entry. Sử dụng mô hình quan hệ, các truy vấn SQL có tể thực hiện join nhiều bảngđể trả lời câu hỏi “những người dùng nào đăng kí xem blog của tôi”, hay “cho tôi xem tấtcả các blog viết về thời trang” hay “cho tôi xem các bài viết mới nhất của các blog mà tôiđăng kí”.

36

Trong Cassandra, keyspace là nơi chứa tất cả dữ liệu ứng dụng, tương tự với mộtcơ sở dữ liệu hay lược đồ trong một cơ sở dữ liệu quan hệ. Bên trong keyspace là mộthoặc nhiều đối tượng column family tương tự như các bảng. Các column family chứa cáccột và một tập các cột được xác định bởi một row key do ứng dụng cung cấp. Mỗi dòng làtrong một column family không nhất thiết phải có cùng các cột.

Cassandra không áp đặt quan hệ giữa các column family như cách mà cơ sở dữ liệuquan hệ thực hiện với các bảng: không có khóa ngoại trong Cassandra, và việc join cáccolumn family khi truy vấn không được hỗ trợ. Mỗi column family có một tập các cột tựchứa được dự định để được truy nhập cùng nhau để thỏa mãn các truy vấn nào đó từ ứngdụng.

Ví dụ, sử dụng vó dụ ứng dụng blog ở trên, bạn có thể có một column family chouser và blog entry như trong mô hình quan hệ. Sau đó, các column family khác có thểđược thêm vào để hỗ trợ truy vấn mà ứng dụng cần thực hiện. Ví dụ, để trả lời truy vấn“những người dùng nào đăng kí xem blog của tôi” ”, hay “cho tôi xem tất cả các blog viếtvề thời trang” hay “cho tôi xem các bài viết mới nhất của các blog mà tôi đăng kí”, bạn cóthể cần thiết kế các column family bổ sung để hỗ trợ những truy vấn này. Chú ý rằng cầnthực hiện một số phi chuẩn hóa đối với dữ liệu.

37

3.2 Keyspaces

Trong Cassandra, keyspace là nơi chưa dữ liệu cho ứng dụng của bạn, giống nhưlược đồ trong một cơ sở dữ liệu quan hệ. keyspace được dùng để nhóm các column familylại với nhau. Thường thì một cluster có một column family cho một ứng dụng. Việc nhânbản được điều khiển trên cơ sở keyspace, vì dữ liệu có những yêu cầu nhân bản khác nhaunên đặt ở những keyspace khác nhau. Keyspace không được thiết kế để sử dụng như mộtlớp bản đồ quan trọng trong mô hình dữ liệu, mà nó chỉ như một cách để điều khiển việcnhân bản dữ liệu cho một tập các column family.

Các lệnh của ngôn ngữ định nghĩa dữ liệu (DDL) cho việc định nghĩa và thay đổikeyspace được cung cấp trong rất nhiều giao diện khách hàng khác nhau như CassandraCLI và CQL. Ví dụ, để định nghĩa có một keyspace trong CQL:

CREATE KEYSPACE keyspace_name WITH

strategy_class = 'SimpleStrategy'

AND strategy_options:replication_factor=2;

Hoặc trong Cassandra CLI:

CREATE KEYSPACE keyspace_name WITH

placement_strategy = 'SimpleStrategy'

AND strategy_options = [{replication_factor:2}];

3.3 Column Families

Khi so sánh Cassandra với cơ sở dữ liệu quan hệ, column family giống như bảngtrong đó nó chứa các cột và dòng. Tuy nhiên, một column family cần thay đổi lớn trongsuy nghĩ của những người quen thuộc với thế giới quan hệ.

Trong cơ sở dữ liệu quan hệ, bạn định nghĩa ra các bảng có các cột cố định. Bảngxác định tên cột, và kiểu dữ liệu của nó, và sau đó ứng dụng cung cấp các dòng để hoànthiện schema đó: mỗi dòng chứa cùng một số cột cố định như nhau.

Trong Cassandra, bạn định nghĩa các column family. Các column family có thể(và nên) định nghĩa metadata về các cột, nhưng các cột thực sự tạp thành một dòng đượcxác định bởi ứng dụng. Mỗi dòng có thể có số lượng cột khác nhau.

Mặc dù các column family rất linh hoạt, nhưng trong thực thế mỗi column familykhông hoàn toàn không có lược đồ. Mỗi column family nên được thiết kế để chứa một

38

kiểu dữ liệu. Có 2 kiểu mẫu thiết kế column family phổ biến trong Cassandra: các columnfamily động và tĩnh.

Một column family tĩnh sử dụng một tập tương đối cố định các tên cột cột và giốngvới cơ sở dữ liệu quan hệ hơn. Ví dụ, một column family lưu trữ dữ liệu người dùng cóthể có các cột tên người dùng, địa chỉ, email, số điện thoại… Mặc dù các dòng sẽ có cùngmột tập cột, chúng không bắt buộc phải có giá trị xác định cho tất cả các cột. Columnfamily tĩnh thường có metadata được đĩnh nghĩa trước cho mỗi cột.

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

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

39

Thay vì định nghĩa metadata cho các cột riêng lẻ, một column family động địnhnghĩa kiểu thông tin cho các tên giá giá trị của cột, nhưng tên và giá trị thực sự của cộtđược đặt ởi ứng dụng khi một cột được thêm vào.

Với tất cả các column family, mỗi dòng là duy nhất và được xác định bằng khóacủa dòng đó, giống như khóa chính trong bảng quan hệ. Một column family luôn đượcphân chia theo khóa dòng của nó, và khóa dòng luôn luôn được đánh chỉ mục ẩn. Khóadòng không được phép để trống.

3.4 Columns

Cột là đơn vị dữ liệu nhỏ nhất trong Cassandra. Nó là một bộ gồm có tên, giá trị,và một nhãn thời gian.

Một cột phải có ten, và tên có thể là một nhãn tĩnh (như “tên”, hay “email”) hoặcnó có thể được đặt tự động khi cột được tạo ra bởi ứng dụng.

Cột có thể được đánh chỉ mục theo tên của nó. Tuy nhiên, mọt hạn chế của các chỉmục cột là chúng không hỗ trợ các truy vấn yêu cầu truy nhập đến dữ liệu có thứ tự, nhưcác dữ liệu chuỗi thời gian. Trong trường hợp này, chỉ mục thứ cấp trên một cột nhãn thờigian là không đủ vì bạn khong thể diều khiển thứ tự sắp xếp của cột với một chỉ mục thứcấp. Với những trường hợp thứ tự sắp xếp là quan trọng, việc duy trì thủ công mộtcolumn family như một chỉ mục là một cách khác để tra cứu cột dữ liệu được sắp xếp theothứ tự.

Một cột không nhất thiết phải có một giá trị. Đôi khi tất cả thông tin ứng dụng cầnđể thỏa mãn một truy vấn nào đó có thể được lưu trữ ngay ở tên của cột. Ví dụ, nếu bạnđang sử dụng một column family như một cái nhìn cụ thể hóa dể truy vấn các dòng từ cáccolumn family khác, tất cả những gì bạn cần là lưu trữ khóa dòng mà bạn đang tìm kiếm,giá trị có thể trống.

Cassandra sử dụng cột nhãn thời gian để xác định cập nhật gần nhất của một cột.Nhãn thời gian được cung cấp bởi ứng dụng. Nhãn thời gian gần nhất luôn đạt dược khiyêu cầu dữ liệu, nếu nhiều phiên cùng cập nhật một cột trong một dòng cùng một lúc thìcập nhập mới nhất là cập nhật sẽ được tồn tại.

40

3.5 Các column đặc biệt (Counter, Expiring, Super)

3.5.1 Expiring Columns

Một cột có thể có một ngày hết hạn tùy chọn gọi là TTL (time to live). Mỗi khimột cột được thêm vào, ứng dụng yêu cầu có thể chỉ ra một giá trị TTL tùy chọn, đượcđịnh nghĩa bằng giây, cho cột đó. Các cột TTL được đánh dấu xóa sau khi thời gian yêucầu hết hạn. Một khi chúng được đánh dấu xóa, chúng sẽ tự động bị loại bỏ khỏi các quátrình sửa hay nén thông thường.

Bạn có thể sử dụng CLI hay CQL để thiết lập TTL cho một cột.

Nếu bạn muốn thay đổi TTL của một cột có hạn, bạn phải thêm lại cột đó với giátrị TTL mới. Trong Cassandra việc thêm một cột thực sự là thao tác thêm hoặc cập nhât,phụ thuộc vào phiên bản trước của cột đó đã tồn tại hay chưa. Điều này có nghĩa là để cậpnhật TTL cho một cột với một giá trị không xác định, bạn phải đọc cột và sau đó thêm lạicột đó với một giá trị TTL mới.

Các cột TTL có độ chính xác đến một giây, được tính toán trên server. Do đó, mộtgiá trị TTL rất nhỏ có lẽ không có mấy ý nghĩa. Hơn nữa, các đồng hồ trên server phảiđược đồng bộ hóa; nếu không độ chính xác có thể bị giảm vì thời gian hết hạn được tínhtoán trên máy chủ chính nhận thao tác thêm cột đầu tiên, nhưng sau đó lại được đọc ra bởicác máy khác trên cluster.

Một cột có hạn có thêm 8 byte mào đầu trong bộ nhớ hay ổ đĩa (để ghi TTL và thờigian hết hạn) so với các cột chuẩn.

3.5.2 Counter Columns

Counter là một kiểu cột đặc biệt được sử dụng để lưu trữ một số có giá trị đếm tựtăng khi có sự xuất hiện của một sự kiện hoặc tiến trình cụ thể nào đó. Ví dụ, bạn có thểsử dụng cột counter để đếm số lần một trang được xem.

Các counter column family phải sử dụng CounterColumnType là kiểu dữ liệu chocột. Điều này có nghĩa là hiện tại, các cột counter chỉ có thể được lưu trữ trong cáccolumn family chuyên biệt; chúng sẽ được phép trộn với các cột thông thường trongtương lai.

Cột counter khác với các cột thông thường ở chỗ một khi nó được định nghĩa, ứngdụng chỉ có thể cập nhật giá trị cột bằng cách tăng hoặc giảm nó. Để cập nhật tới cộtcounter, ứng dụng cần truyền tên của cột và giá trị tăng (hoặc giảm); không cần nhãn thờigian.

41

Về bên trong, cấu trúc của một cột counter có một chút phức tạp hơn. Cassandratheo dõi trạng thái phân tán của counter cũng như nhãn thời gian mà server sinh ra khi xóamột cột counter. Vì lý do này, điều quan trọng là tất cả các node trong cluster phải cóđồng hồ được đồng bộ hóa bằng giao thức thời gian mạng (network time protocol NTP).

Một cột counter có thể được đọc hay viết ở bất cứ mức độ nhất quán nào. Tuynhiên, điều quan trọng là phải hiêu rằng không giống những cột thông thường, việc ghivào cột counter yêu cầu một lần đọc trước để đảm bảo rằng các giá trị counter phân tánvẫn thống nhất với nhau trên các bản sao. Nếu bạn ghi ở mức độ nhất quán là 1, việc đọcẩn sẽ không ảnh hưởng đến độ ghi trễ, nên 1 là mức độ nhất quán phổ biến nhất dùng vớicounter.

3.5.3 Super Columns

Một Cassandra column family có thể chứa cả cột thông thường và siêu cột – điềunày làm cho mức độ lồng ghép trong cấu trúc column family thông thường tăng lên. Siêucột được tạp thành từ tên (siêu) cột và một bản đồ được sắp xếp của các cột con. Một siêucột có thể chỉ ra một kiểu dữ liệu (comparator) cho cả tên siêu cột và tên cột con.

Một siêu cột là một cách nhóm nhiều cột dựa trên một giá trị tìm kiếm chung. Mụcđích sử dụng chính của siêu cột là để phi chuẩn hóa nhiều dòng từ các column familykhác vào trong một dòng, cho phép lấy dữ liệu dưới cái nhìn cụ thể hóa. Ví dụ, giả sử bạnmuốn tạo ra một cái nhìn cụ thể của các blog entry cho những blogger mà một ngườidùng đăng kí xem blog của họ.

42

Một hạn chế của siêu cột là tất cả các cột con của siêu cột đó phải được giải tuần tựhóa để đọc từng giá trị riêng của cột con, và bạn không thể tạo ra các chỉ mục thứ cấp trêncác cột con của siêu cột. Do đó, việc dùng siêu cột phù hợp nhất cho trường hợp số lượngcột con tương đối nhỏ.

3.6 Các kiểu dữ liệu (Comparators và Validators)

Trong cơ sở dữ liệu quan hệ, bạn phải chỉ rõ kiểu dữ liệu cho mỗi cột khi bạn địnhnghĩa bảng. Kiểu dữ liệu ràng buộc các giá trị có thể được thêm vào cột đó. Ví dụ, nếubạn có một cột định nghĩa kiểu dữ liệu integer, bạn sẽ không được phép đưa dữ liệu có giátrị char vào cột đó. Tên cột trong cơ sở dữ liệu quan hệ thường là các nhãn cố định đượcgán khi tạo bảng.

Trong Cassandra, kiểu dữ liệu cho một giá trị cột (hay khóa của dòng) được gọi làvalidator. Kiểu dữ liệu cho một tên cột được gọi là comparator. Bạn có thể định nghĩa cáckiểu dữ liệu khi tạo các lược đồ column family nhưng Cassandra không yêu cầu việc này.Về bên trong, Cassandra lưu tên cột và giá trị dưới dạng các mảng byte hexa (BytesType).Đây là kiểu mã hóa mặc định được dùng nếu các kiểu dữ liệu không được định nghĩatrong lược đồ column family (hoặc không được chỉ ra bởi client yêu cầu).

Cassandra có sẵn một số kiểu dữ liệu có thể được dùng cho cả vadidator (kiểu dữliệu cho khóa dòng và giá trị cột) và comparator (kiểu dữ liệu cho tên cột). Một ngoại lệ làCounterColumnType, chỉ được dùng là giá trị cột (không được dùng cho tên cột hay khóadòng).

43

3.6.1 Validators

Với tất cả các column family, cách thực hành tốt nhất là định nghĩa một kiểu dữliệu cho khóa dòng sử dụng thuộc tính key_validation_class.

Với các column family tĩnh, bạn nên định nghĩa một cột và kiểu dữ liệu tương ứngkhi bạn định nghĩa column family sử dụng thuộc tính column_metadata.

Với các column family động (các tên cột không được biết trước), bạn nên chỉ ramột default_validation_class thay vì định nghĩa kiểu dữ liệu cho từng cột.

Các validator cho khóa và cột có thể được thêm vào hoặc thay đổi trong định nghĩacolumn family bất cứ khi nào. Nếu bạn chỉ định một validator không hợp lệ trên columnfamily, yêu cầu tới dữ liệu đó có thể bị nhầm lẫn, và việc thêm hay cập nhật dữ liệu khongtuân theo validator đã chỉ định sẽ bị từ chối.

3.6.2 Comparators

Trong một dòng, các cột luôn được lưu trữ theo thứ tự sắp xếp theo tên cột.Comparator chỉ ra kiểu dữ liệu cho tên cột, cũng như thứ tự sắp xếp mà các cột được lưutrong một dòng. Không giống validator, comparator có thể không được thay đổi sau khicolumn family được định nghĩa, nên đây là một xem xét quan trọng khi định nghĩa mộtcolumn family trong Cassandra.

Thường thì tên của column family tĩnh thường là kiểu chuỗi, và thứ tự sắp xếp củacột không quan trọng. Với các column family động, thứ tự sắp xếp lại quan trọng. Ví dụ,trong một column family lưu trữ dữ liệu chuỗi thời gian (tên cột và nhãn thời gian), có dữliệu theo thứ tự sắp xếp được cần đến để trích ra tập kết quả từ một dòng các cột.

3.7 Nén column family

Việc nén dữ liệu có thể được cấu hình trên mỗi column family. Việc nén này sẽ tốiđa hóa dung lượng lưu trữ của các node Cassandra bằng cách giảm dung lượng dữ liệutrên đĩa. Hơn nữa ngoài tiết kiệm không gian lưu trữ, việc nén cũng giảm vào ra đĩa, đặcbiệt là cho các công việc chỉ đọc.

Bên cạnh việc giảm kích thước dữ liệu, việc nén thường cải thiện cả hiệu năng đọcvà ghi. Cassandra có thể nhanh chóng tìm ra vị trí của các dòng trong chỉ mục SSTable,và chỉ giải nén nhóm dữ liệu có liên quan. Điều này có nghĩa việc nén cải thiện hiệu năngđọc không chỉ bằng cách cho phép lưu trữ được nhiều dữ liệu hơn trên bộ nhớ mà còn cólợi với các công việc có tập dữ liệu không đặt vừa vào bộ nhớ.

44

Không giống như cơ sở dữ liệu truyền thống, hiệu năng ghi bị ảnh hưởng tiêu cụcbởi việc nén trong Cassandra. Ghi dữ liệu trên các bảng đã nén trong thực tế đã cho thấycải thiện được 10% hiệu năng. Trong cơ sở dữ liệu quan hệ truyền thống, việc ghi đòi hỏighe đè lên các file dữ liệu đang tồn tại trên đĩa. Điều này nghĩa là các cơ sở dữ liệu phảiđịnh vị các trang liên quan trên đĩa, giải nén chúng, ghi đè dữ liệu liên quan lên, và sau đólại nén lại (một thao tác đắt đỏ về cả sử dụng CPU và vào ra đĩa).

Vì các file dữ liệu Cassandra SSTable là bất biến (chúng không dược viết lại saukhi đã được ghi vào đĩa), khong cần phải giản nén để xử lý thao tác ghi. SSTable chỉ đượcnén một lần, khi chúng được ghi vào đĩa.

Việc nén có thể đưa lại các lợi ích sau, phụ thuộc vào đặc trưng dữ liệu của columnfamily:

• Giảm 2x-4xtrong kích thước dữ liệu

• Cải thiện 25-35% hiệu năng đọc

• Cải thiện 5-10% hiệu năng của thao tác ghi.

3.7.1 Khi nào sử dụng nén

Nén phù hợp nhất cho các column family có nhiều dòng, mỗi dòng có cùng số cột,hoặc ít nhất có nhiều cột chung. Ví dụ, một column family chứa dữ liệu người dùng nhưtên, email… có thể là ứng cử viên tốt cho việc nén. Càng có nhiều dữ liệu tương đồng trêncác dòng tỉ lệ nén càng lớn, và đạt được hiệu năng đọc tốt hơn.

Nén khong tốt đối với các column family mà mỗi dòng có tập các cột khác nhau, hoặc córất ít dòng rộng. Column family động như vậy sẽ không tốt trong tỉ lệ nén.

3.7.2 Cấu hình nén cho một Column Family

Khi bạn tạo hay cập nhật một column family, bạn có thể chọn làm nó thành mộtcolumn family nén bằng cách thiết lập thuộc tính compression_options. Bạn có thể chophép nén khi bạn tạo một column family mới, hoặc cập nhật một column family đã có đểthêm việc nén vào sau. Khi bạn thêm thao tác nén vào một column family mới, SSTabledã có trên đĩa khong được nén ngay lập tức. Bất cứ SSTable mới nào được tạo ra cũng sẽđược nén, và các SSTable đã có sẽ được nén trong quá trình nén Cassandra thông thường.Nếu cần, bạn có thể ép buộc các bảng SSTable đã có được ghi lại và nén bằng cách sửdụng một số nodetool.

Ví dụ, để tạo ra một column family mới có thực hiện nén bằng Cassandra CLI, bạnlàm như sau:

45

[default@demo] CREATE COLUMN FAMILY users WITHkey_validation_class=UTF8Type AND column_metadata = [

{column_name: name, validation_class: UTF8Type} {column_name: email,validation_class: UTF8Type} {column_name:

state, validation_class: UTF8Type} {column_name: gender, validation_class:UTF8Type} {column_name: birth_year,

validation_class: LongType} ] ANDcompression_options={sstable_compression:SnappyCompressor,

chunk_length_kb:64};

3.8 Chỉ mục trong Cassandra

Một chỉ mục là một cấu trúc dữ liệu cho phép tìm kiếm dữ liệu nhanh, hiệu quảphù hợp với một điều kiện đã cho.

3.8.1 Chỉ mục chính

Trong thiết kế cơ sở dữ liệu quan hệ, một khóa chính là khóa duy nhất được dùngđể xác định mỗi dòng trong bảng. Một chỉ mục khóa chính, giống như chỉ mục, tăng tốcđộ truy nhập ngẫu nhiên tới dữ liệu trong bảng. Khóa chính cũng đảm bảo tính duy nhấtcủa bản ghi, và có thể điều khiển thứ tự trong đó các bản ghi được phân cụm một cách vậtlý, hoặc được lưu trữ trong cơ sở dữ liệu.

Trong Cassandra, chỉ mục chính cho một column family là chỉ mục của các khóadòng. Mỗi node giữ chỉ mục này cho dữ liệu nó quản lý.

Các dòng được gán cho các node bởi phân vùng cluster được cấu hình, và chiếnlược đặt bản sao keyspace đã cấu hình. Chỉ mục chính trong Cassandra cho phép tìm kiếmcác dòng theo khóa dòng. Vì mỗi node biết khoảng các khóa mà nó quản lý, các dòngđược yêu cầu có thể được định vị một cách hiệu quả bằng việc quét các chỉ mục dòng chỉtrên các bản sao liên quan.

Với các khóa dòng được phân vùng ngẫu nhiên (mặc định trong Cassandra), cáckhóa dòng được phân vùng bởi mã băm MD5 và không được quét theo thứ tự như trongcác chỉ mục cây nhị phân truyền thống. Sử dụng các phân vùng có thứ tự cho phép giớihạn các truy vấn tới các dòng, nhưng không được khuyến khích vì độ phức tạp trong việcduy trì việc phân tán dữ liệu trên các node.

46

3.8.2 Chỉ mục thứ cấp

Các chỉ mục thứ cấp trong Cassandra chỉ các chỉ mục trên giá trị cột (để phân biệtvới chỉ mục khóa dòng chính cho một column family). Cassandra hỗ trợ các chỉ mục thứcấp của kiểu KEYS (tương tự như chỉ mục băm).

Các chỉ mục thứ cấp cho phép truy vấn hiệu quả bởi việc chỉ ra các giá trị bằngphép bằng (where column x = value y). Và, các truy vấn trên các giá trị đã được đánh chỉmục có thể áp dụng các bộ lọc bổ sung vào tập kết quả cho các giá trị ở cột khác.

Chỉ mục thứ cấp của Cassandra tốt nhất cho các trường hợp nhiều dòng chứa giá trịđược đánh chỉ mục.

Ví dụ, giả sử bạn có mọt bảng user với hàng tỉ người dùng, và muốn tìm kiếmngười dùng theo bang mà họ sống. Rất nhiều người dùng sẽ có cùng giá trị cột cho bang(như CA, NY, TX…). Đây là ứng cử viên tốt nhất cho chỉ mục thứ cấp. Mặc khác, nếubạn muốn tìm kiếm người dùng theo địa chỉ email của họ (một giá trị thường là duy nhấtcho mỗi người), thì có thể hiệu quả hơn khi duy trì một cách thủ công column familyđộng dưới dạng một “chỉ mục”.

Thậm chí với các cột chứa dữ liệu độc nhất, sử dụng các chỉ mục thứ cấp cũng làmột điều khôn ngoan, chừng nào khối lượng truy vấn tới các column family được đánhchỉ mục là vừa phải và không dưới một tải liên tục.

Một ưu điểm khác của các chỉ mục thứ cấp là sự dễ dàng về mặt thao tác duy trìchỉ mục. Khi bạn tạo một chỉ mục thứ cấp cho một cột, nó đánh chỉ mục dữ liệu ngầm bêndưới.

Các column family được client duy trì như những chỉ mục phải được tạo một cáchthủ công; ví dụ, nếu cột bang được đánh chỉ mục bằng cách tạp ra một column family nhưusers_by_state , ứng dụng client phải xây dựng column family với dữ liệu từ columnfamily users.

3.8.3 Tạo và sử dụng chỉ mục thứ cấp

Bạn có thể chỉ ra kiểu KEYS khi tạo ra định nghĩa cột, hoặc bạn có thể thêm vàosau để đánh chỉ mục một cột có sẵn. Các chỉ mục thứ cấp được tạo một cách tự động bởitiến trình nền mà không cần phải khóa các thao tác đọc, ghi.

Ví dụ, trong Cassandra CLI, bạn có thể tạo ra một chỉ mục thứ cấp trên một côt khiđịnh nghĩa column family (chú ý index_type: đặc tả KEYS cho các cột state vàbirth_year):

47

[default@demo] create column family users with comparator=UTF8Type

... and column_metadata=[{column_name: full_name, validation_class: UTF8Type},

... {column_name: email, validation_class: UTF8Type},

... {column_name: birth_year, validation_class: LongType, index_type: KEYS},

... {column_name: state, validation_class: UTF8Type, index_type: KEYS}];

Hoặc bạn có thể thêm một chỉ mục vào column family đã có:

[default@demo] update column family users with comparator=UTF8Type

... and column_metadata=[{column_name: full_name, validation_class: UTF8Type},

... {column_name: email, validation_class: UTF8Type},

... {column_name: birth_year, validation_class: LongType, index_type: KEYS},

... {column_name: state, validation_class: UTF8Type, index_type: KEYS}];

Vì chỉ mục thứ cấp được tạo cho cột state, giá trị của nó có thể được truy vấn trực tiếp vớinhững người dùng sống ở một bang nào đó, như

[default@demo] get users where state = 'TX';

3.9 Thiết kế mô hình dữ liệu

Việc thiết kế một mô hình dữ liệu trong Cassandra cần một số cân nhắc trong thiếtkế khác so với trong cơ sở dữ liệu quan hệ. Sau cùng, mô hình dữ liệu bạn thiết kế phụthuộc vào dữ liệu mà bạn muốn lưu giữ và cách bạn truy nhập nó. Tuy nhiên, có một sốcân nhắc thiết kế chung cho việc dự kiến mô hình dữ liệu Cassandra.

3.9.1 Dựa trên các truy vấn

Cách tốt nhất để tới gần với mô hình hóa dữ liệu cho Cassandra là bắt đầu với cáctruy vấn và làm ngược trở lại từ đó.

Nghĩ về các hành động mà ứng dụng của bạn cần thực hiện, bạn muốn truy nhậpdữ liệu như thế nào, và sau đó thiết kế các column family để hỗ trợ các mẫu truy cập đó.Ví dụ, bắt đầu với việc liệt kê tất cả những use case mà ứng dụng cần hỗ trợ. Nghĩ về dữliệu bạn muốn lưu giữ và các tra cứu ứng dụng cần làm. Chú ý cả các yêu cầu về sắp xếp,lọc và nhóm dữ liệu. Ví dụ, nếu bạn cần các sự kiện theo một thứ tự thời gian, hoặc bạn

48

chỉ quan tâm đến dữ liệu của 6 tháng trước, những điều này nên là nhân tố trong thiết kếmô hình dữ liệu cho Cassandra.

3.9.2 Phi chuẩn hóa để tối ưuTrong thế giới quan hệ, mô hình dữ liệu thường được thiết kế với mục tiêu chuẩn

hóa dữ liệu để giảm thiểu tối đa dư thừa. Việc chuẩn hóa thường liên quan đến việc tạo racác bảng có cấu trúc chặt chẽ, nhở hơn và sau đó định nghĩa quan hệ giữa chúng. Trongquá trình truy vấn, các bảng liên quan được kết nối với nhau để thỏa mãn yêu cầu.

Cassandra không có mối quan hệ khóa ngoại giống như cơ sở dữ liệu quan hệ,nghĩa là bạn không thể kết nối nhiều column family với nhau để đáp ứng mọt yêu cầu truyvấn cụ thể. Cassandra thực hiện tót nhất khi dữ liệu cần thỏa mãn một truy vấn nào đóđược đặt ở cùng một column family. Cố gắng thiết kế mô hình dữ liệu để một hoặc mộtvài dòng trong một column family được dùng để trả lời mỗi truy vấn. Điều này hy sinhkhông gian đĩa (một trong những tài nguyên rẻ nhất cho một server) để giảm số lượng tìmkiếm trên đĩa và lưu lượng mạng.

3.9.3 Lập kế hoạch cho việc ghi trùng lặp

Trong một column family, mỗi dòng được xác định bởi khóa dòng của nó, mộtchuỗi có độ dài gần như không giới hạn. Khóa này không có dạng cụ thể, nó phải là duynhất trong một column family. Không giống khóa chính trong cơ sở dữ liệu quan hệ,Cassandra không bắt buộc tính duy nhất. Việc thêm vào một khóa dòng bị trùng sẽ upsert(kết hợp của insert và update) các cột trong câu lệnh insert chứ không trả về lỗi vi phạm.

3.9.4 Sử dụng các khóa dòng tự nhiên hoặc thay thếMột vấn đề cần xem xét là sử dụng các khóa tự nhiên hay thay thế cho một column

family. Một khóa thay thế là khóa được sinh ra (như UUID) xác định duy nhất một dòng,nhưng không có quan hệ với dữ liệu thực tế trong dòng đó.

Với một số column family, dữ liệu có thể chứa các giá trị được đảm bảo là duynhất và thường không được cập nhật sau khi dòng được tạo ra. Ví dụ, username trongcolumn family user. Đây được gọi là khóa tự nhiên. Các khóa tự nhiên khiến cho dữ liệudễ đọc hơn, và loại bỏ nhu cầu các chỉ mục bổ sung hoặc phi chuẩn hóa. Tuy nhiên, trừkhi ứng dụng của bạn đảm bảo tính duy nhất, thì vẫn có nguy cơ viết đè lên cột dữ liệu.Và các dùng khóa tự nhiên không cho phép cập nhật khóa dòng một cách dễ dàng. Ví dụ,nếu khóa dòng của bạn là một địa chỉ email và người dùng muốn thay đổi địa chỉ emailcủa mình, bạn có thể phải tạo ra một dòng mới với địa chỉ email mới và sao chép tất cảcác cột đang có từ dòng cũ sang dòng mới.

49

3.9.5 Các kiểu UUID cho tên cột

Kiểu UUID comparator (id duy nhất) được sử dụng để tránh xung đột trong tên cột. Vídụ, nếu bạn muốn xác định một cột (như blog entry hay tweet) theo nhãn thời gian của nó,nhiều client viết cùng một khóa dòng đồng thời có thể gây ra xung đột về nhãn thời gian,nguy cơ ghi đè dữ liệu không có ý định bị ghi đè. Sử dụng UUIDType để thể hiện mộtkiểu UUID (dựa trên thời gian) có thể tránh những xung đột như vậy.

50

KẾT LUẬNTrong tiểu luận này nhóm em đã trình bày khái quát về hệ cơ sở dữ liệu phân tán

Cassandra. Cassandra, hệ thống phân phối và quản lý cơ sở dữ liệu, vốn được phát triển bởiFacebook, công bố mã nguồn mở vào tháng 07/2008 và chính thức gia nhập vào “đại giađình” Apache. Và trong cuối tháng 02/2010, Cassandra đã trở thành Apache Top-LevelProject (TLP). Mặc dù vẫn còn khá mới mẻ với cộng đồng người sử dụng, nhưng công nghệcủa Cassandra đã được ứng dụng rộng rãi trong những công ty và tổ chức có quy mô nhưCisco, Twitter và Digg.

Cassandra đã mở đầu cho một thế hệ database kế tiếp là một thế hệ cơ sở dữ liệunon-relational (không quan hệ), distributed (phân tán), mã nguồn mở, horizontal scalable(khả năng mở rộng theo chiều ngang) có thể lưu trữ, xử lý từ một lượng rất nhỏ cho tớihàng petabytes dữ liệu trong hệ thống có độ chịu tải, lỗi cao với những đòi hỏi về tàinguyên phần cứng thấp.

Tiểu luận đã giới thiệu về hệ cơ sở dữ liệu phân tán Cassandra, kiến trúc và mô hìnhdữ liệu trong Cassandra. Đây là một tiểu luận khá mới, phần lớn là tham khảo từ tài liệunước ngoài, không thể tránh khỏi những thiếu xót. Chúng em mong thầy cô và các bạn gópý để kiến thức của chúng em ngày càng hoàn thiện hơn.Xin chân thành cảm ơn.

TÀI LIỆU THAM KHẢO

1. Apache Cassandra™ Documentation (http://www.datastax.com/doc-source/pdf/cassandra10.pdf )2. Cassandra: The Definitive Guide – Eben Hewitt3. Cassandra 2.0 Tutorial V1.0 Sébastien Jourdain, Fatiha Zeghir 2005/06/014. Cassandra – An Introduction Mikio L. Braun Leo Jugel TU Berlin, twimpactLinuxTag Berlin, 13. May 2011