Чому НЕ розділити?

Коли б НЕ захотів розділити базу даних? (думаючи про розділення MySQL )

У моєму випадку

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

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

ОНОВЛЕННЯ - Я вибрав відповідь zgguy, але зауважте, що я додав власну відповідь до результатів мого власного дослідження, включаючи посилання на дійсно гарну відповідь на подібне питання, яке було дуже корисним для мене.

mysql database-design partitioning

— чал
джерело

Відповіді:

Немає срібної кулі для проблем із роботою, і розділення теж не одна.

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

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

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

— zgguy
джерело

Тож пошук унікальних / первинних ключів насправді не побачить значно (якщо є?) Поліпшення, оскільки індекс PK швидше? Чи це в усьому світі - чи буває час, коли індекс PK повільніше? Що робити, якщо пошукові запити перекошені на нові додані ПК? Чи корисний би розділ, заснований на ПК (я думаю, що альго ключа розділу повинен бути модульним чи подібним, а НЕ хеш, правда?), Який спричиняє, що більшість активностей потрапляє лише на один розділ?

— чел

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

— zgguy

Вибачте, що повернувся через 10 днів, але ви підкреслили ключовий момент - Ви надали вагомі підстави вважати розділ, як можливо, не потрібним, однак мій сценарій включає в себе оновлення кожного запису після його читання (кілька за секунду). Чи є потреба в стільки записах більш переконливим випадком для розділів (з рівномірним розподілом), щоб навантаження на запис було розповсюджене?

— чел

Я також намагаюся зрозуміти ваш коментар щодо запитів, які потрапляють до багатьох розділів (які повільніше). Якщо запити відносяться до ПК, який також використовується (хеш) як ключ розділу, чи DB не одразу знає, до якого розділу перейти на основі хешу пошуку? Дякуємо за допомогу!

— чел

На жаль, останнім часом не вдалося відвідати обмін стеками. Відповідь, з якою ви пов’язали, - чудова. Я вважаю, що це відповідає на обидва ваші запитання.

— zgguy

Відповідь тут добре написана і наводить аргументи, подібні до відповіді zgguy , що розділення не купує вас багато, якщо такі є, користь для одномашинного сценарію, де найчастіші пошуки призначаються на первинному ключі або щось подібне (тому що індексований пошук повинен бути таким же швидким).

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

Я також бачив згадку, що MySQL ніколи не робить нічого паралельно (було б добре побачити деякі посилання або більше пояснень з цього приводу).

Ніхто не бачив, щоб хто-небудь говорив, додає чи ні письмовій діяльності, що викликає різні міркування.

— чал
джерело

Я не думаю, що записи змінюють ваш відповідь. Ви згадали 2 з 4 випадків використання, які я знайшов. Досі немає паралелізму, навіть у 8.0.

— Рік Джеймс

Найперше, що спадає на думку, - це обрізка перегородок ; якщо це не те, що ваші запити можуть використовувати.

Чи буде потрібно чистити велику кількість даних із таблиці, оскільки розділення допоможе вам вийти. Хоча стара, але ця публікація від Петра має кілька моментів для розгляду.

і ще одна річ, про яку можна придумати, це простота використання для простих таблиць ... Розбиття розділів потребує додаткових робіт та обслуговування.

— mysql_user
джерело

Новіші версії мають синтаксис для явного обмеження запиту до розділу. Я не можу придумати поважну причину для того, щоб коли-небудь використовувати таке.

— Рік Джеймс