chiến lược sharding cơ sở dữ liệu

Question

Đối với sản phẩm thị trường trực tuyến đang được xây dựng, tôi có tình huống yêu cầu triển khai giải pháp giải mã cơ sở dữ liệu. Tôi mới để sharding và sau khi đọc các bài viết trong diễn đàn này tôi cảm thấy một thư mục dựa trên chiến lược sharding sử dụng các thực thể kinh doanh sẽ được phù hợp. Nhưng tôi vẫn chưa rõ ràng về việc chuẩn hóa và thực hiện tốt nhất việc đồng bộ hóa dữ liệu để áp dụng với một giải pháp đã được giải quyết như vậy. Sẽ có 3 thực thể cốt lõi, nhà cung cấp, khách hàng và đặt hàng. Tôi đang lập kế hoạch để phân phát cơ sở dữ liệu dựa trên id nhà cung cấp vì hầu hết quá trình xử lý dữ liệu đơn hàng sẽ được thực hiện bởi các quản trị viên của nhà cung cấp. Điều này sẽ đảm bảo rằng các đơn đặt hàng cho một nhà cung cấp được lấy từ một cá thể db duy nhất loại bỏ các lần nạp chéo db. Tuy nhiên, trong trường hợp này, khi khách hàng xem thông tin đơn đặt hàng của họ, dữ liệu sẽ nằm trong nhiều phiên bản db và sẽ yêu cầu tìm nạp nhiều cơ sở dữ liệu. Những gì thường được thực hiện khi các kịch bản như vậy xuất hiện trong một giải pháp được phân giải.

Answer 1

Tôi nghĩ rằng có 99,9% khả năng bạn không cần sharding.

Bạn cần sharding nếu:

• cơ sở dữ liệu chèn của bạn/tốc độ cập nhật gần, hoặc là vượt, công suất của máy chủ đặc tả cao nhất mà bạn có thể chi phí-hiệu quả mua VÀ
• Bạn đã nuôi ra hầu hết các truy vấn của bạn đọc, báo cáo, sao lưu vv nô lệ vào read-only nhân rộng
• bạn đã thực hiện phân vùng chức năng để di chuyển bất kỳ khối lượng công việc update-nặng không cần thiết hoặc không liên quan ra khỏi máy chủ tổng thể của bạn

Nếu bạn không thể chắc chắn nói "có" cho cả ba điều trên, bạn không cần phải phân mảnh.

đọc

http://www.mysqlperformanceblog.com/2009/08/06/why-you-dont-want-to-shard/

Answer 2

Cơ sở dữ liệu sharding có thể cực kỳ hiệu quả, thậm chí trước khi cơ sở dữ liệu của bạn được có nhiều TBS trong kích thước. Lý do chính mà chúng tôi đã tìm thấy là vì tỷ lệ bộ nhớ/CPU thành đĩa thay đổi rõ rệt và các sản phẩm DBMS như MySQL thực sự xuất sắc khi đưa các chỉ mục và dữ liệu được sử dụng gần đây nhất vào bộ nhớ.

Để khắc phục sự cố dữ liệu của bạn, kỹ thuật này có thể hữu ích.

• Truy vấn song song (chúng tôi gọi đó là truy vấn "Truy vấn cá"). Với ý tưởng này, bạn có thể truy vấn các đơn đặt hàng của khách hàng từ nhiều phân đoạn cùng một lúc và củng cố kết quả. Nếu nó thực hiện quyền này có thể rất hiệu quả.

Đối với dữ liệu không thay đổi nhiều, chúng tôi thường khuyên bạn nên sao chép bảng toàn cục cho bảng tra cứu chung, nhưng điều đó sẽ không giúp ích nhiều cho hoạt động của khách hàng.

Trong mọi trường hợp, có thể thực hiện sharding theo cách rất hiệu quả, và có thể mở rộng tuyến tính để viết và thường tốt hơn tuyến tính cho lần đọc dựa trên ở trên.

Answer 3

Bạn cũng có thể muốn thử ra DBS NoSQL như MongoDB hay Cassandra

Bạn cũng có thể sử dụng memcache để cache dữ liệu cho nhanh chóng truy cập

Bạn cũng có thể nhìn vào chủ nô lệ sao chép với nhiều nô lệ.