Sharding
Last updated
Last updated
Sharding sẽ phân chia các database lớn thành các phần nhỏ hơn, được gọi là các shard (trong tiếng Việt “shard” có nghĩa là “mảnh vỡ”).
Các shard sẽ có schema giống nhau, mặc dù dữ liệu thực tế trên mỗi shard là duy nhất cho shard đó.
Hình vẽ dưới đây minh hoạt về một database được phân mảnh.
Dữ liệu người dùng được phân bổ cho các database server khác nhau dựa trên UserID.
Bất cứ khi nào bạn truy cập dữ liệu, một hàm băm được sử dụng để tìm shard tương ứng với user đó.
Ví dụ, chúng ta lấy UserID % 5 làm hàm băm.
Khi này, nếu kết quả UserID % 5 == 0, shard 0 được sử dụng để lưu trữ, thêm, sửa, xóa, truy vấn dữ liệu của user đó.
Tương tự như vậy, nếu UserID % 5 == 1, shard 1 sẽ được sử dụng.
…
Yếu tố quan trọng nhất cần xem xét khi thực hiện chiến lược phân vùng (sharing) là sự lựa chọn sharding key.
Sharding key (hay một số tài liệu khác còn gọi là partition key) bao gồm một hoặc nhiều cột, dùng để xác định cách phân phối dữ liệu.
Như trong ví dụ ở trên, UserID đã được chọn là sharding key.
Sharding key cho phép bạn truy xuất và sửa đổi dữ liệu một cách hiệu quả, bằng cách định tuyến các truy vấn đến chính xác database tương ứng.
Ưu điểm:
Cải thiện hiệu suất: Giảm tải công việc trên mỗi server.
Khả năng mở rộng: Dễ dàng thêm nhiều shard khi cần.
Nhược điểm:
Sharding là một kỹ thuật rất hay để scale database, nhưng nó cũng không phải là một giải pháp hoàn hảo và cần thiết cho mọi trường hợp.
Nó có thể gây ra sự phức tạp và những thách thức mới cho hệ thống:
Thách thức 1 – Resharding data:
Tức là việc tái cấu trúc lại việc phân phối dữ liệu vào các shard. Việc này thường xảy ra trong trường hợp phân phối dữ liệu không đồng đều, một số shard bị quá tải do các user trong shard này tăng trưởng dữ liệu quá nhanh.
Khi ấy, bạn sẽ cần phải update lại sharding function và phối phối dữ liệu sang các shard khác.
Một trong những kỹ thuật để xử lý việc này đó là Consistent hashing.
Thách thức 2 – Celebrity problem hay Hotspot key problem:
Lấy một ví dụ dễ hiểu liên quan đến cái tên của vấn đề này – Celebrity (tiếng Việt nghĩa là Người nổi tiếng, kiểu ngôi sao đồ đó)
Thử tưởng tượng bạn đang quản lý ứng dụng mạng xã hội, mà dữ liệu của Sếp Sơn Tùng MTP, couple Ninh Dương, anh Lý Hải, Lee Min Hô Đồng Nai, Tộc trưởng Độ Mixi xếp vào chung 1 shard xem.
Chắc hẳn sẽ rất nhanh chóng, lượng truy cập vào shard này sẽ gây ra tình trạng quá tải. Và đương nhiên các fan và antifan sẽ không thể đọc dữ liệu trên trang cá nhân của những người nổi tiếng này được nữa.
Một giải pháp để có thể giải quyết vấn đề này, đó là phân phối mỗi người nổi tiếng này vào một shard riêng.
Thách thức 3 – Join và Denormalization:
Khi một database đã được phân mảnh thành nhiều shard, sẽ rất khó để thực hiện các thao tác JOIN dữ liệu trên các shard.
Một cách giải quyết phổ biến là denormalize database. Hiểu đơn giản thì đây là cách lưu dữ liệu dư thừa vào các bảng, để các truy vấn có thể được thực hiện trong một bảng duy nhất, thay vì phải JOIN nhiều bảng với nhau.
Nhưng đương nhiên việc thực hiện denormalize database sẽ không hề dễ dàng (Nhiều bạn cứ nghĩ là đơn giản, cho đến khi dữ liệu ngày càng phát sinh lên nhiều).
Vì nó có thể gây ra sự không nhất quán giữa dữ liệu trong bảng gốc và dữ liệu được lưu dư thừa trong các bảng khác.
Ngoài ra, mỗi khi INSERT, UPDATE, DELETE dữ liệu trong bảng gốc, chúng ta lại phải cân nhắc tới việc UPDATE dữ liệu vào bảng lưu dư thừa kia.
Và đương nhiên, lưu dư thừa dữ liệu đồng nghĩa với việc bạn sẽ phải tốn nhiều dung lượng database hơn.
Một số tài liệu tham khảo về Sharding:
[Tips Javascript]()
