Phân phân tách dữ liệu (Sharding) là 1 trong những phương án phân chia bé dại một database phệ thành những database nhỏ. Ta có thể phân bóc tách từng bảng hoặc cả một database ra đa số nhỏ tuổi đặt tại những sever (server) khác biệt.
Bạn đang xem: Cơ sở dữ liệu phân tán là gì
Vấn đề này để giúp đỡ mang đến khối hệ thống database của họ có được các đặc điểm như: khả năng gia hạn (manageability), công suất (performance), tính sẵn sàng chuẩn bị (availability), và cân đối sở hữu (load balancing) của áp dụng.
Giải pháp này cũng giúp sút chi phí và kỹ năng mở rộng (scalability) để scale up database bằng phương pháp sử dụng nhiều VPS bé dại gộp lại rộng là upgrade một server lớn.
Các phương pháp Sharding dữ liệu
Có 3 cách thức phân chia (Sharding) dữ liệu như sau:
Horizontal sharding: Là cách phân chia tài liệu của và một bảng (table) ra các database khác biệt. ví dụ như ta có bảng dữ liệu lên tiếng về người dùng, ta đã dựa vào location của fan dùng để ra quyết định nó nằm ở database nào, ví dụ người tiêu dùng làm việc TPhường.Sài Gòn thì sẽ chứ đọng nghỉ ngơi DB_SG, biết tin người dùng ở Biên Hòa sẽ nằm tại DB_BH tốt thông tin người tiêu dùng ngơi nghỉ Vĩnh Long đang nằm ở vị trí DB_VL. Giải pháp này có một vụ việc là ta buộc phải chọn nơi dữ liệu Sharding hết sức cẩn thận nhằm không khiến mất thăng bằng (unbalanced) giữa các database dẫn tới rất hoàn toàn có thể gồm một vài Server đang thành điểm trung tâm (hot spot), ví dụ người dùng làm việc Sài Gòn chắc chắn là đông hơn rất nhiều lần người dùng nghỉ ngơi Biên Hòa giỏi Vĩnh Long.Vertical sharing: Là bí quyết chỉa tài liệu dựa trên nhân tài (feature) của hệ thống. Ví dụ ta thiết kế một hệ thống chia sẻ ảnh tương đương Instagram, ta sẽ giữ báo cáo của User vào DB_Users, lưu công bố hình họa họ up lên trên mặt một DB khác là DB_Photos với thông tin danh sách những người dân chúng ta follow tại một database sản phẩm 3 là DB_Follow. Cách làm này cực kỳ rõ ràng dễ dàng để thực hiện và ko có tác dụng ảnh hưởng Khủng mang lại ứng dụng, nhưng Khi khối hệ thống béo dần dần lên thì dữ liệu cũng béo dần theo, cho nên vì thế ta lại phải tiến hành sharding tiếp phần lớn database bên trên từng feature (chính vì 1 DB tất yêu cách xử trí 10 tỷ bức ảnh của 140 triệu user được).Directory Based sharding: Cách này đã yên cầu ta bắt buộc xây cất một “lookup service” tất cả tính năng đưa ra quyết định ánh xạ (mapping) tài liệu vẫn nằm tại vị trí database như thế nào. Mỗi Khi có request ghi hoặc gọi sẽ trải qua lookup service nhằm mapping vị trí đã gọi cùng ghi. lúc business mở rộng con số VPS rất có thể tạo thêm nhưng mà không ảnh hưởng giỏi đòi hỏi vận dụng yêu cầu biến hóa theo.
Những tiêu chí nhằm phân vùng dữ liệu
Bên trên ta đang mày mò với các cách thức nhằm sharding tài liệu, tiếng ta hãy search thứ hạng sâu rộng về những tiêu chuẩn nhằm phân vùng dữ liệu.
Phân vùng theo danh sách (list): Cách phân vùng sẽ được ra quyết định gán một danh sách các quý giá tức thì từ trên đầu, tự kia các lần ghi một phiên bản ghi mới ta vẫn tìm ra cực hiếm của phiên bản ghi nằm ở vị trí phân vùng như thế nào với ghi vào đó. lấy ví dụ như ta sẽ ra quyết định team toàn bộ những người dùng nghỉ ngơi Ai-len, Na Uy, Thụy Điển, Phần Lan với Đan Mạch với 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 khôn cùng đơn giản và dễ dàng là mỗi lần có thao tác làm việc ghi ta đã ghi vòng tròn quanh những phân vùng tất cả sẵn. Cách chế biến này đơn giản mà lại rất cực nhọc để xác định tài liệu như thế nào ở đâu mang ra Khi đề xuất.Phân vùng tổng hợp: Là phương pháp tổng vừa lòng những giải pháp trên thành một giải pháp new. lấy ví dụ ta rất có thể áp dụng phân vùng theo Key/Hash và sau đó xác minh được key rồi ta vẫn áp dụng tiếp phân vùng theo danh sách để chứa key sau thời điểm hash vào một danh sách cụ thể như thế nào đó. Consistent Hashing có thể được xem là cách phân vùng tổng đúng theo.Các sự việc Lúc Sharding dữ liệu
Vì vấn đề dữ liệu sẽ bị phân tán đi những Server không giống nhau do vậy đang tạo nên một vài ba vấn đề Khi sharding dữ liệu như sau:
Joins và De-normalization: Bởi vị Việc tài liệu ở những bảng được phân bổ cùng trải rộng đi các Database/Server khác biệt cho nên việc join bảng tài liệu là điều cực kỳ khó khăn cùng cũng ko mang đến hiệu suất chính vì Việc dữ liệu đề nghị được queries từ nhiều sever khác biệt. Để giải quyết vụ việc này ta có thể thiết kế tài liệu dạng non-relationship Database xuất xắc còn được gọi là NoSQL, hệt như MongoDB xuất xắc Cassandra hai hệ NoSQL siêu nổi tiếng với hỗ trợ Sharding cực kỳ tốt. Tuy nhiên vấn đề này ta phải gật đầu đồng ý khủng hoảng rủi ro việc không đồng bộ dữ liệu (inconsistency)Referential integrity: Cũng bởi nguyên do bên trên về vấn đề truy tìm vấn chéo cánh tài liệu thân những Database nằm trong các sever không giống nhau là bất khả thi, thế nên câu hỏi buộc ràng khóa nước ngoài để bảo vệ sự trọn vẹn dữ liệu cũng là một điều cực kỳ khó khăn. Hầu không còn RDBMS ko cung ứng những ràng buộc khóa nước ngoài bên trên những cơ sở tài liệu phân tán trền những hệ thống. Do vậy để đạt được điều đó ta cần triển khai vấn đề này bên trên mã áp dụng (code), điều này sẽ tăng tính phức hợp của ứng dụng.Rebalancing: Trong xuyên suốt quá trình hệ thống quản lý và vận hành có tương đối nhiều nguyên do ta chuyển đổi những phương án giỏi phương pháp Sharding dữ liệu, như business vững mạnh đòi hỏi thêm Server… Và mọi khi những điều đó ta đề nghị tái cân đối (rebalancing) dữ liệu trên tất cả các Server, tức là dữ liệu đề nghị được phân pân hận lại trên toàn cục VPS. Để có tác dụng được điều đó nhưng mà không tồn tại độ trễ (downtime) là rất là khó khăn. Mô hình sharding “Directory Based” có khả năng rebalancing cực tốt tuy thế lại tăng cường mức độ phức tạp của áp dụng với tạo nên thêm 1 single point of failure (ví dụ “lookup service”).Tóm lại cùng với Sharding thì quy mô sharding cùng với key/hash với Consistent Hashing ngày nay là giải pháp tối ưu nhất cho câu hỏi Rebalancing.
Consistent Hashing
Vấn đề hashing vào distributed system
Nlỗi vẫn nói đến không ít lần trên thì Distributed Hash Table (DHT — Bảng băm phân tán) là 1 trong nguyên tố cơ bản trong số những distributed scalable systems (khối hệ thống phân tán có tác dụng msinh hoạt rộng). Một Hash Table cần một cặp key-value, cùng một hàm “hash” để map key với vị trí nhưng value của chính nó được tàng trữ.
index = hash_function(key)Giả sử ta được thiết kế theo phong cách một distributed caching system (Redis cađậy chẳng hạn). Chúng ta tất cả “n” cache servers, thì hàm băm (hash function) nhằm bản đồ key với vị trí của Cabịt VPS nó làm cho ở đâu đã là key % n. Nó khôn cùng dễ dàng và đơn giản và dễ sử dụng, tuy vậy nó bao gồm hai nhược điểm bao gồm là:
Nó rất có thể không đáp ứng nhu cầu được việc cân đối tải (Load Balanced), cũng chính vì ta tất yêu chắc chắn rằng câu hỏi hash với mapping như thế đầy đủ data được tàng trữ nghỉ ngơi những server không giống nhau gồm độ truy cập có cân bằng nhau không? Rất có thể đông đảo data ít được truy vấn được tập trung vào một trong những vài VPS và vài ba server sót lại lại đựng phần nhiều data được truy cập các, mang tới tình trang một vài ba hệ thống thì hoạt động hết năng suất, một vài ba VPS thì lại vượt thanh nhàn ngồi chơi không
