Làm thế nào để phân vùng bảng giúp?


28

Tôi đang gặp khó khăn để lấy ý tưởng về ưu và nhược điểm của phân vùng bảng. Tôi sắp bắt đầu làm việc với một dự án có 8 bảng và một trong số đó sẽ là bảng dữ liệu chính chứa 180-260 triệu bản ghi. Vì nó sẽ được lập chỉ mục đúng bảng, vì vậy tôi nghĩ đến việc giới hạn các bản ghi bảng xuống còn 20 triệu theo cách này, tôi sẽ phải tạo 9-13 bảng.

Nhưng tôi không chắc lắm về cách nó sẽ cải thiện hiệu năng vì họ sẽ ngồi trên cùng một máy (RAM 32 GB)?

Tôi đang sử dụng MySQL và các bảng sẽ là MyISAM và bảng lớn sẽ có chỉ mục trên trường id và không có sự phức tạp nào nữa như tìm kiếm toàn văn, v.v.

Xin vui lòng làm sáng tỏ phân vùng bảng so với phân vùng cơ sở dữ liệu.


Vui lòng giải thích loại tìm kiếm được lập chỉ mục sẽ được thực hiện đối với bảng khác với id. Nó sẽ gợi ý cho bạn về kiểu phân vùng sẽ được thực hiện.
RolandoMySQLDBA

Nó sẽ chỉ là id.
Rick James

'Chỉ id' vẫn không cho chúng tôi biết bất cứ điều gì. Làm thế nào các id được phân phối trong phạm vi của tất cả các id? Bạn chủ yếu truy vấn cho những cái mới hơn, nó có thực sự được phân phối không? Truy cập dữ liệu sẽ chủ yếu được đọc hoặc chủ yếu là viết? Tất cả đây là những câu hỏi quan trọng chúng tôi cần câu trả lời trước khi chúng tôi có thể giúp bạn cụ thể. Điều đó nói rằng, các câu trả lời dưới đây là những câu trả lời thực sự hữu ích :)
Walter Heck

1
Dưới đây là cảm xúc của tôi 5 năm sau khi bắt đầu chủ đề này.
Rick James

Câu trả lời:


32

Sau đây chỉ là những lời ca tụng điên rồ và cuồng nhiệt ...

Nếu bạn để tất cả dữ liệu trong một bảng (không phân vùng), bạn sẽ có thời gian tìm kiếm O (log n) bằng khóa. Hãy lấy chỉ số tồi tệ nhất trên thế giới, cây nhị phân. Mỗi nút cây có chính xác một khóa. Cây nhị phân cân bằng hoàn hảo với các nút cây 268,435,455 (2 ^ 28 - 1) sẽ có chiều cao 28. Nếu bạn tách cây nhị phân này thành 16 cây riêng biệt, bạn nhận được 16 cây nhị phân mỗi cây với 16.777.215 (2 ^ 24 - 1) các nút cây cho chiều cao 24. Đường dẫn tìm kiếm giảm 4 nút, giảm 14.2857% chiều cao. Nếu thời gian tìm kiếm tính bằng micrô giây, thì thời gian tìm kiếm giảm 14.2857% là không đáng kể.

Bây giờ trong thế giới thực, một chỉ số BTREE sẽ có các bộ ba với nhiều khóa. Mỗi tìm kiếm BTREE sẽ thực hiện tìm kiếm nhị phân trong trang với khả năng có thể vào một trang khác. Ví dụ: nếu mỗi trang BTREE chứa 1024 khóa, chiều cao cây 3 hoặc 4 sẽ là chuẩn, chiều cao cây ngắn thực sự.

Lưu ý rằng việc chia bảng không làm giảm chiều cao của BTREE vốn đã nhỏ. Với một phân vùng gồm 260 triệu hàng, thậm chí có khả năng mạnh mẽ là có nhiều BTREE có cùng chiều cao. Tìm kiếm một khóa có thể đi qua tất cả các trang BTREE gốc mỗi lần. Chỉ một người sẽ hoàn thành đường dẫn của phạm vi tìm kiếm cần thiết.

Bây giờ mở rộng về điều này. Tất cả các phân vùng tồn tại trên cùng một máy. Nếu bạn không có các đĩa riêng biệt cho mỗi phân vùng, bạn sẽ có I / O đĩa và xoay trục chính như một nút cổ chai tự động bên ngoài hiệu suất tìm kiếm phân vùng.

Trong trường hợp này, phân vùng theo cơ sở dữ liệu sẽ không mua cho bạn bất cứ thứ gì nếu id là khóa tìm kiếm duy nhất được sử dụng.

Phân vùng dữ liệu sẽ phục vụ cho nhóm dữ liệu hợp lý và gắn kết trong cùng một lớp. Hiệu suất tìm kiếm từng phân vùng không cần phải được xem xét chính miễn là dữ liệu được nhóm chính xác. Một khi bạn đã đạt được phân vùng hợp lý, sau đó tập trung vào thời gian tìm kiếm. Nếu bạn chỉ tách dữ liệu bằng id, có thể nhiều hàng dữ liệu có thể không bao giờ được truy cập để đọc hoặc ghi. Bây giờ, đó phải là một sự cân nhắc chính: Xác định vị trí tất cả các id thường xuyên truy cập và phân vùng theo đó . Tất cả các id ít được truy cập thường nằm trong một bảng lưu trữ lớn vẫn có thể truy cập được bằng cách tra cứu chỉ mục cho truy vấn 'một lần trong một mặt trăng xanh'.

Tác động tổng thể phải có ít nhất hai phân vùng: Một cho các id thường xuyên truy cập và các paritiion khác cho các id còn lại. Nếu các id thường xuyên truy cập là khá lớn, bạn có thể tùy ý phân vùng đó.


16

200 triệu hàng chắc chắn nằm trong phạm vi mà bạn có thể hưởng lợi từ việc phân vùng bảng. Tùy thuộc vào ứng dụng của bạn, bạn có thể đặt cược một số lợi ích được liệt kê bên dưới:

  • Dễ xóa dữ liệu cũ Nếu bạn cần xóa các bản ghi nhiều hơn (giả sử) 6 tháng tuổi, bạn có thể phân vùng bảng vào ngày và sau đó trao đổi các phân vùng cũ hơn. Điều này nhanh hơn nhiều so với việc xóa dữ liệu khỏi bảng và thường có thể được thực hiện trên một hệ thống trực tiếp. Trong trường hợp của OP, điều này có thể hữu ích cho việc bảo trì hệ thống.

  • Nhiều ổ đĩa Phân vùng cho phép bạn phân chia dữ liệu để phân phối lưu lượng đĩa trên nhiều ổ đĩa cho tốc độ. Với bộ điều khiển RAID hiện đại, điều này dường như không phải là vấn đề đối với OP.

  • Quét bảng và phạm vi nhanh hơn Thực sự, một hệ điều hành không nên thực hiện loại việc này, nhưng một kho dữ liệu hoặc hệ thống tương tự sẽ thực hiện loại truy vấn này với số lượng. Quét bảng sử dụng chủ yếu lưu lượng đĩa tuần tự, vì vậy chúng thường là cách hiệu quả nhất để xử lý truy vấn trả về hơn một vài phần trăm các hàng trong bảng.

    Phân vùng theo bộ lọc chung (thường dựa trên thời gian hoặc thời gian) cho phép loại bỏ các khối lớn của bảng khỏi các truy vấn đó nếu vị từ có thể được giải quyết theo khóa phân vùng. Nó cũng cho phép bảng được chia thành nhiều khối, có thể tăng hiệu suất đáng kể cho các tập dữ liệu lớn. Thông thường, đây không phải là một vấn đề cho các hệ thống hoạt động.

Đối với phân vùng mục đích của OP không có khả năng đạt được nhiều lợi ích hiệu năng cho các truy vấn hoạt động, nhưng nó có thể hữu ích cho việc quản lý hệ thống. Nếu có bất kỳ yêu cầu quan trọng nào để báo cáo tổng hợp trên một khối lượng dữ liệu lớn thì một sơ đồ phân vùng thích hợp có thể giúp ích cho điều đó.


1

Phân vùng cho phép reorgs đồng thời theo phân vùng, nếu tất cả các chỉ mục của bạn được phân vùng. Nếu không, các phân vùng vẫn nhỏ hơn nhiều và sử dụng ít không gian làm việc hơn để reorg. Và, trong nội bộ, bất kỳ DBMS "tốt" nào cũng có thể thực hiện song song với các bảng được phân đoạn. Điều đó có thể KHÔNG bao gồm MySQL hoặc MyISAM, tho ....


MySQL không xử lý song song, ngay cả khi phân vùng được tham gia. Chỉ số MySQL chỉ một phân vùng; do đó UNIQUEFOREIGN KEYkhông thực sự có sẵn trong các bảng được phân vùng. Phân vùng trên MyISAM so với InnoDB - không có sự khác biệt đối với những điều được thảo luận trong chuỗi này.
Rick James
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.