1. Trang chủ
  2. » Giáo Dục - Đào Tạo

Báo cáo Ứng dụng phân tán Đề tài hệ cơ sở dữ liệu phân tán cassandra

52 4 0
Tài liệu đã được kiểm tra trùng lặp

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Hệ Cơ sở dữ liệu phân tán Cassandra
Tác giả Đỗ Minh Hải Đăng, Dương Văn Khang, Dương Minh Hưng
Người hướng dẫn Nguyễn Phương Nam
Trường học Trường Đại Học Phenikaa
Chuyên ngành Ứng dụng phân tán
Thể loại Báo cáo
Năm xuất bản 2024
Thành phố Hà Nội
Định dạng
Số trang 52
Dung lượng 0,96 MB

Nội dung

Bạn có thể thay thế các nút lỗi trong cluster mà không gây ra thời gian chết, và bạn có thể sao chép dữ liệu đến nhiều trung tâm dữ liệu cung cấp cải thiện hiệu năng và giảm thời gian dừ

Trang 1

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC PHENIKAA

BÁO CÁO ỨNG DỤNG PHÂN TÁN

ĐỀ TÀI: HỆ CƠ SỞ DỮ LIỆU PHÂN TÁN CASSANDRA

Giảng viên hướng dẫn: Nguyễn Phương Nam

Lớp: Ứng dụng phân tán (N03)

Hà Nội – Năm 2024

Trang 2

Thành viên nhóm

Trang 3

MỤC LỤC

MỤC LỤC 1

MỞ ĐẦU 6

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 7

1.3 Khả năng mở rộng mềm dẻo 7

1.4 Tính sẵn sàng cao và khả năng chịu lỗi 8

1.5 Tính nhất quán tùy chỉnh 8

1.6 Hướng dòng – Row oriented 9

1.7 Schema – Free (không bị ràng buộc về lược đồ) 9

1.8 Hiệu năng cao 10

2 Kiến trúc Cassandra 11

2.1 Kết nối giữa các nút (giao thức Gossip) 11

2.2 Các thành viên của cụm và các nút hạt giống 11

2.3 Trạng thái dò thất bạo và sự phục hồi 12

2.4 Phân vùng dữ liệu trong Cassandra 12

2.4.1 Giới thiệu về Phân vùng trong 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 15

2.5 Nhân bản trong Cassandra 17

Trang 4

Chiến lược xác định vị trí nhân bản 18

2.6 Kiến trúc liên kết mạng 19

2.7 Snitches 22

Các dạng Snitch 23

2.8 Yêu cầu từ phía Client trong Cassandra 25

2.8.1 Yêu cầu ghi 25

Truy vấn ghi tới trung tâm đa dữ liệu 26

2.8.2 Truy vấn đọc 27

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

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

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

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

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

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

3.2 Keyspaces 39

3.3 Column Families 40

3.4 Columns 41

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

3.5.1 Expiring Columns 42

3.5.2 Counter Columns 43

3.5.3 Super Columns 43

Trang 5

3.6.1 Validators 45

3.6.2 Comparators 45

3.7 Nén column family 46

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

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

3.8 Chỉ mục trong Cassandra 48

3.8.1 Chỉ mục chính 48

3.8.2 Chỉ mục thứ cấp 48

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

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

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

3.9.2 Phi chuẩn hóa để tối ưu 50

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

3.9.4 Sử dụng các khóa dòng tự nhiên hoặc thay thế 51

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

KẾT LUẬN 52

TÀI LIỆU THAM KHẢO 52

Trang 6

MỞ ĐẦU

Ngày nay, các dịch vụ trên Internet phải xử lí khối lượng dữ liệu rất lớn Hầu hết dữ liệu sẽ được lưu trữ phân tán trên nhiều máy chủ khác nhau Các cơ sở dữ liệu quan hệ đang được triển khai hiện nay giải quyết rất tốt nhiệm vụ lưu trữ dữ liệu nhất định nào đó, nhưng

vì tính tập trung đó mà chúng có thể gây ra vấn đề khi mở rộng Và, người sử dụng thường muốn tìm cách để bớt các thao tác join nữa các bảng, tức là phi chuẩn hóa dữ liệu – việc lưu trữ nhiều bản sao lưu của dữ liệu phá vỡ hoàn toàn thiết kế ban đầu, cả trong cơ sở dữ liệu và ứng dụng Hơn nữa, chúng ta thường xuyên cần tìm đường xung quanh các giao dịch phân tán - nơi rất dễ hình thành nên các nút cổ chai Những hoạt động này thường không được hỗ trợ trực tiếp trong bất cứ cơ sở dữ liệu quan hệ nào Vì vậy, các hệ quản trị cơ sở

dữ liệu quan hệ (RDBMS) tỏ ra không còn phù hợp với các dịch vụ như thế này nữa Người

ta bắt đầu nghĩ tới việc phát triển các DBMS mới phù hợp để quản lí các khối lượng dữ liệu phân tán này Các DBMS này thường được gọi là NoSQL Một đại diện nổi bật của các NoSQL là Cassandra

Cassandra là hệ cơ sở dữ liệu phân tán mã nguồn mở được bắt đầu bởi Facebook Năm 2008, Facebook chuyển nó cho cộng đồng mã nguồn mỡ và được Apache tiếp tục phát triển đến ngày hôm nay Cassandra được coi là sự kết hợp của Amazon’s Dynamo và Google’s BigTable Cassandra là một mô hình cơ sở dữ liệu phân tán hoàn toàn, có khả năng chịu lỗi cực tốt Một tính chất nữa là nó rất linh hoạt, tốc độ đọc/ghi tăng tuyến tính khi bổ sung thêm hạ tầng mới

Trong bài tiểu luận này, nhóm xin trình bày về những đặc trưng của hệ cơ sở dữ liệu phân tán Cassandra Tiếp theo là phần kiến trúc và mô hình dữ liệu mà Cassandra sử dụng

1 Những đặc trưng của Cassandra

1.1 Khái niệm

"Apache Cassandra là một mã nguồn mở, phân tán, không tập trung hóa, khả năng

mở rộng cao, tính sẵn sàng cao, chịu lỗi, tính nhất quán, cơ sở dữ liệu hướng cột dựa trên

cơ sở thiết kế phân tán trên Dynamo của Amazon và mô hình dữ liệu của nó trên Bigtable của Google Được tạo ra bởi Facebook, nó được sử dụng phổ biến nhất tại một số sites trên Web"

Trang 7

1.2 Phân tán và không tập trung hóa

Cassandra là phân tán, có nghĩa là nó có khả năng chạy trên nhiều máy trong khi xuất hiện trước người sử dụng như một thể thống nhất

Thực tế Cassandra không tập trung hóa có nghĩa là không có điểm lỗi duy nhất nào Tất cả các nút trong một cluster Cassandra hoạt động như nhau Điều này đôi khigọi là “máy chủ đối xứng” Bởi vì tất cả chúng đều làm những việc như nhau, và không có một máy chủ đặc biệt được phối điều phối các hoạt động, như với mô hình chủ /tớ trong MySQL, Bigtable, và những nhiều hệ cơ sở dữ liệu khác

Do đó, đặc điểm không tập trung hóa có hai ưu điểm quan trọng: nó đơn giản hơn sử dụng hơn mô hình chủ /tớ, và nó giúp bạn tránh việc hệ thống ngừng hoạt động Vì các node

là giống nhau nên việc thao tác và duy trì lưu trữ không tập trung hóa dễ dàng hơn so với

mô hình chủ/tớ Điều đó có nghĩa bạn không cần bất kỳ kiến thức đặc biệt để mở rộng, thiết lập 50 nút không khác nhau nhiều lắm so với thiết lập một nút Hơn nữa, trong một thiết lập master/slave, master có thể trở thành một điểm lỗi duy nhất (SPOF) Để tránh điều này, bạn thường cần phải tăng thêm tính phức tạp để môi trường có nhiều master Bởi vì tất cả các bản sao trong Cassandra đều đồng nhất, một nút bị lỗi sẽ không làm gián đoạn dịch vụ

Theo một cách ngắn gọn hơn, bởi vì Cassandra được phân phối và không tập trung,

nó không có điểm lỗi duy nhất, và hỗ trợ sẵn sàng cao

1.3 Khả năng mở rộng mềm dẻo

Khả năng mở rộng là một tính năng kiến trúc của một hệ thống cho phép nó có thể tiếp tục phục vụ số yêu cầu lớn hơn với hoạt động ít bị suy giảm Mở rộng theo chiều dọc - chỉ đơn giản thêm khả năng phần cứng và bộ nhớ máy tính hiện tại - là cách dễ nhất để đạt được điều này Mở rộng theo chiều ngang, có nghĩa là thêm nhiều máy chứa tất cả hoặc một phần dữ liệu để không có máy nào phải chịu toàn bộ gánh nặng của yêu cầu phục vụ Nhưng sau đó phần mềm bản thân nó phải có một cơ chế nội bộ để giữ dữ liệu của nó đồng bộ với các nút khác trong cluster

Khả năng mở rộng mềm dẻo, đề cập đến một đặc tính đặc biệt của mở rộng theo chiều ngang Nó có nghĩa là cluster của bạn có thể mở rộng quy mô và giảm quy mô xuống một cách liền mạch Để làm điều này, các cụm phải có khả năng chấp nhận các nút mới có thể bắt đầu tham gia bằng cách nhận được một bản sao của một số hoặc tất cả dữ liệu và bắt

Trang 8

đầu phục vụ yêu cầu người sử dụng mới mà không có sự gián đoạn lớn hoặc cấu hình lại toàn bộ cluster.Bạn không cần phải khởi động lại quá trình của bạn.Bạn không cần thay đổi các truy vấn ứng dụng của bạn Bạn không phải tự cân bằng lại các dữ liệu Chỉ cần thêm một máy - Cassandra sẽ tìm thấy nó và làm nó hoạt động

Mở rộng quy mô xuống, tất nhiên, có nghĩa là loại bỏ một số khả năng xử lý của cluster Bạn có thể phải làm điều này nếu bạn di chuyển một phần ứng dụng của bạn sang nền tảng khác, hoặc nếu ứng dụng của bạn bị giảm số lượng người dùng và bạn cần phải bắt đầu bán bớt phần cứng.Chúng ta hãy hy vọng điều đó không xảy ra.Nhưng nếu có, bạn

sẽ không cần phải phá vỡ toàn hệ thống để có quy mô nhỏ lại

1.4 Tính sẵn sàng cao và khả năng chịu lỗi

Trong thuật ngữ kiến trúc nói chung, tính sẵn sàng của một hệ thống được đánh giá dựa trên khả năng đáp ứng các yêu cầu của hệ thống đó Nhưng máy tính có thể mắc phải rất nhiều kiểu lỗi, từ lỗi phần cứng đến việc đứt mạng Và đa số các máy tính không thể tránh khỏi các loại lỗi này Tất nhiên, có một số máy tính phức tạp có thẻ tự mình làm giảm thiểu các lỗi này, vì chúng có nhiều phần cứng thay thế, và có khả năng gửi thông báo về các sự kiện lỗi để tự chuyển đổi các thành phần phần cứng của mình Nhưng bất cứ ai có thể vô tình làm hỏng một cáp Ethernet, và nó sẽ cô lập một trung tâm dữ liệu duy nhất Vì vậy, để một hệ thống được đánh giá là có tính sẵn sàng cao, nó thường phải bao gồm nhiều máy tính nối mạng,và phần mềm mà họ đang chạy phải có khả năng điều hành trong một cluster và có một vài cơ chế nhận diện lỗi ở các node thông qua yêu cầu tới các phần khác của hệ thống

Cassandra có tính sẵn sàng cao Bạn có thể thay thế các nút lỗi trong cluster mà không gây ra thời gian chết, và bạn có thể sao chép dữ liệu đến nhiều trung tâm dữ liệu cung cấp cải thiện hiệu năng và giảm thời gian dừng nếu một trung tâm dữ liệu phải đối mặt với một thảm họa như hỏa hoạn hoặc lũ lụt

1.5 Tính nhất quán tùy chỉnh

Tính nhất quán cơ bản có nghĩa là thao tác đọc luôn được trả về giá trị bản ghi mới nhất Hãy xem xét việc hai khách hàng đang cố gắng để đặt cùng một mặt hàng vào giỏ hàng của họ trên một trang web thương mại điện tử Nếu tôi đặt mặt hàng cuối cùng trong kho vào giỏ hàng của tôi ngay lập tức sau khi bạn làm việc đó, bạn sẽ nhận có hàng được

Trang 9

này được đảm bảo để xảy ra khi trạng thái của thao tác ghi là nhất quán giữa tất cả các nút

có dữ liệu đó

Tuy nhiên, việc mở rộng quy mô lưu trữ dữ liệu nghĩa là chúng ta phải đánh đổi giữa tính nhất quán, tính sẵn sàng và khả năng chịu lỗi (chúng ta chỉ có thể lựa chọn 2 trong 3 đặc điểm này) Và Cassandra đã ưu tiên tính sẵn sàng hơn là tính nhất quán Vì thế, Cassandra có đặc điểm là “tùy chỉnh tính nhất quán”, tức là nó cho phép người dùng điều chỉnh mức độ nhất quán theo yêu cầu, trong sự cân nhắc với mức độ sẵn sàng Mức độ nhất quán là một thiết lập mà client phải chỉ ra trên mỗi thao tác và cho phép bạn quyết định bao nhiên bản sao trong cluster phải nhận biết thao tác ghi hay đáp ứng lại thao tác đọc để được xem là thành công

1.6 Hướng dòng – Row oriented

Cassandra thường được gọi là cơ sở dữ liệu hướng dòng, và điều này không sai

Nó không có quan hệ, và nó thể hiện cấu trúc dữ liệu của mình trong những hashtable đa chiều rải rác Rải rác nghĩa là với một dòng bất kỳ, bạn có thể có một hoặc nhiều cột, nhưng mỗi dòng không cần phải có tất cả các cột giống nhau như trong cơ sở dữ liệu quan hệ Mỗi dòng có một khóa riêng làm cho dữ liệu của nó có thể truy cập được

Cassandra lưu trữ dữ liệu trong bảng băm đa chiều nên bạn có thể không cần phải quyết định trước cấu trúc dữ liệu của mình nên như thế nào, hoặc các bản ghi cần những trường gì… Điều này rất có lợi nếu bạn vừa mới bắt đầu phát triển ứng dụng, việc thêm vào hoặc loại bỏ các chức năng là khá thường xuyên Tuy nhiên, điều này không có nghĩa là bạn hoàn toàn không phải suy nghĩ gì về cấu trúc dữ liệu Cassandra khiến bạn có suy nghĩ khác

đi về nó Thay vì thiết kế một mô hình dữ liệu ban đầu và sau đó thiết kế các truy vấn xung quanh mô hình đó như trong hệ cơ sở dữ liệu quan hệ, bạn có thể tự do nghĩ về các truy vấn trước, và sau đó cung cấp dữ liệu để trả lời những truy vấn đó

1.7 Schema – Free (không bị ràng buộc về lược đồ)

Cassandra yêu cầu bạn định nghĩa một container gọi là keyspace chứa các column family Keyspace thực chất chỉ là một namespace logic để giữ các column family và thuộc tính cầu hình cụ thể Ngoài ra, các bảng dữ liệu rải rác bên bạn có thể chỉ cần đưa dữ liệu vào đó, sử dụng cột mình muốn, và không cần phải định nghĩa trước các cột Thay vì mô hình hóa dữ liệu bằng các công cụ mô hình hóa đắt tiền, và viết những câu truy vấn phức

Trang 10

tạp, Cassandra cho phép bạn mô hình hóa các truy vấn mình cần, và sau đó cung cấp dữ

liệu cho nó

1.8 Hiệu năng cao

Cassandra được thiết kế nhằm mục đích tận dụng được ưu điểm của các máy đa xử

lý/ đa lõi, và để chạy trên nhiều nhiều máy ở nhiều trung tâm dữ liệu với khối lượng dữ liệu

khổng lồ Cassandra có thể hoạt động tốt thậm chí dưới tải công việc cao Thao tác ghi trong

Cassandra cũng được thực hiện rất nhanh chóng Khi bạn thêm nhiều server, bạn có thể duy

trì tất cả đặc tính mong muốn của Cassandra mà không phải hy sinh hiệu năng hoạt động

Trang 11

2 Kiến trúc Cassandra

Cassandra được thể hiện là một tập hợp của các nút độc lập được cấu hình lại với nhau thành một cụm (Cluster).Trong một cụm, tất cả các nút là ngang hàng, có nghĩa là không có nút chính hoặc nút trung tâm quản lý các tiến trình Một nút có thể tham gia một cụm Cassandra dựa trên các khía cạnh nhất định trong cấu hình của nó Phần này giải thích những khía cạnh của kiến trúc cụm Cassandra

2.1 Kết nối giữa các nút (giao thức Gossip)

Cassandra sử dụng một giao thức gọi là tin đồn (Gossip) để khám phá vị trí và thông tin trạng thái về các nút khác tham gia trong một cụm Cassandra Gossip là một giao thức truyền thông ngang hàng, trong đó các nút định kỳ trao đổi thông tin trạng thái về bản thân

và về các nút khác mà chúng biết

Trong Cassandra, quá trình Gossip chạy mỗi giây và mỗi nút trao đổi các thông báo trạng thái của nó tối đa với 3 nút khác trong cluster Các nút thông tin trao đổi về bản thân

và về các nút khác mà họ nó đã được biết, do đó, tất cả các nút nhanh chóng tìm hiểu về tất

cả các nút khác trong cụm (cluster) Một Gossip có một phiên bản liên kết với nó, do đó trong quá trình trao đổi tin đồn, với mỗi nút cụ thể thông tin cũ hơn bị ghi đè bằng các trạng thái hiện tại cập nhật của nó

2.2 Các thành viên của cụm và các nút hạt giống

Khi một nút bắt đầu, nó nhìn vào tập tin cấu hình của nó để xác định tên của cụm Cassandra chứa nó và nút được gọi là hạt giống để liên hệ, có được thông tin về các nút khác trong cluster điểm liên lạc của các cụm được cấu hình trong file cassandra.yaml cho mỗi nút

Để ngăn chặn sự đứt đoạn trong truyền thông tin đồn (gossip), tất cả các nút trong cluster phải có cùng một danh sách các nút hạt giống được liệt kê trong tập tin cấu hình của

nó Điều này là quan trọng nhất khi một nút khởi động Theo mặc định, một nút sẽ nhớ các nút khác, nó đã có giao tiếp kể cả khi khởi động lại

Chú ý: Các nút hạt giống được thiết kế không có mục đích nào khác hơn khởi động quá trình loan tin đồn cho các nút mới gia nhập nhóm

Trang 12

2.3 Trạng thái dò thất bạo và sự phục hồi

Dò thất bại là thông qua trạng thái của tin đồn (gossip), từ 1 nút xác định xem các nút khác trong hệ thống đang online hay offline Thông tin dò thất bại cũng được sử dụng trong Cassandra để tránh định tuyến các yêu cầu từ máy khách đến các nút không thể truy cập được (Cassandra cũng có thể tránh được các yêu cầu định tuyến các nút còn sống, nhưng hoạt động kém, qua dynamic snitch)

Trong quá trình truyền tải các bản tin từ các nút khác cả trực tiếp (các nút giao tiếp trực tiếp đến nó) và gián tiếp (thông tin có được khi nghe qua 2 nút, 3 nút …), Cassandra

sử dụng một cơ chế tính toán một ngưỡng cho mỗi nút dựa vào điều kiện mạng, khối lượng công việc, hoặc các điều kiện khác mà có thể ảnh hưởng đến quá trình truyền tải Trong quá trình trao đổi tin đồn, mỗi nút duy trì một cửa sổ trượt báo các thông báo tin đồn từ các nút khác trong cluster Trong Cassandra, cấu hình phi_convict_threshold điều chỉnh độ nhạy cho việc dò thất bại Các giá trị mặc định là fine cho hầu hết các tình huống, nhưng DataStax

đề nghị tăng đến 12 cho Amazon EC2 do tắc nghẽn mạng thường xuyên xảy ra trên nền tảng đó

Node có thể thất bại do nhiều nguyên nhân khác nhau như thất bại phần cứng, mất mạng… Để chính thức thay đổi nút thành viên trong một cluster, các quản trị viên sử dụng tiện ích nodetool để thêm hoặc loại bỏ các nút trong một cụm Cassandra

Khi một node trở lại trực tuyến sau khi không hoạt động, nó có thể đã bỏ lỡ việc sao chép các dữ liệu mà nó duy trì Một khi quá trình dò thất bại đánh dấu một nút là offline, nếu như hinted handoff được kích hoạt thì quá trình ghi nhớ được thực hiện bởi các bản sao khác Tuy nhiên, nó có thể xảy ra tình huống việc ghi bị bỏ lỡ giữa khoảng thời gian của một nút thực sự offline cho tới khi nó bị phát hiện là offline Hoặc nếu một nút không hoạt động lâu hơn max_hint_window_in_ms (mặc định là một giờ), gợi ý sẽ không còn được lưu lại Vì lý do đó, tốt nhất là thường xuyên chạy nodetool sửa chữa tất cả các nút để đảm bảo chúng toàn vẹn dữ liệu, và cũng chạy repair sau khi hồi phục một nút đã offline trong một thời gian dài

2.4 Phân vùng dữ liệu trong Cassandra

Khi bạn khởi động một cụm Cassandra, bạn phải chọn cách thức dữ liệu sẽ được chia trên các nút trong cluster Điều này được thực hiện bằng cách chọn một phân vùng cho cluster

Trang 13

Trong Cassandra, tổng số dữ liệu được quản lý bởi 1 cụm được đại diện như là một không gian hoặc vòng tròn Vòng tròn được chia tương ứng với phạm vi và số lượng các nút, mỗi nút chịu trách nhiệm cho một hoặc nhiều vùng của toàn bộ dữ liệu Trước khi một nút có thể tham gia vòng, nó phải được gán một thẻ bài Thẻ bài xác định vị trí của nút trên vòng tròn và phạm vi của dữ liệu nó chịu trách nhiệm

Các cột dữ liệu được phân chia qua các nút dựa trên khóa hàng Để xác định các nút bản sao đầu tiên của một dòng còn sống, vòng tròn được quay theo chiều kim đồng hồ cho đến khi nó định vị các nút với một giá trị thẻ lớn hơn giá trị khóa hàng Mỗi nút có trách nhiệm đối với 1 khu vực xác định trong vòng tròn giữa bản thân và nút chịu trách nhiệm ở khu vực liền kề nó.Với các nút được sắp xếp theo thứ tự thẻ bài, nút cuối cùng được coi là tiền thân của nút đầu tiên

Ví dụ, hãy xem xét một cụm đơn giản gồm 4 nút, nơi tất cả các dữ liệu được quản

lý bởi 1 cụm được đánh số trong khoảng từ 0 đến 100 Mỗi nút được gán một thẻ bài đại diện cho một điểm trong phạm vi này Trong ví dụ đơn giản này, các thẻ có giá trị là 0, 25,

50, và 75 Nút đầu tiên, với token 0, chịu trách nhiệm về phạm vi gói (75-0) Nút với thẻ bài thấp nhất cũng chấp nhận khóa hàng ít hơn so với các mã thẻ bài thấp nhất và nhiều hơn với các mã thẻ bài cao nhất

Trang 14

2.4.1 Giới thiệu về Phân vùng trong cụm Trung tâm đa dữ liệu

Trong triển khai trung tâm đa dữ liệu, vị trí bản sao được tính cho mỗi trung tâm dữ liệu dựa vào chính sách NetworkTopologyStrategy Trong mỗi trung tâm dữ liệu (hoặc nhóm nhân bản), bản sao đầu tiên cho một hàng cụ thể được xác định bởi giá trị thẻ bài gán cho một nút Các bản sao trong cùng một trung tâm dữ liệu được xác định bằng việc dịch chuyển vòng theo chiều kim đồng hồ cho đến khi nó tìm được nút đầu tiên trong bánh răng (rack) khác

Nếu bạn không tính toán thẻ phân vùng để đảm bảo dữ liệu được phân bố đều cho mỗi trung tâm dữ liệu, bạn có thể gặp phải tình trạng phân phối dữ liệu không đồng đều trong mỗi trung tâm dữ liệu

Mục đích là để đảm bảo rằng các nút tại mỗi trung tâm dữ liệu đều được phân chia thẻ bài trên phạm vi tổng thể Nếu không, bạn có thể gặp tình trạng các nút trong mỗi trung tâm dữ liệu sở hữu một số lượng không cân xứng các khóa hàng Mỗi trung tâm dữ liệu phải được phân chia một cách độc lập, tuy nhiên việc gán thẻ bài trong phạm vi 1 cụm không được xung đột với nhau (mỗi node phải có một thẻ duy nhất) Xem

Calculating Tokens for a Multi-Data Center Cluster cho các chiến lược về việc làm thế nào

để sinh các thẻ cho các cụm trung tâm đa dữ liệu

Trang 15

2.4.2 Hiểu biết về các loại phân vùng

Không giống như hầu hết các lựa chọn cấu hình khác trong Cassandra, phân vùng chỉ có thể thay đổi được khi tải lại tất cả các dữ liệu Bởi vậy cần lựa chọn và cấu hình phân vùng chính xác trước khi khởi tạo cluster Cassandra cung cấp một số phân vùng out-of-the-box, nhưng các phân vùng ngẫu nhiên là sự lựa chọn tốt nhất khi triển khai Cassandra

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

RandomPartitioner là phân vùng đã mặc định cho một cụm Cassandra, và trong hầu hết các trường hợp là sự lựa chọn đúng Việc phân vùng ngẫu nhiên sử dụng hàm băm phù hợp để xác định xem nút nào sẽ lưu trữ hàng nào Không giống như việc sử dụng modulus-by-node-count, hàm băm phù hợp đảm bảo rằng khi các nút được thêm vào cluster, số lượng

dữ liệu bị ảnh hưởng là ít nhất

Để phân phối các dữ liệu đều qua các nút, một thuật toán băm tạo ra một giá trị MD5 hash của khóa hàng Phạm vi có thể của giá trị băm là từ 0 đến 2 ** 127 Mỗi nút trong cụm được gán một thẻ bài đại diện một giá trị hash trong phạm vi này Một nút sau

Trang 16

đó sở hữu các hàng với một giá trị hash ít hơn số thẻ bài của nó Đối với việc triển khai trung tâm dữ liệu đơn lẻ, các thẻ bài được tính bằng cách chia phạm vi băm bởi số lượng các nút trong cluster Đối với việc triển khai nhiều trung tâm dữ liệu, thẻ được tính cho mỗi trung tâm dữ liệu (khoảng băm nên được chia đều cho các nút trong mỗi nhóm nhân bản)

Lợi ích chính của phương pháp này là một khi thẻ của bạn được đặt phù hợp, dữ liệu

từ tất cả các cột được phân bố đều trên toàn cụm mà không tốn nhiều thời gian xử lý Ví dụ, một cột có thể được sử dụng tên người dùng như là khóa hàng và một nhãn thời gian cột, các khóa hàng từ mỗi cột riêng lẻ vẫn luân chuyển đồng đều Điều này có nghĩa là đọc và viết các yêu cầu của cluster cũng sẽ được phân bố đều

Một lợi ích của việc sử dụng phân vùng ngẫu nhiên là đơn giản hóa việc cân bằng tải tại mỗi cụm Bởi vì mỗi một phần trong phạm vi băm sẽ nhận được một số lượng trung bình cộng các hàng, nó làm cho việc gán thẻ bài cho các nút mới được dễ dàng hơn

Phân vùng theo thứ tự

Việc phân vùng theo thứ tự đảm bảo rằng các khóa hàng được lưu trữ theo thứ tự sắp xếp DataStax khuyến cáo bạn lựa chọn cách phân vùng ngẫu nhiên trên một phân vùng trừ khi ứng dụng của bạn thực sự cần cách phân vùng khác

Sử dụng một phân vùng đã được sắp xếp cho phép quét số lượng hàng lớn, có nghĩa

là bạn có thể quét các hàng như thể bạn đang di chuyển con trỏ thông qua một chỉ số truyền thống Ví dụ, nếu ứng dụng của bạn có tên người sử dụng như là khóa hàng, bạn có thể quét hàng cho người sử dụng có tên ở giữa Jake và Joe Đây là loại truy vấn sẽ không thực hiện được với các phân vùng có khóa hàng ngẫu nhiên, vì các khóa được lưu trữ trong thứ tự của bảng băm MD5 của nó (không phải theo tuần tự)

Phân vùng theo thứ tự không được khuyến khích vì những lý do sau:

Việc tuần tự ghi dữ liệu có thể gây ra điểm nóng Nếu ứng dụng của bạn có xu hướng ghi hoặc cập nhật một khối liên tục các hàng tại một thời điểm mà việc viết không được phân phối trên cluster, đều thực hiện trên một nút Điều này thường xuyên là một vấn đề với các ứng dụng xử lý dữ liệu nhãn thời gian

Cần phí quản lý cao để cân bằng tải trong cluster Một phân vùng theo thứ tự yêu cầu quản trị viên tự tính toán phạm vi thẻ bài dựa trên các ước tính của họ về phân phối khóa

Trang 17

hàng Trong thực tế, điều này đòi hỏi các nút tích cực di chuyển thẻ bài để thích ứng với phân phối thực tế của dữ liệu khi nó được tải

Cân bằng tải không đồng đều giữa các cột liên quan Nếu ứng dụng của bạn có nhiều cột, rất có thể là những cột có khóa hàng khác nhau và phân phối dữ liệu khác nhau Một phân vùng theo thứ tự có thể dẫn đến phân phối không đồng đều cho các cột trong cùng một cụm

Với Cassandra, có ba sự lựa chọn trong việc xây dựng phân vùng theo thứ tự: ByteOrderedPartitioner – khóa hàng được lưu trữ theo thứ tự các raw byte thay vì chuyển đổi chúng sang các chuỗi mã hóa Tokens được tính bằng cách nhìn vào các giá trị thực tế của dữ liệu, sử dụng hệ thập lục phân cho các ký tự đầu trong khóa Ví dụ, nếu bạn muốn hàng phân vùng theo thứ tự bảng chữ cái, bạn có thể chỉ định thẻ A bằng cách sử dụng

hệ thập lục phân đại diện là 41

OrderPreservingPartitioner – khóa hàng được lưu trữ theo thứ tự dựa trên mã

UTF8 Yêu cầu khóa hàng phải mã hóa theo UTF-8 CollatingOrderPreservingPartitioner – khóa hàng được lưu trữ theo thứ tự dựa trên tiếng Anh Mỹ Cũng yêu cầu các khóa hàng phải mã hóa theo UTF-8

2.5 Nhân bản trong Cassandra

Nhân bản là quá trình lưu trữ các bản sao của dữ liệu trên nhiều nút để đảm bảo độ tin cậy và khả năng chịu lỗi Khi bạn tạo một keyspace (không gian khóa) trong Cassandra, bạn phải có chính sách quyết định vị trí các bản sao: số lượng bản sao và cách những bản sao được phân phối trên các nút trong cluster Chiến lược nhân bản dựa trên cấu hình của cụm để giúp xác định vị trí vật lý của các nút và khoảng cách giữa chúng

Tổng số bản sao trên cluster thường được gọi là nhân tố nhân bản Một nhân tố nhân bản của 1 có nghĩa là chỉ có một bản sao của mỗi hàng Một nhân tố nhân bản của 2 có nghĩa là có hai bản sao cho mỗi hàng Tất cả các bản sao được quan trọng như nhau, không

có bản sao nào được coi là chính, phụ về cách đọc và ghi khi xử lý các request

Như một quy luật chung, các nhân tố nhân bản không được vượt quá số lượng các nút trong cluster Tuy nhiên, có thể để tăng nhân tố nhân bản, và sau đó thêm số lượng mong muốn của các nút sau đó Khi nhân tố nhân bản vượt quá số lượng các nút, lệnh ghi sẽ bị từ chối, nhưng lệnh đọc sẽ được phục vụ miễn là đáp ứng được mức độ nhất quán

Trang 18

(consistency level)

Chiến lược xác định vị trí nhân bản

Replica placement strategy (chiến lược xác định vị trí bản sao) cách thức phân phối không gian khóa giữa các bản sao trên cluster chiến lược xác định vị trí bản sao được thiết lập khi bạn tạo một keyspace Có một số chiến lược để lựa chọn dựa trên mục tiêu của bạn

và các thông tin bạn có về vị trí các nút

Chiến lược đơn giản

SimpleStrategy là cách mặc định khi tạo một keyspace bằng cách sử dụng Cassandra CLI Công cụ khác, chẳng hạn như CQL, yêu cầu bạn phải xác định rõ ràng một chiến lược

SimpleStrategy đặt bản sao đầu tiên trên một nút được xác định bằng partitioner (cách phân vùng) Bản sao bổ sung được đặt trên các nút tiếp theo trong vòng theo chiều kim đồng hồ mà không xem xét vị trí các nút hoặc vị trí trung tâm dữ liệu

Trang 19

2.6 Kiến trúc liên kết mạng

NetworkTopologyStrategy là chiến lược nhân bản được ưa thích khi bạn có thông tin về cách thức các nút được nhóm lại trong trung tâm dữ liệu của bạn, hoặc bạn có (hoặc kế hoạch có) cluster triển khai trên nhiều trung tâm dữ liệu Chiến lược này cho phép bạn xác định có bao nhiêu bản sao bạn muốn trong mỗi trung tâm dữ liệu

Khi quyết định có bao nhiêu bản sao để cấu hình trong mỗi trung tâm dữ liệu, xem xét chính là (1) đảm bảo dữ liệu được đọc tốt tại mỗi trung tâm dữ liệu, không có trễ, và (2) kịch bản khi thất bại

Hai cách phổ biến nhất để cấu hình các cụm trong nhiều trung tâm dữ liệu là:

Trang 20

➢ Tạo hai bản sao trong mỗi trung tâm dữ liệu Cấu hình này đảm bảo khi 1 nút đơn lẻ trong 1 nhóm nhân bản bị lỗi vẫn cho phép đọc được dữ liệu (ở một mức độ nhất quán ONE)

➢ Tạo ba bản sao trong mỗi trung tâm dữ liệu Cấu hình này sử dụng phục vụ các nhu cầu truy cập thời gian thực

Trong Cassandra khái niệm trung tâm dữ liệu và nhóm nhân bản là tương tự nhau, nhóm nhân bản là nhóm các nút được cấu hình lại với nhau phục vụ cho việc nhân bản Với NetworkTopologyStrategy, vị trí bản sao được xác định độc lập trong mỗi trung tâm dữ liệu (hoặc nhóm nhân bản) Bản sao đầu tiên tại mỗi trung tâm dữ liệu được đặt theo các phân vùng (giống như với SimpleStrategy) Bản sao sau đó trong cùng một trung tâm dữ liệu được xác định bằng cách tiến theo chiều kim đồng hồ cho đến khi một nút ở 1 rack khác từ nhân bản trước đó được tìm thấy Nếu không có nút như vậy, bản sao bổ sung sẽ được đặt trong cùng một rack NetworkTopologyStrategy ưu tiên đặt các bản sao lên các rack riêng biệt nếu có thể Các nút trong cùng một rack (hoặc tương đương nhóm vật lý) có thể dễ dàng lỗi cùng 1 thời gian do nguồn, lỗi phần cứng hoặc các vấn đề mạng Dưới đây là một

ví dụ về cách NetworkTopologyStrategy đặt bản sao giữa hai trung tâm dữ liệu với 4 nhân

tố nhân bản (hai bản sao ở Trung tâm dữ liệu 1 và hai bản sao trong Trung tâm dữ liệu 2):

Trang 22

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

Trang 23

Các dạng Snitch

SimpleSnitch (Snitch đơn giản)

SimpleSnitch (mặc định) là thích hợp nếu bạn không có thông tin về rack hoặc trung tâm thông tin dữ liệu có sẵn Triển khai trung tâm dữ liệu duy nhất (hoặc một vùng trong đám mây công cộng) thường rơi vào loại này Nếu sử dụng snitch, dùng replication_factor

= <#> khi xác định phạm vi khóa của bạn Snitch này không xác định được thông tin về trung tâm dữ liệu hoặc rack

Trang 24

RackInferringSnitch

RackInferringSnitch xác đinh cấu trúc liên kết của mạng bằng cách phân tích địa chỉ

IP của các nút Snitch này giả định rằng các octet thứ hai xác định các trung tâm dữ liệu chứa nút đó, và các octet thứ ba xác định các rack

PropertyFileSnitch

PropertyFileSnitch xác định vị trí của các nút bằng cách sử dụng định nghĩa của người dùng trong file: cassandra-topology.properties Snitch này là tốt nhất khi IP của các nút là không thống nhất hoặc bạn có yêu cầu nhân bản phức tạp Xem Cấu hình

PropertyFileSnitch để biết thêm thông tin Dùng Snitch này bạn có thể đặt tên trung tâm dữ liệu của mình theo tên mong muốn được định nghĩa trong flie: cassandra-

Ví dụ, nếu một nút ở trung tâm dữ liệu có tên us-east-1a, us-east thì vị trí rack là 1a

Dynamic Snitching (Snitching động)

Theo mặc định, tất cả snitches cũng sử dụng một lớp snitch động giám sát độ trễ khi đọc, định tuyến các yêu từ client tránh xa các nút hiệu năng thấp Snithc động được kích hoạt theo mặc định, và được khuyến khích sử dụng trong tất cả các phạm vi

Snitching động được cấu hình trong file cassandra.yaml cho mỗi nút

Trang 25

2.8 Yêu cầu từ phía Client trong Cassandra

Các nút trong Cassandra là ngang hàng 1 client đọc hay viết các yêu cầu có thể làm việc với bất kỳ nút nào trong cụm Khi một client kết nối đến một nút và đưa ra các yêu cầu đọc hoặc viết, nút đóng vai trò là điều phối viên cho các hoạt động đó

Điều phối viên hoạt động như một proxy giữa các ứng dụng khách hàng và các nút (hoặc bản sao) chứa các dữ liệu được yêu cầu Điều phối viên xác định nút nào trong vòng

sẽ nhận được các yêu cầu dựa trên cấu hình phân vùng cụm và chiến lược đặt vị trí bản sao

2.8.1 Yêu cầu ghi

Để ghi dữ liệu, điều phối viên gửi yêu cầu ghi cho tất cả các bản sao sở hữu hàng đang được ghi Miễn là tất cả các nút sao đang hoạt động và rảnh, chúng sẽ ghi dựa vào consistency level trong yêu cầu của client Mức độ nhất quán ghi xác định có bao nhiêu nút nhân bản phải đáp ứng yêu cầu thì việc ghi mới được coi là thành công

Ví dụ, trong một trung tâm dữ liệu của 1 cụm có 10 nút với nhân tố nhân bản là 3, yêu cầu ghi sẽ đi đến tất cả 3 nút sở hữu hàng yêu cầu Nếu mức độ thống nhất ghi theo quy định của cliet là ONE, nút đầu tiên hoàn tất việc ghi sẽ báo về cho điều phối viên, sau điều phối viên sẽ nhắn tin thành công lại cho client Một mức độ nhất quán ONE có nghĩa rằng

nó có thể có 2 trong 3 bản sao có thể bỏ lỡ việc ghi nếu chúng đang down tại thời điểm yêu cầu được đưa ra Nếu 1 bản sao bỏ việc ghi, hàng dữa liệu đó sẽ được thực hiện phù hợp sau đó thông qua một cơ chế tự sửa lỗi của Cassandra

Trang 26

Truy vấn ghi tới trung tâm đa dữ liệu

Trong sự triển khai trung tâm đa dữ liệu, Cassandra tối ưu hiệu năng ghi bằng việc chọn một nút điều phối trong mỗi trung tâm dữ liệu từ xa để xử lý những truy vấn tới các bản sao trong trung tâm dữ liệu Nút điều phối được liên hệ bởi ứng dụng Client chỉ yêu cầu chuyển tiếp truy vấn ghi tới mỗi nút trong trung tâm dữ liệu từ xa

Nếu sử dụng mức độ nhất quán là 1 hoặc LOCAL_QUORUM, thì chỉ những nút trong cùng trung tâm dữ liệu với nút điều phối phải phản hồi lại truy vấn của Client là truy vấn thành công Theo cách này thì vị trí địa lý không ảnh hưởng tới thời gian phản hồi truy vấn Client

Ngày đăng: 20/10/2024, 09:19

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w