Database Distributed Architecture


Database Clustering, Parttitioning, Replication, Sharding
& CQRS 

Database architecture đã được chú trọng từ rất sớm, trong suốt những năm đầu của thập niên 90 các kiến trúc sư đã đặt nền móng cho các database có quy mô lớn từ bấy giờ. Tính đến thời điểm hiện tại có rất nhiều mô hình kiến trúc database nhằm giải quyết các bài toán khác nhau, có những ưu nhược điểm khác nhau. Trong bài này chúng ta sẽ ngó qua một số những kiến trúc cốt lõi của database nhé!

Replication 
——————
Chiến lược duplicate dữ liệu ở tất cả các node, có rất nhiều mô hình từ đơn giản như Master-Slave hay là Master-Master, Leader-Followers
Hình dung nôm na là chúng ta dựng lên nhiều database instances ở các máy chủ vật lý khác nhau, có cùng cấu trúc database

Master nhận nhiệm vụ hứng dữ liệu sau đó replicate tới tất cả các slaves, quá trình replicate này có thể gặp vấn đề nếu như một salve ngắt kết nối với hệ thống, sau đó quá trình replicate phải được thực hiện lại. Nếu con master ngỏm thì cả hệ thống sập, sau này người ta khắc phục bằng Master-Standby-Slaves nghĩa là có thể có 2 con masters nhưng một con active và con còn lại standby nếu một con ngỏm thì dựng con khác dậy thay thế.
Với mô hình này thì tốn kém tài nguyên, dữ liệu duplicate rất lớn, hệ thống vận hành một khối dữ liệu lớn cũng rất vất vả và tốn kém chi phí do RAM và CPU đòi hỏi nhiều hơn

Parttitioning 
——————
Chiến lược là chia nhỏ khối database lớn kia ra theo kiểu modular, bạn có thể có module user, module top ranking, hot sale… kiểu kiểu như vậy. Người ta triển khai theo các cơ chế như fragmenting, single node.
Với mô hình thiết kế này xây dựng query trở lên rất phức tạp, tuy nhiên nó có ưu điểm là nhanh và giảm được duplicate, ít tiêu hao tài nguyên…

Clustering
——————
Chiến lược là dùng nhiều application servers để truy cập cùng một tài nguyên, sử dụng cho những tính toán song song, tính toán kiểu nhạy cảm. Mục đích chính là để nhiều chương trình cùng đồng thời truy xuất được tài nguyên
Clustering cũng cần xây dựng Controller để quản lý các clusters nhiều trường phái họ có cách gọi như là xây dựng master-slaves để quản lý các clusters vậy.

Sharding
——————
Là cách mà chúng ta chia nhỏ dữ liệu của một table ví dụ từ bản ghi 1 -99, từ 100- 499, từ 500-1000, hãy hình dung có những table chứa tới hàng triệu hoặc hàng tỷ bản ghi việc đánh indexes và rebuild indexes là vô cùng mất thời gian đôi khi làm cho quá trình truy xuất slow down.
Kết quả của việc chia nhỏ này sẽ được đặt vào các database thuộc các server khác nhau, sharding hiện vẫn cho kết quả truy suất tốt. Các table của Facebook/Tweeter/Microsoft… được tổ trức theo dạng này.

Tổ trức lưu trữ đã khó, mở rộng hệ thống còn khó hơn nhiều. Thông thường các hệ thống vài chục ngàn người dùng thường vẫn áp dụng Master-Master, Master-Slaves kết hợp với load balancing nơi mà Master nhận nhiệm vụ ghi dữ liệu sau đó dùng cơ chế replicate dữ liệu sang các slaves, từ các slaves sẽ đón nhận các request liên quan tới việc đọc (query) dữ liệu. Bạn có thấy ở đây phân biệt tách bạch nhiệm vụ không? Ví như một cặp vợ chồng nhưng anh chồng thì mặc quần áo đàn ông, cô vợ mặc quần áo phụ nữ tuy là cùng một nhà nhưng đôi khi vẫn có những hoạt động khác nhau như: đàn ông thì đi câu lạc bộ bia, bóng đá, offline… đàn bà thì tham gia hội văn nghệ phụ nữ, shopping… hãy hình dung anh chồng đi bia ôm mà dẫn bà vợ đi cùng thì còn làm ăn gì…xung đột là cái chắc. đâu đó thấy hình bóng của việc Read & Write ở đây đó là lý do nên tách biệt chức năng và nhiệm vụ

CQRS (Command Query Reponsibilty Segregation) ra đời nhắm tới các ý đồ như vậy, nơi mà các command (insert/update/delete) sẽ được tách riêng khỏi phần query giúp cho quá trình định hướng đến master hay salves dễ dàng hơn. Hãy hình dung 1 API của bạn được thực hiện có cả Read&Write trong đó thì việc request đó đi tới master hay salve là như nhau bởi nó sẽ đều phát sinh các xung đột của việc đọc ghi như ở bài trước mình đã đề cập.

Ở góc độ khác database như về message queuing như 
RabbitMQ, ActiveMQ, ZeroQueue thì việc quản lý các clusters cũng sẽ có controller và các followers, nơi mà các clusters sẽ join vào tạo thành một hệ thống message queuing có khả năng phân tán tới các máy vật lý khác nhau.

Với những góc nhìn khác nhau đâu đó chúng ta sẽ thấy các mô hình kiến trúc này ở khắp nơi không riêng gì database.

Hãy Like/Share/Comment/Follows Gravity Model để nhận thêm những bài viết mới nhé các bạn

Y Hoang,

#Database architecture
#Sharding
#Parttioning
#Clustering
#Replication
#CQRS
#RabbitMQ
#ActiveMQ

Please follow and like us:

Leave a Reply

Your email address will not be published. Required fields are marked *