Phân vùng MySQL: Có sự đánh đổi hiệu suất giữa số lượng phân vùng và kích thước của từng phân vùng không?


10

Tôi có một bảng lớn (vài trăm triệu hàng) mà tôi muốn phân vùng hiệu quả. Câu hỏi của tôi là liệu có sự đánh đổi giữa kích thước phân vùng và số lượng phân vùng. Theo tôi hiểu, hầu hết các truy vấn trên một cột được sử dụng trong phân vùng sẽ nhanh hơn vì truy vấn sẽ (đối với hầu hết các truy vấn) chỉ phải tìm kiếm trong phân vùng áp dụng cho truy vấn. Do đó, sẽ có ý nghĩa rằng, để tối đa hóa hiệu quả, bạn nên chia một bảng lớn thành số lượng phân vùng tối đa, do đó, làm cho mỗi phân vùng càng nhỏ càng tốt. Trong trường hợp của MySQL, điều này có nghĩa là 1024 phân vùng. Nhưng có bất kỳ hạn chế hiệu suất để có một số lượng lớn các phân vùng? Là như vậy, làm thế nào để tìm thấy số lượng phân vùng tối ưu?

Lưu ý: Đã có một câu hỏi tương tự trên stackoverflow , nhưng chỉ có một câu trả lời (theo quan điểm của tôi) bỏ lỡ dấu. Vì vậy, tôi sẽ nêu câu hỏi theo cách riêng của mình ... hy vọng nó rõ ràng hơn

Câu trả lời:


6

Hãy so sánh chúng

KÍCH THƯỚC PHẦN

Nếu bạn có những điều sau đây:

  • 100 triệu hàng trong một bảng
  • Lập chỉ mục BTREE
  • Mỗi trang trong BTREE chứa 1024 phím

Các số liệu sẽ trông như thế nào?

Vì LOG (100000000) / LOG (2) = 26.575424759099, chỉ số BTREE với 1024 khóa trên mỗi treenode sẽ có chiều cao cây chỉ 3 (CEILING (LOG (100000000) / LOG (1024))). Chỉ với ba nút trang, một tìm kiếm nhị phân cho khóa cần thiết trong mỗi treenode được truy cập sẽ dẫn đến việc cắt tỉa và cách ly khoảng 30 khóa.

SỐ PHẦN

Nếu bạn có những điều sau đây:

  • 100 triệu hàng trong một bảng
  • Lập chỉ mục BTREE
  • Mỗi trang trong BTREE chứa 1024 phím
  • Bạn tạo 1024 mệnh đề

Các con số sẽ hơi khác nhau.

Mỗi phân vùng nên có khoảng 97656 hàng. Những gì các số liệu sẽ trở thành bây giờ?

Vì LOG (97656) / LOG (2) = 16.575421065795, chỉ số BTREE có 1024 khóa trên mỗi treenode sẽ có chiều cao cây chỉ bằng 2 (CEILING (LOG (97656) / LOG (1024))). Chỉ với hai nút trang, một tìm kiếm nhị phân cho khóa cần thiết trong mỗi treenode được truy cập sẽ dẫn đến việc cắt tỉa và cách ly khoảng 20 khóa.

PHẦN KẾT LUẬN

Trải ra các khóa chỉ loại bỏ một cấp độ cây nhưng về cơ bản tạo ra 1024 chỉ mục. Các truy vấn sẽ không biết sự khác biệt. Thời gian tìm kiếm có thể là danh nghĩa tốt nhất cho các phân vùng. Tuy nhiên, hãy chắc chắn rằng tất cả các dữ liệu đang hoạt động. Mặt khác, bạn có thể chỉ nhấn một vài phân vùng, trong khi các phân vùng khác có dữ liệu hiếm khi truy cập chỉ chiếm không gian và không bao giờ được truy cập thường xuyên đủ để biện minh cho việc phân vùng . Bạn có thể có các số liệu hiệu suất khác nhau để lo lắng về điều đó rõ ràng hơn (chẳng hạn như phân mảnh nội bộ trong XFS , ext3 so với ext4, v.v.) Bạn cũng cần lo lắng về việc bạn đang sử dụng công cụ lưu trữ nào vì:

  • Lập chỉ mục InnoDB sẽ rắc rối hơn một chút so với MyISAM do phải quản lý một chỉ mục được nhóm
  • InnoDB thực hiện ghi hai lần dữ liệu trong ibdata1 cũng như tệp nhật ký hiện tại (ib_logfile0 hoặc ib_logfile1)

1
Cảm ơn, RolandoMySQLDBA, điều này rất thú vị. Điều tôi hiểu từ điều này là phân vùng sẽ có ảnh hưởng tích cực nhỏ nhưng đáng kể đến tốc độ truy vấn, nhưng có thể có các tác động tiêu cực khác, chẳng hạn như phân mảnh. Tuy nhiên, điều tôi quan tâm là làm thế nào để xác định số lượng phân vùng tối ưu. Tôi có nên luôn luôn sử dụng số cho phép tối đa (ví dụ 1024) hay một số khác có thể là một sự thỏa hiệp tốt đẹp giữa các tác động tích cực và tiêu cực? Hoặc không thể phân tích loại tối ưu hóa này?
cướp

BTW, bài viết này cho thấy câu trả lời phức tạp hơn một chút: mysqlperformanceblog.com/2010/12/11/
mẹo

Câu trả lời là tốt, nhưng đó là về tìm kiếm theo khóa (hoặc trường được lập chỉ mục). Tôi không có nhiều kinh nghiệm về phân vùng, nhưng theo quan điểm của tôi về veiw, nó rất hữu ích khi bạn phải thực hiện quét toàn bộ tabel. Trong trường hợp như vậy, bạn chỉ quét một số phân vùng thay vì toàn bộ bảng.
Cherry
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.