Як допомагає розділити таблицю?

Мені важко зрозуміти плюси і мінуси розподілу таблиць. Я збираюся розпочати роботу над проектом, який мав би 8 таблиць, і одна з них буде основною таблицею даних, яка містить 180-260 мільйонів записів. Оскільки це буде правильно індексована таблиця, тому я думаю про обмеження записів таблиці до 20 мільйонів, таким чином мені доведеться створити 9-13 таблиць.

Але я не зовсім впевнений, як це покращить продуктивність, оскільки вони будуть сидіти на одній машині (32 ГБ оперативної пам’яті)?

Я використовую MySQL, і таблиці будуть MyISAM, а велика таблиця матиме індекс у полі id, і немає інших складностей, таких як пошук повного тексту тощо.

Будь ласка, пролийте світло на розділ таблиці та розділення бази даних.

Далі - це просто божевільна скачка та захоплення ...

Якщо ви залишите всі дані в одній таблиці (без розділів), у вас з'явиться O (log n) час пошуку за допомогою ключа. Візьмемо найгірший індекс у світі, двійкове дерево. Кожен вузол дерева має рівно один ключ. Ідеально збалансоване двійкове дерево з 268 455 455 (2 ^ 28 - 1) деревними вузлами було б заввишки 28. Якщо ви розділите це бінарне дерево на 16 окремих дерев, ви отримаєте 16 двійкових дерев, кожне з 16 777 215 (2 ^ 24 - 1) вузли дерев висотою 24. Шлях пошуку зменшується на 4 вузли, зменшення висоти на 14,2857%. Якщо час пошуку в мікросекундах, скорочення часу пошуку на 14,2857% є нульовим до незначного.

Зараз у реальному світі індекс BTREE матиме треноди з кількома ключами. Кожен пошук BTREE здійснював бинарний пошук всередині сторінки з можливим порядком на іншій сторінці. Наприклад, якщо кожна сторінка BTREE містила 1024 клавіші, висота дерева 3 або 4 була б нормою, дійсно коротка висота дерева.

Зауважте, що розділення таблиці не зменшує висоту BTREE, яка вже мала. Враховуючи розділення на 260 мільйонів рядів, є навіть велика ймовірність мати кілька BTREE з однаковою висотою. Пошук ключа може щоразу проходити через усі кореневі сторінки BTREE. Тільки один виконає шлях потрібного діапазону пошуку.

Тепер розгорніть це питання. Усі розділи існують на одній машині. Якщо у вас немає окремих дисків для кожного розділу, ви матимете обертання дискового вводу-виводу та шпинделя як автоматичне вузьке місце поза виконанням пошуку розділів.

У цьому випадку розділення за базою даних нічого не купує, якщо ідентифікатор є єдиним пошуковим ключем.

Розбиття даних має слугувати для групування даних, які логічно та згуртовано входять в один клас. Продуктивність пошуку кожного розділу не повинна бути головним фактором, якщо дані правильно згруповані. Коли ви досягли логічного розподілу, сконцентруйтесь на часі пошуку. Якщо ви просто розділяєте дані лише за допомогою id, можливо, багато рядків даних ніколи не можуть отримати доступ для читання чи запису. Тепер це має бути головним питанням: Знайдіть усі ідентифікатори, до яких найчастіше звертаються, і розділ за цим . Усі рідше доступні ідентифікатори, що мають доступ, повинні розміщуватися в одній великій архівній таблиці, яка все ще доступна шляхом пошуку індексу для запиту "раз у синій місяць".

Загальний вплив повинен мати, як мінімум, два розділи: Один для ідентифікаторів, які часто отримують доступ, а другий для розділення інших. Якщо ідентифікатори, які часто звертаються, досить великі, ви можете необов’язково розділити це.

200 мільйонів рядків, безумовно, в діапазоні, де ви могли б отримати вигоду від розподілу таблиці. Залежно від вашої заявки, ви можете зробити ставку на деякі переваги, перелічені нижче:

• Простота очищення старих даних Якщо вам потрібно очистити записи, які перевищують (скажімо, 6-місячні), ви можете розділити таблицю за датою, а потім замінити старі розділи. Це набагато швидше, ніж видалення даних із таблиці, і часто це можна зробити в реальній системі. У випадку з ОП це може бути корисним для обслуговування системи.

• Кілька томів диска Розділення дозволяє розділити дані для розподілу дискового трафіку по декількох томах диска за швидкістю. З сучасним контролером RAID це, швидше за все, не буде проблемою для ОП.

• Швидше сканування таблиць і діапазонів Дійсно, операційна система не повинна робити подібних дій, але сховище даних або подібні системи будуть робити такі запити в кількості. Сканування таблиць використовує в основному послідовний дисковий трафік, тому вони, як правило, є найбільш ефективним способом обробки запиту, який повертає більше ніж кілька відсотків рядків у таблиці.
  
  Розбиття за допомогою загального фільтра (зазвичай на основі часу або періоду) дозволяє виключати великі шматки таблиці з таких запитів, якщо предикат можна вирішити проти ключа розбиття. Це також дозволяє розділити таблицю на кілька томів, що може призвести до значного підвищення продуктивності для великих наборів даних. Зазвичай це не проблема для операційних систем.

Для цілей ОП, швидше за все, не вдасться досягти великої користі для оперативних запитів, але це може бути корисно для управління системою. Якщо є якась значна вимога повідомляти про агрегати за великими обсягами даних, то в цьому може допомогти відповідна схема розподілу.

Розбиття дозволяє паралельно виконувати повторне оформлення перерозподілів, якщо всі ваші індекси розділені. Якщо ні, то розділи ще набагато менші та використовують менше робочої області для reorg. І, внутрішньо, будь-яка "добра" СУБД може робити паралельно паралельні таблиці. Це, ймовірно, НЕ включає MySQL або MyISAM, тхо ....