Один з великих плюсів для nosql СУБД - це те, що вони можуть кластеризуватися легше. Нібито за допомогою NoSQL ви можете створити сотні дешевих машин, які зберігають різні фрагменти даних і запитують їх все одночасно.

Моє запитання таке, чому реляційні СУБД не можуть зробити це на зразок mysql або sql-сервера? Хіба що продавці просто не знайшли технічного способу зробити це з наявним продуктом, чи є проблема з реляційною моделлю, яка не дозволяє це зробити неможливим? Що так чудового в способі зберігання та доступу до даних (ключ / значення, документи тощо) NoSQL, що полегшує кластеризацію, якщо це взагалі так?

Системи розподілених баз даних 101

Або розподілені бази даних - що ФК означає " веб-шкала " насправді?

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

По-перше, деяка термінологія

Властивості кислотних кислот (атомність, консистенція, ізоляція та довговічність): це ключові інваріанти, які повинні бути примусові для надійної реалізації транзакції, не викликаючи небажаних побічних ефектів.

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

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

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

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

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

Спільна архітектура диска: архітектура, в якій усі вузли обробки кластеру мають доступ до всіх сховищ. Це може стати центральним вузьким місцем для доступу до даних. Прикладом системи спільного диска є Oracle RAC або Exadata .

Спільна архітектура нічого: архітектура, в якій вузли обробки в кластері мають локальне сховище, яке не видно для інших вузлів кластера. Прикладами систем загального користування є Teradata і Netezza .

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

Синхронізація: загальний термін, що описує різні методи забезпечення послідовного доступу до спільного ресурсу за допомогою декількох процесів або потоків. Це набагато важче зробити на розподілених системах, ніж на системах спільної пам'яті, хоча деякі мережеві архітектури (наприклад, BYNET Teradata) мали примітивні синхронізації в мережевому протоколі. Синхронізація також може мати значну кількість накладних витрат.

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

Побічна узгодженість: Термін, що використовується для опису семантики транзакцій, що торгує негайним оновленням (узгодженість зчитуванням) на всіх вузлах розподіленої системи для продуктивності (а отже, і більшої пропускної здатності транзакцій) у записі. Побічна послідовність є побічним ефектом використання Quorum Replication як оптимізації продуктивності для прискорення транзакцій, що здійснюються в розподілених базах даних, де декілька копій даних зберігаються в окремих вузлах.

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

Двухфазна комісія (2PC): сімейство протоколів, які забезпечують оновлення бази даних, що включає декілька фізичних систем, послідовно фіксують або повертаються назад. Незалежно від того, чи використовується 2PC в системі або в декількох системах через менеджер транзакцій, це несе значні витрати.

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

Багатоверсійний контроль за сумісністю (MVCC): управління суперечкою, записуючи нові версії даних в інше місце та дозволяючи іншим транзакціям бачити стару версію даних, поки нова версія не буде скоєна. Це зменшує конфіденційність бази даних за рахунок деякого додаткового трафіку запису, щоб написати нову версію, а потім позначити стару версію як застарілу.

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

Горизонтальний розподіл: Таблиця може бути розділена на кілька вузлів або об'ємів зберігання за допомогою її ключа. Це дозволяє розділити великий об'єм даних на менші шматки та розподілити по вузлах зберігання даних.

Шардування: Набір даних може бути горизонтально розділений на декілька фізичних вузлів в архітектурі, що ділиться нічим. Якщо цей розділ не прозорий (тобто клієнт повинен знати про схему розділів і розробити, який вузол явно запитувати), це відомо як шардінг. Деякі системи (наприклад, Teradata) роблять розділені дані по вузлах, але місце розташування є прозорим для клієнта; термін, як правило, не використовується в поєднанні з цим типом системи.

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

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

Неблокуючий комутатор: мережевий комутатор, який використовує внутрішній апаратний паралелізм для досягнення пропускної здатності, пропорційної кількості портів без внутрішніх вузьких місць. Наївна реалізація може використовувати механізм поперечки, але це має складність O (N ^ 2) для N портів, обмежуючи їх меншими комутаторами. Більші комутатори можуть використовувати більш складну внутрішню топологію, яка називається не блокуючим мінімальним перемикачем, щоб досягти лінійного масштабування пропускної здатності без необхідності обладнання O (N ^ 2).

Створення розподілених СУБД - наскільки важко це може бути?

Кілька технічних проблем ускладнюють це на практиці. Крім додаткової складності побудови розподіленої системи, архітектору розподіленої СУБД доводиться долати деякі складні інженерні проблеми.

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

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

Затримка примусового виконання обмежень (тобто чекання, поки зобов’язання підтвердити DRI) вимагає, щоб блокування було збережено протягом тривалості транзакції. Цей вид розподіленого блокування має значні накладні витрати.

Якщо зберігається декілька копій даних (це може знадобитися в системах, що не мають спільного доступу, щоб уникнути непотрібного мережевого трафіку від напівз'єднання), то всі копії даних повинні бути оновлені.

Ізоляція в розподілених системах: Якщо дані, що впливають на транзакцію, знаходяться на кількох системних вузлах, блокування та версія (якщо MVCC використовується) повинні бути синхронізовані через вузли. Гарантування послідовності операцій, особливо в архітектурах, що розділяються нічим, де можуть зберігатися зайві копії даних, вимагає розподіленого механізму синхронізації, такого як Алгоритм Лампорта, який також має значні накладні витрати в мережевому трафіку.

Довговічність в розподілених системах: У спільній дисковій системі проблема довговічності по суті є такою ж, як у системі спільної пам’яті, за винятком того, що протоколи розподіленої синхронізації все ще потрібні по вузлах. СУБД повинна вести журнал запису в журнал і послідовно виписувати дані. У системі загального користування може бути декілька копій даних або частин даних, що зберігаються в різних вузлах. Двофазний протокол фіксації необхідний, щоб переконатися, що фіксація відбувається правильно через вузли. Це також спричиняє значні накладні витрати.

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

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

Зауважте, що "можлива узгодженість" є основною компромісною консистенцією, яка може бути неприйнятною, якщо дані повинні переглядатися послідовно, як тільки транзакція буде здійснена. Наприклад, у фінансовій заяві оновлений баланс повинен бути доступний негайно.

Системи спільного користування дисками

Система спільного диска - це система, де всі вузли мають доступ до всіх сховищ. Таким чином, обчислення не залежать від місця розташування. Багато платформи СУБД також можуть працювати в цьому режимі - Oracle RAC є прикладом такої архітектури.

Спільні дискові системи можуть значно змінювати масштаби, оскільки вони можуть підтримувати зв'язок M: M між вузлами зберігання та вузлами обробки. SAN може мати декілька контролерів, а кілька серверів можуть запускати базу даних. Ці архітектури мають перемикач як центральне вузьке місце, але перехресні перемикачі дозволяють цьому комутатору мати велику пропускну здатність. Деяка обробка може бути завантажена на вузли зберігання (як у випадку з Exadata Oracle), що може зменшити трафік на пропускну здатність накопичувача.

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

Системи загального користування

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

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

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

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

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

Шардінг, тиражування кворуму та подія послідовності

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

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

Це означає, що зчитування вузлів поза кворумом може бачити застарілі версії даних до тих пір, поки фоновий процес не закінчить запис даних до решти вузлів. Семантика відома як "Подія консистенції" і може бути або неприйнятною залежно від вимог вашої програми, але означає, що комісійні транзакції у використанні ресурсів ближче до O (1), ніж O (n).

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

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

Наприклад, BigTable від Google не реалізує реплікацію кворуму самостійно, хоча вона сидить на GFS, кластерній файловій системі, яка використовує реплікацію кворуму. BigTable (або будь-яка система загального користування) може використовувати надійну систему зберігання з декількома контролерами та розподіляти дані серед контролерів. Тоді паралельний доступ буде досягнутий шляхом розподілу даних.

Повернутися до платформ RDBMS

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

Системи спільного диска та загального користування можуть не змінювати масштабну роботу. Наприклад, Oracle RAC може підтримувати 63 вузли обробки (які самі по собі можуть бути великими SMP-машинами) та довільну кількість контролерів зберігання даних в SAN. IBM Sysplex (кластер мейнфреймів zSeries) може підтримувати декілька мейнфреймів (кожна зі значною потужністю обробки та власною пропускною здатністю вводу / виводу) та декілька контролерів SAN. Ці архітектури можуть підтримувати дуже великі обсяги транзакцій із семантикою ACID, хоча вони передбачають надійне зберігання. Teradata, Netezza та інші виробники роблять високоефективні аналітичні платформи на основі спільних проектів, які масштабуються до надзвичайно великих обсягів даних.

Поки на ринку дешевих, але надмірно об'ємних повністю ACID RDBMS платформ переважає MySQL, який підтримує шардинг та мультимайстерну реплікацію. MySQL не використовує реплікацію кворуму для оптимізації пропускної здатності запису, тому транзакції виконуються дорожче, ніж у системі NoSQL. Шардінг дозволяє дуже високу пропускну здатність (наприклад, Facebook широко використовує MySQL), тому цей тип архітектури добре масштабується на важких робочих навантаженнях для читання.

Цікава дискусія

BigTable - це архітектура спільного використання (по суті, пара розподілених ключів і значень), як вказав Майкл Хаузенблас нижче . Моя оригінальна оцінка цього проекту включала двигун MapReduce, який не є частиною BigTable, але зазвичай використовується разом із ним у найбільш поширених його реалізаціях (наприклад, Hadoop / HBase та Google MapReduce).

Порівнюючи цю архітектуру з Teradata, яка має фізичну спорідненість між зберіганням та обробкою (тобто вузли мають локальне сховище, а не спільний SAN), можна стверджувати, що BigTable / MapReduce - це спільна архітектура диска через глобально видиму паралельну систему зберігання.

Пропускна здатність системи стилю MapReduce, такої як Hadoop, обмежується пропускною здатністю мережевого комутатора, що не блокує. ¹ Неблокуючі комутатори, однак, можуть працювати з агрегатами великої пропускної здатності через паралелізм, притаманний конструкції, тому вони рідко є значним практичним обмеженням у роботі. Це означає, що архітектура спільного диска (можливо, краще називається системою спільного зберігання) може масштабуватися до великих навантажень, навіть якщо мережевий комутатор теоретично є центральним вузьким місцем.

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

¹ Звичайно, доступна обробка та пропускна здатність вводу / виводу також є обмеженням продуктивності, але мережевий комутатор є центральною точкою, через яку проходить весь трафік.

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

Наприклад, в основному навантаження OLTP може мати додаткову затримку в одному запиті, навіть якщо пропускна здатність кластера добре масштабується. Ця додаткова затримка може залишитись непоміченою або стати справжньою довірою, залежно від програми. Загалом, кластеризація покращить пропускну здатність і зашкодить затримки, але навіть це правило є підозрілим, якщо запити програми особливо піддаються паралельній обробці.

Що компанія, над якою я працюю, Clustrix , пропонує це ряд однорідних вузлів обчислення та зберігання, з'єднаних відносно швидкісною мережею. Реляційні дані є хеш-розподілом по вузлах на основі індексу в шматках, які ми називаємо "фрагментами". Кожен зріз матиме дві чи більше реплік, розповсюджених по всьому кластеру, для довговічності у разі відмови вузла чи диска. Клієнти можуть підключитися до будь-якого вузла кластеру для видачі запитів за допомогою дротового протоколу MySQL.

Дуже неприродно думати про компоненти бази даних ACID самостійно, оскільки стільки з них узгоджується разом, але ось що:

Атомарність - Clustrix використовує дві фази фіксацій , щоб забезпечити атомарность. Операції UPDATE та DELETE також заблокують рядки через наш диспетчер розподілених блокувань, оскільки ми внутрішньо перетворюємо ці операції в SELECT, а потім - точні UPDATE / DELETE.

Атомність очевидно збільшує кількість повідомлень між вузлами, що беруть участь в транзакції, і збільшує навантаження на ці вузли для обробки протоколу фіксації. Це частина накладних витрат на наявність розподіленої системи і обмежуватиме масштабованість, якщо кожен вузол брав участь у кожній транзакції, але вузли беруть участь лише в транзакції, якщо у них є одна із записаних реплік.

Послідовність - Зовнішні ключі реалізуються як тригери, які оцінюються під час фіксації. Великий діапазон операцій UPDATE та DELETE може зашкодити нашій роботі через блокування, але ми, на щастя, не бачимо цього все так часто. Набагато частіше бачити оновлення / видалення транзакцій у декількох рядках, а потім здійснювати фіксацію.

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

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

Довговічність - кожен фрагмент реляційних даних зберігається у двох або більше вузлах, щоб забезпечити стійкість у разі відмови вузла чи диска. Тут, мабуть, також варто відзначити, що версія пристрою нашого продукту має карту NVRAM, де WAL зберігається з міркувань продуктивності. Багато баз даних одного примірника покращать продуктивність своїх WAL, контролюючи точки з інтервалами, а не на кожному коміті. Такий підхід є проблематичним у розподіленій системі, оскільки змушує "переграти куди?" складне питання. Ми робимо це в цьому приладі, надаючи гарантію міцності.

Фундаментальна відповідь полягає в тому, що модель узгодженості інша. Я пишу це, щоб розширити відповідь ConcernedOfTunbridge, яка справді повинна бути орієнтиром для цього.

Основним моментом моделі послідовності ACID є те, що вона дає купу фундаментальних гарантій стану даних у глобальному масштабі в системі. Ці гарантії поширюються на обмеження теореми CAP, які в основному означають, що для того, щоб вони працювали, вам потрібно мати усі авторитетні джерела на одній сторінці, перш ніж повідомити заяві, що ви здійснили транзакцію. Таким чином, багаторежимну реплікацію дуже важко зробити, не стикаючись з цими обмеженнями. Звичайно, щойно ви почнете робити асинхронну реплікацію в середовищі мультимайстра, ці гарантії виходять із вікна. Модель узгодженості ACID - це сильна модель узгодженості, призначена для важливої ​​або критичної інформації.

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

Незважаючи на те, що RDBMS може масштабувати, а також рішення NoSQL!

Однак бувають випадки, коли RDBMS може і може масштабуватись до такої міри, з якою NoSQL навіть не зможе відповідати. Це просто так інакше. Я розгляну Postgres-XC як приклад того, як можливе масштабування масштабів, не приносячи великих гарантій послідовності.

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

Я розумію, модель Postgres-XC натхненна Teradata. Він складається з вузлів у двох різних ролях, як вузлів зберігання або координаторів. Координатори є багатопровідними (реальну реплікацію не передбачає) і вони підключаються до вузлів зберігання для обробки фактичної обробки даних. Вузли пам’яті копіюються в налаштуваннях ведучого-підлеглого. Кожен вузол зберігання містить те, що по суті є частиною бази даних, але координатори підтримують послідовну картину даних.

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

У зв'язку з цим Postgres-XC пропонує щось подібне до параметрів масштабування NoSQL, але є додаткова складність завдяки додатковим гарантіям послідовності. Я розумію, що є комерційні RDBMS, які пропонують подібну масштабованість там, однак. Терадата це робить. Додатково спільні дискові системи можуть масштабувати аналогічним чином, і DB2, і Oracle пропонують такі рішення. Тож цілком несправедливо говорити, що RDBMS не може цього зробити. Вони можуть. Однак потреба в минулому була настільки мала, що економія від масштабу була недостатньою, щоб зробити власні рішення дуже доступними для більшості гравців.

Нарешті нота про VoltDB. Як і рішення NoSQL, я вважаю VoltDB дуже спеціалізованим інструментом. Це дуже швидко, але за рахунок багатосторонніх транзакцій та довговічності на диску. Це означає, що у вас дуже різний набір проблем. VoltDB - це те, що ви отримуєте, коли піонери RDBMS будують рішення NoSQL ;-). VoltDB є частково швидким, оскільки він визначає сумісність та довговічність поза рівнянням. Довговічність стає властивістю мережі, а не внутрішньо-хост-властивістю, а одночасність керування здійснюється керуванням запитами, один за одним, внутрішньо паралелізованими, в послідовному порядку. Це не традиційна RDBMS (і це непогано, але вона може пройти місця, де традиційні RDBMS не можуть, але навпаки також дуже правда).

Редагувати: Також важливо враховувати наслідки приєднань. У кластеризованих системах приєднання стають зовсім іншими проблемами продуктивності. Якщо все знаходиться на одному вузлі, вони можуть підвищити продуктивність, але якщо вам доведеться здійснити зворотний шлях до іншого вузла, це вимагає дуже високої вартості. Таким чином, моделі даних роблять різниці, а підхід кластеризації впливає на ефективність роботи. Такі підходи, як Postgres-XC та Postgres-XL, припускають, що ви можете витратити досить багато часу на обдумування речей, щоб ви могли належним чином розподілити свої дані та зберігати об’єднані дані разом. Але це накладає дизайн накладних витрат. З іншого боку, ця шкала набагато краще, ніж багато рішень NoSQL, і може бути налаштована належним чином. Наприклад, ми (в Adjust) використовуємо стратегію кластеризації, схожу на NoSQL, для наших 3.5PB даних у PostgreSQL, що є в основному аналізом журналу. І багато наш дизайн глибоко натхненний стратегіями кластеризації NoSQL. Тому іноді модель даних також обмежує модель кластеризації.

Моя відповідь не буде так добре написана, як попередня, але ось що.

Майкл Стоунбракер із слави Інгреса створив сховище стовпців-сховищ MPP (Vertica) та нову базу даних MPP-нової бази даних SQL (VoltDB), яка розподіляє дані між різними вузлами в кластері та підтримує ACID. Vertica відтоді купує HP.

Я вважаю, що й нові бази даних SQL також підтримують ACID, хоча я не впевнений, скільки з них розподіляє свої рядки по кластері тощо.

Ось розмова Stonebraker виступила з Новим SQL щодо NoSQL та "Old SQL". http://www.youtube.com/watch?v=uhDM4fcI2aI

Кластеризація MySQL може відшаровуватись за допомогою багатокористувацької реплікації та хеш-фрагментів по кластеру.