Cơ Sở Dữ Liệu Phân Tán Là Gì

      143

Phân chia dữ liệu (Sharding) là một giải pháp chia nhỏ một database lớn thành nhiều database nhỏ. Ta có thể phân tách từng bảng hoặc cả một database ra nhiều phần nhỏ đặt ở nhiều máy chủ (server) khác nhau.

Bạn đang xem: Cơ sở dữ liệu phân tán là gì

Điều này sẽ giúp cho hệ thống database của chúng ta đạt được các tính chất như: khả năng bảo trì (manageability), hiệu suất (performance), tính sẵn sàng (availability), và cân bằng tải (load balancing) của ứng dụng.

Giải pháp này cũng giúp giảm chi phí và khả năng mở rộng (scalability) để scale up database bằng cách dùng nhiều server nhỏ gộp lại hơn là nâng cấp một server lớn.

*

Các cách thức Sharding dữ liệu

Có 3 cách thức phân chia (Sharding) dữ liệu như sau:

Horizontal sharding: Là cách chia dữ liệu của cùng một bảng (table) ra nhiều database khác nhau. Ví dụ ta có bảng dữ liệu thông tin về người dùng, ta sẽ dựa trên location của người dùng để quyết định nó nằm ở database nào, ví dụ người dùng ở Sài Gòn thì sẽ chứ ở DB_SG, thông tin người dùng ở Biên Hòa sẽ nằm ở DB_BH hay thông tin người dùng ở Vĩnh Long sẽ nằm ở DB_VL. Giải pháp này có một vấn đề là ta phải chọn nơi dữ liệu Sharding rất cẩn thận để không gây mất cân bằng (unbalanced) giữa các database dẫn tới rất có thể có một vài Server sẽ thành điểm nóng (hot spot), ví dụ người dùng ở Sài Gòn chắc chắn là đông hơn rất nhiều lần người dùng ở Biên Hòa hay Vĩnh Long.Vertical sharing: Là cách chỉa dữ liệu dựa trên tính năng (feature) của hệ thống. Ví dụ ta thiết kế một hệ thống chia sẻ ảnh giống Instagram, ta sẽ lưu thông tin của User vào DB_Users, lưu thông tin ảnh họ up lên trên một DB khác là DB_Photos và thông tin danh sách những người họ follow ở một database thứ 3 là DB_Follow. Cách làm này rất là rõ ràng dễ để triển khai và không làm ảnh hưởng lớn đến ứng dụng, nhưng khi hệ thống lớn dần lên thì dữ liệu cũng lớn dần theo, do đó ta lại phải thực hiện sharding tiếp những database trên từng feature (bởi vì 1 DB không thể xử lý 10 tỷ bức ảnh của 140 triệu user được).Directory Based sharding: Cách này sẽ yêu cầu ta phải thiết kế một “lookup service” có tác dụng quyết định ánh xạ (mapping) dữ liệu sẽ nằm ở database nào. Mỗi khi có request ghi hoặc đọc sẽ thông qua lookup service để mapping vị trí sẽ đọc và ghi. Khi business mở rộng số lượng server có thể tăng lên mà không ảnh hưởng hay đòi hỏi ứng dụng phải thay đổi theo.
*

Những tiêu chí để phân vùng dữ liệu

Bên trên ta đã tìm hiểu và các cách thức để sharding dữ liệu, giờ ta hãy tìm kiểu sâu hơn về các tiêu chí để phân vùng dữ liệu.

Xem thêm: Mức Thuế Suất Thuế Tndn Năm 2016 Là Bao Nhiêu ??? Công Văn 2695/Tct

Phân vùng theo danh sách (list): Cách phân vùng sẽ được quyết định gán một danh sách các giá trị ngay từ đầu, từ đó mỗi lần ghi một bản ghi mới ta sẽ tìm ra giá trị của bản ghi nằm ở phân vùng nào và ghi vào đó. Ví dụ ta sẽ quyết định nhóm tất cả các người dùng ở Ai-len, Na Uy, Thụy Điển, Phần Lan và Đan Mạch và một phân vùng có tên là Nordic (Bắc Âu).Phân vùng vòng tròn (round-robin): Cách phân vùng này rất đơn giản là mỗi lần có thao tác ghi ta sẽ ghi vòng tròn quanh các phân vùng có sẵn. Cách làm này đơn giản nhưng rất khó để xác định dữ liệu nào ở đâu lấy ra khi cần.Phân vùng tổng hợp: Là cách tổng hợp các giải pháp trên thành một giải pháp mới. Ví dụ ta có thể áp dụng phân vùng theo Key/Hash và sau đó xác định được key rồi ta sẽ áp dụng tiếp phân vùng theo danh sách để chứa key sau khi hash vào một danh sách cụ thể nào đó. Consistent Hashing có thể được coi là cách phân vùng tổng hợp.

Các vấn đề khi Sharding dữ liệu

Vì việc dữ liệu sẽ bị phân tán đi nhiều Server khác nhau do vậy sẽ phát sinh một vài vấn đề khi sharding dữ liệu như sau:

Joins and De-normalization: Bởi vì việc dữ liệu ở các bảng được phân bố và trải rộng đi nhiều Database/Server khác nhau nên việc join bảng dữ liệu là điều rất khó khăn và cũng không đem lại hiệu suất bởi vì việc dữ liệu phải được queries từ nhiều máy chủ khác nhau. Để giải quyết vấn đề này ta có thể thiết kế dữ liệu dạng non-relationship Database hay còn gọi là NoSQL, giống như MongoDB hay Cassandra hai hệ NoSQL rất nổi tiếng và hỗ trợ Sharding vô cùng tốt. Tuy nhiên việc này ta phải chấp nhận rủi ro việc không nhất quán dữ liệu (inconsistency)Referential integrity: Cũng vì lý do trên về việc truy vấn chéo dữ liệu giữa các Database nằm trên các máy chủ khác nhau là bất khả thi, do vậy việc ràng buộc khóa ngoại để bảo đảm sự toàn vẹn dữ liệu cũng là một điều vô cùng khó khăn. Hầu hết RDBMS không hỗ trợ các ràng buộc khóa ngoại trên các cơ sở dữ liệu phân tán trền nhiều server. Do vậy để đạt được điều này ta phải thực hiện điều này trên mã ứng dụng (code), điều này sẽ tăng tính phức tạp của ứng dụng.Rebalancing: Trong suốt quá trình hệ thống vận hành có rất nhiều lý do ta thay đổi các chiến thuật hay cách thức Sharding dữ liệu, như business tăng trưởng yêu cầu thêm Server… Và mỗi khi như vậy ta phải tái cân bằng (rebalancing) dữ liệu trên tất cả các Server, có nghĩa là dữ liệu phải được phân phối lại trên toàn bộ server. Để làm được điều này mà không có độ trễ (downtime) là cực kỳ khó khăn. Mô hình sharding “Directory Based” có khả năng rebalancing tốt nhất nhưng lại tăng độ phức tạp của ứng dụng và tạo thêm một single point of failure (ví dụ “lookup service”).

Tóm lại với Sharding thì mô hình sharding với key/hash với Consistent Hashing hiện tại là giải pháp tối ưu nhất cho việc Rebalancing.

Consistent Hashing

Vấn đề hashing trong distributed system

Như đã nhắc đến rất nhiều lần bên trên thì Distributed Hash Table (DHT — Bảng băm phân tán) là một thành phần cơ bản trong những distributed scalable systems (hệ thống phân tán có khả năng mở rộng). Một Hash Table cần một cặp key-value, và một hàm “hash” để map key với vị trí mà value của nó được lưu trữ.

index = hash_function(key)

Giả sử ta có thiết kế một distributed caching system (Redis cache chẳng hạn). Chúng ta có “n” cache servers, thì hàm băm (hash function) để map key với vị trí của Cache server nó làm ở đâu sẽ là key % n. Nó rất đơn giản và dễ sử dụng, tuy nhiên nó có hai nhược điểm chính là:

Nó có thể không đáp ứng được việc cân bằng tải (Load Balanced), bởi vì ta không thể chắc chắn rằng việc hash và mapping như vậy những data được lưu trữ ở các server khác nhau có độ truy cập có cân bằng nhau không? Rất có thể những data ít được truy cập được tập trung vào một vài server và vài server còn lại lại chứa những data được truy cập nhiều, dẫn tới tình trang một vài server thì hoạt động hết công suất, một vài server thì lại quá nhàn rỗi ngồi chơi không