Tại sao KHÔNG phân vùng?

Khi nào người ta KHÔNG muốn phân vùng cơ sở dữ liệu? (suy nghĩ phân vùng MySQL )

Trong trường hợp của tôi

• Tôi sẽ bắt đầu với một vài triệu hàng, nó sẽ phát triển từ đó.
• Khóa chính trên trường ký tự đóng vai trò hạn chế truy vấn thường xuyên nhất (và tra cứu là thường xuyên - ít nhất là vài giây mỗi giây).
• Khóa chính sẽ được băm để phục vụ như là khóa phân vùng
• Các cập nhật sẽ được thực hiện cho mỗi hàng được lấy trong các truy vấn thường xuyên được đề cập ở trên
• Tra cứu ít thường xuyên hơn (so với cột ngày hoặc khác) sẽ cần phải nhấn tất cả các phân vùng

Ngay cả đối với điểm cuối cùng, không phải việc tra cứu chạy song song nên trong mọi trường hợp, đây có phải là một chiến thắng không? Nhược điểm của phân vùng là gì? Tại sao đó không phải là thứ mà MỌI NGƯỜI sử dụng theo mặc định, ít nhất là khi bạn đang xem hàng triệu bản ghi?

CẬP NHẬT - Tôi đã chọn câu trả lời của zgguy nhưng lưu ý rằng tôi đã thêm câu trả lời của riêng mình với kết quả nghiên cứu của riêng tôi bao gồm liên kết đến câu trả lời thực sự tốt cho một câu hỏi tương tự rất hữu ích với tôi.

Không có viên đạn bạc nào cho các vấn đề về hiệu năng và phân vùng cũng không phải là một.

Mỗi phân vùng về cơ bản là một bảng cho chính nó. Do đó, các truy vấn được viết theo cách cho phép cơ sở dữ liệu tìm kiếm các hàng chỉ trong một phân vùng trở nên nhanh hơn. Sự khác biệt có thể rất lớn đối với các truy vấn cần quét toàn bộ bảng lớn, nhưng có thể hạn chế chỉ quét một phân vùng trong bảng được phân đoạn. Đối với tra cứu khóa duy nhất, sự khác biệt là nhỏ hơn nhiều.

Tuy nhiên, các truy vấn sử dụng tra cứu chỉ mục theo cách yêu cầu cơ sở dữ liệu truy cập tất cả hoặc hầu hết các phân vùng bảng (chỉ mục) sẽ chạy chậm hơn đáng kể.

Thực hiện song song là một chủ đề cho chính nó. Nếu bạn chạy các lô lớn qua đêm và có toàn bộ máy để thực hiện công việc đó, thì việc song song hóa nó là một điều tốt. Tuy nhiên, trong một hệ thống OLTP nơi cơ sở dữ liệu liên tục phục vụ các truy vấn từ nhiều người dùng đồng thời, bạn không muốn một người dùng chiếm hết tài nguyên.

Câu trả lời ở đây được viết tốt và đưa ra các đối số tương tự như câu trả lời của zgguy , rằng phân vùng không mua cho bạn nhiều, nếu có, mang lại lợi ích cho một kịch bản máy đơn trong đó việc tra cứu thường xuyên nhất được đưa ra trên khóa chính hoặc tương tự (vì tra cứu được lập chỉ mục nên nhanh như vậy).

Trên thực tế, một luồng lời khuyên phổ biến dường như là lý do chính để phân vùng là tiếp tuyến và chủ yếu liên quan đến quản lý: ví dụ: tách biệt dữ liệu của bạn dựa trên ngày nếu bạn cần thường xuyên xóa các bản ghi cũ. Mặc dù đã lưu ý rằng điều này cũng có thể có lợi cho hiệu suất tra cứu của bạn nếu dữ liệu của bạn sao cho hầu hết tất cả các truy vấn sẽ chỉ đạt các bản ghi được thêm gần đây.

Tôi cũng thấy đề cập rằng MySQL không bao giờ làm bất cứ điều gì song song (sẽ rất tuyệt khi thấy một số liên kết hoặc giải thích thêm về điều đó).

Không thấy ai nói đến việc có hay không hoạt động viết thêm những cân nhắc khác nhau.

Điều đầu tiên xuất hiện trong tâm trí là cắt tỉa phân vùng ; nếu đó không phải là thứ mà truy vấn của bạn có thể sử dụng.

Bạn sẽ cần một lượng lớn dữ liệu từ bảng vì phân vùng sẽ giúp bạn ra ngoài. Mặc dù cũ nhưng bài này từ Peter có vài điểm để xem xét.

và một điều khác người ta có thể nghĩ đến là dễ sử dụng cho các bảng đơn giản ... phân vùng cần thêm công việc và bảo trì.