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

- Đố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ép

CPU 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ác

tệ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ỉ đọc

trong 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ệu

tương ứng được đẩy vào. Nguợc lại, Các lệnh ghi SSTable (tập tin dữ liệu) được xảy

ra một cách không đồng bộ và được đọc trong suốt thời gian Client tìm kiếm. Ngoài

ra, 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ối

và 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 cho

mỗ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 san

lấp).

• Số lượng nút

Số 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ước

tổ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ình

gắn kết.

• Mạng

Vì 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ác

truy 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

27



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ần

nhấ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ản

sao ở 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ắc

chắ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út

Nhìn chung, khi bạn có tường lửa giữa các máy, rất khó để chạy JMX qua một

mạ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à

28



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ư Amazon

EC2.

Đố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ơi

lư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 Cassandra

qua 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ĩa

là 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ông

mở rộng.

DataStax cung cấp một hình ảnh máy Amazon (AMI) cho phép bạn nhanh chóng

triển khai cụm Cassandra nhiều nút trên Amazon EC2. DataStax AMI khởi tạo tất cả các

nú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ông

sử dụng DataStaxAMI. Thay vì đó , khởi tạo EC2 cho mỗi nút Cassandra và sau đó cấu

hì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ằng

trong 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

29



Tính toán cho hao phí định dạng hệ thống tập tin (khoảng 10%) và mức RAID đang

sử 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 ổ đĩa

cho 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ến

cá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ơn

khi 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ưu

trong 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òng

trong 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ác

nhau, 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ỗi

dò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 quan

trọ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ó chi

phí 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 bao

gồm cả chi phí bản sao:

replication_overhead = total_data_size * (replication_factor - 1)



30



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ác

thuộ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ình

khá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 trung

tâ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ấu

hình cassandra.yaml. Mỗi nút nên được cấu hình đúng trước khi khởi động nó lần đầu

tiê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út

trong 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ình

Gossip. 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 bao

gồ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ịu

trách nhiệm.



31



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ỗi

lần khởi động nút (ví dụ, địa chỉ IP nút thay đổi), thì thêm dòng sau đây vào file

cassandra-env.sh.

File

nà

được

đặt

trong

/usr/share/cassandra

hoặc

/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ách

nhiệ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 được

thự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ác

cho 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 khai

cụ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ểu

diệ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ính

toá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. Xem

Calculating Tokens đối với các phương pháp khác nhau để sinh token cho mỗi nút trong

cá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 đến

nơ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ản

sao 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út

nê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ấu

hình thông tin về trung tâm dữ liệu và rách từ khi bắt đầu.

Cấu hình PropertyFileSnitch



32



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ái

gì 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 cho

mỗi nút trong cụm trong file cấu hình cassandra-topology.properties. File này được đặt

trong /etc/cassandra/conf/cassandra.yaml đối với chương trình cài đặt đã được đóng gói

hoặc trong /conf/cassandra.yaml đối với chương trình cài đặt ở dạng

nhị 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ới

hai 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ệu

phâ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

33



172.106.12.122=DC3:RAC1

# default for unknown nodes

default=DC3:RAC1



34



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

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

là, không giống cơ sở dữ liệu quan hệ, người sử dụng không cần mô hình hóa tất cả các

cột mà ứng dụng cần đến, vì mỗi dòng không cần phải có cùng một tập hợp các cột giống

nhau. Cột và siêu dữ liệu của nó có thể được thêm vào bởi ứng dụng khi cần mà không

làm dừng chương trình.



3.1 So sánh mô hình dữ liệu Cassandra với cơ sở dữ liệu quan hệ

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

Mặc dù nhu cầu so sánh Cassandra với cơ sở dữ liệu quan hệ là rất tự nhiên, nhưng chúng

hoàn toàn khác nhau. Trong cơ sở dữ liệu quan hệ, dữ liệu được lưu trong các bảng, các

bảng này tạo thành một ứng dụng mà chúng thường liên quan đến nhau. Dữ liệu được

chuẩn hóa để giảm các bản ghi dư thừa, và các bảng được kết nối bằng khóa để thỏa mãn

một truy vấn nào đấy. Ví dụ, xem xét một ứng dụng cho phép người dùng tạo các bài

blog. Trong ứng dụng này, bài blog được phân loại theo chủ đề (thể thao, thời trang …).

Người dùng có thể chọn đăng kí xem blog của những người khác. Trong ví dụ này, user

id là khóa chính trong bảng user, và là khóa ngoại trong các bảng blog và subcriber.

Tương tự, category id là khóa chính của bảng category và là khóa ngoại trong bảng

blog_entry. Sử dụng mô hình quan hệ, các truy vấn SQL có tể thực hiện join nhiều bảng

để trả lời câu hỏi “những người dùng nào đăng kí xem blog của tôi”, hay “cho tôi xem tất

cả các blog viết về thời trang” hay “cho tôi xem các bài viết mới nhất của các blog mà tôi

đăng kí”.



35



Trong Cassandra, keyspace là nơi chứa tất cả dữ liệu ứng dụng, tương tự với một

cơ sở dữ liệu hay lược đồ trong một cơ sở dữ liệu quan hệ. Bên trong keyspace là một

hoặc nhiều đối tượng column family tương tự như các bảng. Các column family chứa các

cột và một tập các cột được xác định bởi một row key do ứng dụng cung cấp. Mỗi dòng là

trong một column family không nhất thiết phải có cùng các cột.

Cassandra không áp đặt quan hệ giữa các column family như cách mà cơ sở dữ liệu

quan hệ thực hiện với các bảng: không có khóa ngoại trong Cassandra, và việc join các

column family khi truy vấn không được hỗ trợ. Mỗi column family có một tập các cột tự

chứa được dự định để được truy nhập cùng nhau để thỏa mãn các truy vấn nào đó từ ứng

dụng.

Ví dụ, sử dụng vó dụ ứng dụng blog ở trên, bạn có thể có một column family cho

user và blog entry như trong mô hình quan hệ. Sau đó, các column family khác có thể

được thêm vào để hỗ trợ truy vấn mà ứng dụng cần thực hiện. Ví dụ, để trả lời truy vấn

“những người dùng nào đăng kí xem blog của tôi” ”, hay “cho tôi xem tất cả các blog viết

về thời trang” hay “cho tôi xem các bài viết mới nhất của các blog mà tôi đăng kí”, bạn có

thể cần thiết kế các column family bổ sung để hỗ trợ những truy vấn này. Chú ý rằng cần

thực hiện một số phi chuẩn hóa đối với dữ liệu.



36