Я чув, що продуктивність безшарових реляційних баз даних, таких як MySQL або PostgreSQL, "пробиває" понад 10 ТБ.
Я підозрюю, що такі обмеження існують, оскільки не можна було б створити "Нетецца", "Грінплмум" або "Вертика" тощо. Однак я хотів би запитати, чи є у когось тут посилання на будь-який дослідницький документ або формальні приклади, де ці межі кількісно визначені.
Відповіді:
На ваше запитання немає простої відповіді, але ось кілька речей, про які варто подумати.
По-перше, масштаб - це не єдине, про що слід турбуватися. Що ви робите зі своїми даними. Якщо у вас є 500 таблиць на 30 ТБ даних, а ви робите простий OLTP з дуже малою кількістю звітів, я не думаю, що у вас буде занадто багато проблем. Є 32TB баз даних на PostgreSQL там. Однак в той же час продуктивність дещо погіршиться, оскільки йому доведеться вдарити диск на все. Аналогічно, якщо у вас є 50 ТБ, якщо дані, але у вас загальний набір близько 100 ГБ, ви можете створити сервер з достатньою оперативною пам’яттю, щоб зберегти цю частину db в пам'яті, і ви золото.
З іншого боку, якщо ви намагаєтеся вийняти режим (найпоширеніше значення) з 1 ТБ даних, не має значення, яку систему ви використовуєте, це буде болісно з або без різкості. (Редагувати: Шардування може насправді погіршити цю проблему . )
Основні проблеми, з якими ви зіткнетеся з величезними db-кодами на MySQL та PostgreSQL, пов'язані з тим, що жоден з них не підтримує паралелізм внутрішньозапиту. Іншими словами, запит запускається як один блок одним потоком, і він не може бути розбитий на частини і запускатися окремо. Найчастіше це питання під час запуску великих аналітичних запитів над великою кількістю даних. Тут на допомогу приходять Postgres-XC і Green Plum, оскільки вони відокремлюють сховище від виконання, і це можуть зробити на рівні координатора. Зауважте, що Postgres-XC та Green Plum, по суті, використовують внутрішню різкість, але координатори застосовують всю послідовність у всьому світі.
Завдяки паралелізму запитів ви можете розбити запит, мати різні процесори / дискові канали вводу / виводу, виконувати його частини, і повідомляти про складені результати та збирати їх назад, щоб повернутись до програми. Знову ж таки, це, як правило, більше допомагає в аналітичному, а не в обробці транзакцій.
Друга річ - це те, що деякі системи, такі як Vertica або Greenplum, зберігають стовпці інформації разом. Це ускладнює використання системи з точки зору OLTP і зменшує продуктивність там, але це значно збільшує продуктивність для великих аналітичних навантажень. Отже, це конкретний компроміс.
Отже, відповідь полягає в тому, що коли ви наберетеся більше 1-2 ТБ, ви можете зіткнутися з низкою компромісів між системами та навантаженнями. Знову ж це характерно для баз даних, розміру робочих наборів і т. Д. Однак на даний момент вам дійсно доведеться працювати з системами сніжинок, тобто унікальними та підібраними до вашого навантаження.
Це, звичайно, означає, що обмеження в цілому не піддаються кількісній оцінці.
Редагувати : Зараз я працював із базою даних 9TB, яка обробляє суміш підтримки та прийняття рішень та навантажень транзакційної обробки в PostgreSQL. Найбільшою проблемою є те, що якщо у вас виникнуть питання, що стосуються великих частин набору даних, вам доведеться почекати деякий час, щоб відповісти.
Однак при уважному увазі до основ (включаючи індекси, автовакуум, як вони працюють на низькому рівні тощо) та достатньої кількості обчислювальних ресурсів, ці цілком керовані (і я вважаю, що це було б керовано добре в діапазоні 30 ТБ в Pg).
Edit2 : Як тільки ви перейдете до 100TB, але те, що працює, залежатиме від вашого набору даних. Зараз я працюю над одним, який не зміститься до цього діапазону, оскільки він спочатку досягне межі 32 ТБ на таблицю в PostgreSQL.