Phần 13 Lý thuyết Database Sharding

Phần 13 Lý thuyết Database Sharding

1./ Cách thức hoạt động

Các bảng sẽ được tách ra theo chiều dọc hoặc theo chiều ngang.

2./ Lợi ích của Sharding

Giúp mở rộng Cơ sở dữ liệu theo chiều ngang.

Giảm thiểu thời gian truy vấn do dữ liệu được truy xuất từ nhiều node.

Linh hoạt trong việc mở rộng.

Không giống như sắp xếp dữ liệu truyền thống theo chiều dọc sẽ bị giới hạn bởi CPU, RAM, HDD của node.

3./ Hạn chế của Sharding

Mặc dù việc làm sắc nét cơ sở dữ liệu có thể giúp mở rộng quy mô dễ dàng hơn và cải thiện hiệu suất, nhưng nó cũng có thể đặt ra một số hạn chế nhất định. Ở đây, chúng ta sẽ thảo luận về một số điều này và lý do tại sao chúng có thể là lý do để tránh nói rõ ràng hoàn toàn.

Khó khăn đầu tiên mà mọi người gặp phải với sharding là sự phức tạp tuyệt đối của việc triển khai đúng kiến ​​trúc cơ sở dữ liệu phân đoạn. Nếu thực hiện không chính xác, có một nguy cơ đáng kể là quá trình sharding có thể dẫn đến mất dữ liệu hoặc bảng bị hỏng.​​ Tuy nhiên, ngay cả khi được thực hiện đúng cách, sharding vẫn có thể có tác động lớn đến quy trình làm việc của nhóm bạn. Thay vì truy cập và quản lý dữ liệu của một người từ một điểm nhập duy nhất, người dùng phải quản lý dữ liệu trên nhiều vị trí phân đoạn, điều này có thể gây gián đoạn cho một số nhóm.

Một vấn đề mà người dùng đôi khi gặp phải sau khi phân chia cơ sở dữ liệu là các phân đoạn cuối cùng trở nên mất cân bằng. Ví dụ: giả sử bạn có một cơ sở dữ liệu với hai phân đoạn riêng biệt, một phân đoạn dành cho những khách hàng có họ bắt đầu bằng chữ A đến M và một phân đoạn khác dành cho những người có tên bắt đầu bằng các chữ cái từ N đến Z. Tuy nhiên, ứng dụng của bạn phục vụ rất nhiều của những người có họ bắt đầu bằng chữ G. Theo đó, phân đoạn AM dần dần tích lũy nhiều dữ liệu hơn phân đoạn NZ, khiến ứng dụng chạy chậm và ngừng hoạt động đối với một phần đáng kể người dùng của bạn. Phân đoạn A-M đã trở thành thứ được gọi là điểm phát sóng cơ sở dữ liệu. Trong trường hợp này, bất kỳ lợi ích nào của việc làm sắc nét cơ sở dữ liệu đều bị hủy bỏ bởi sự chậm chạp và sự cố. Cơ sở dữ liệu có thể sẽ cần được sửa chữa và làm cứng lại để cho phép phân phối dữ liệu đồng đều hơn.

Một nhược điểm lớn khác là một khi cơ sở dữ liệu đã bị chia nhỏ, có thể rất khó để đưa cơ sở dữ liệu đó trở lại kiến ​​trúc không cứng của nó. Bất kỳ bản sao lưu nào của cơ sở dữ liệu được thực hiện trước khi nó bị chia nhỏ sẽ không bao gồm dữ liệu được ghi kể từ khi phân vùng. Do đó, việc xây dựng lại kiến ​​trúc không cứng ban đầu sẽ yêu cầu hợp nhất dữ liệu được phân vùng mới với các bản sao lưu cũ hoặc cách khác, chuyển đổi DB được phân vùng trở lại thành một DB duy nhất, cả hai đều sẽ tốn kém và mất thời gian. Một bất lợi cuối cùng cần xem xét là sharding không được hỗ trợ bởi mọi công cụ cơ sở dữ liệu. Ví dụ: PostgreSQL không​​ hỗ trợ Sharding

4./ Kiến trúc của Sharding

4.1/ Key Based Sharding

Hàm băm sẽ dựa theo từ khoá ID như Mã số sinh viên, IP, mã ZIP… để băm xuất ra các giá trị rời rạc​​ 

Để đảm bảo toàn vẹn dữ liệu các dữ liệu được nhập vào hàm băm phải chung 1 cột. các Shard key không thay đổi​​ 

Mặc dù sharding dựa trên khóa là một kiến ​​trúc sharding khá phổ biến, nhưng nó có thể khiến mọi thứ trở nên phức tạp khi cố gắng thêm hoặc xóa động các máy chủ bổ sung vào cơ sở dữ liệu. Khi bạn thêm máy chủ, mỗi máy chủ sẽ cần một giá trị băm tương ứng và nhiều mục nhập hiện có của bạn, nếu không phải tất cả, sẽ cần được ánh xạ lại thành giá trị băm mới, chính xác của chúng và sau đó được chuyển sang máy chủ thích hợp. Khi bạn bắt đầu cân bằng lại dữ liệu, cả hàm băm mới và cũ sẽ không hợp lệ. Do đó, máy chủ của bạn sẽ không thể ghi bất kỳ dữ liệu mới nào trong quá trình di chuyển và ứng dụng của bạn có thể bị ngừng hoạt động.

Điểm hấp dẫn chính của chiến lược này là nó có thể được sử dụng để phân phối dữ liệu một cách đồng đều nhằm ngăn chặn các​​ Hotspot. Ngoài ra, bởi vì nó phân phối dữ liệu theo thuật toán, không cần phải duy trì bản đồ về vị trí của tất cả dữ liệu, cũng như cần thiết với các chiến lược khác như phân bổ theo phạm vi hoặc dựa trên thư mục.

4.2/ Range Based Sharding

Sharding dựa trên phạm vi liên quan đến việc phân bổ dữ liệu dựa trên các phạm vi của một giá trị nhất định.​​ Để minh họa, giả sử bạn có cơ sở dữ liệu lưu trữ thông tin về tất cả các sản phẩm trong danh mục của nhà bán lẻ.​​ Bạn có thể tạo một vài phân đoạn khác nhau và chia nhỏ thông tin của từng sản phẩm dựa trên phạm vi giá của chúng, như sau:

Lợi ích chính của phân bổ theo phạm vi là nó tương đối đơn giản để triển khai.​​ Mỗi phân đoạn chứa một tập hợp dữ liệu khác nhau nhưng tất cả chúng đều có một lược đồ giống hệt nhau, cũng như cơ sở dữ liệu ban đầu.​​ Mã ứng dụng chỉ đọc dữ liệu thuộc phạm vi nào và ghi dữ liệu đó vào phân đoạn tương ứng. Mặt khác, phân bổ theo phạm vi không bảo vệ dữ liệu khỏi bị phân phối không đồng đều, dẫn đến các điểm nóng cơ sở dữ liệu nói trên.​​ Nhìn vào sơ đồ ví dụ, ngay cả khi mỗi phân đoạn chứa một lượng dữ liệu bằng nhau, tỷ lệ cược là các sản phẩm cụ thể sẽ nhận được nhiều sự chú ý hơn các sản phẩm khác.​​ Đến lượt mình, các đoạn tương ứng của chúng sẽ nhận được số lần đọc không tương xứng.

4.3/ Directory Based Sharding

Từ Shard Key sẽ tạo thêm 1 bảng có chứa Shard Key và Shard ID

Mô hình này khá linh hoạt khi dữ liệu được chia ra và phần bổ giữa các node, việc thêm và giảm node không ảnh hưởng đến tốc độ truy xuất dữ liệu.

Tuy nhiên bất lợi của mô hình là phải chia rất nhiều key do đó tốc độ cũng sẽ bị chậm hơn.

5./ Có nên sử dụng Sharding?

Việc lựa chọn hay không tuỳ thuộc vào quy mô, tốc độ phát triển của cơ sở dữ liệu. Do sử dụng Sharding sẽ làm mức độ phức tạp tăng thêm. Do đó thường chỉ sử dụng ở những DB rất lớn.

• Khi số lượng đọc / ghi vượt quá giới hạn của node.

• Khi dữ liệu quá lớn.

• Khi băng thông của 1 node không tải được.

Trước khi Sharding bạn có thể cân nhắc giải pháp sau:

• Nếu cơ sở dữ liệu ở xa có thể đặt gần với app hoặc cài chung cùng server để giảm độ trễ.

• Thêm bộ nhớ đệm, cache trên RAM nếu có thể

• Thêm node Replicate để cải thiện đọc từ nhiều node

• Hoặc đơn giản hơn là nâng cấp phần cứng của node.

Khi không còn lựa chọn nào khác thì chuyển qua Sharding

6./ Kết luận

Sharding có thể là một giải pháp tuyệt vời cho những người muốn mở rộng cơ sở dữ liệu của họ theo chiều ngang.​​ Tuy nhiên, nó cũng làm tăng thêm độ phức tạp và tạo ra nhiều điểm hỏng hóc tiềm ẩn cho ứng dụng của bạn.​​ Sharding có thể cần thiết đối với một số người, nhưng thời gian và nguồn lực cần thiết để tạo và duy trì một kiến trúc phân đoạn có thể mang lại nhiều lợi ích hơn cho những người khác. Bằng cách đọc bài viết khái niệm này, bạn sẽ hiểu rõ hơn về những ưu và nhược điểm của sharding.​​ Trong tương lai, bạn có thể sử dụng thông tin chi tiết này để đưa ra quyết định sáng suốt hơn về việc kiến trúc cơ sở dữ liệu phân đoạn có phù hợp với ứng dụng của bạn hay không.

https://www.digitalocean.com/community/tutorials/understanding-database-sharding