Порівняння реляційних баз даних та баз даних графіків

Хтось може пояснити мені переваги та недоліки бази даних відношень, таких як MySQL, порівняно з базою даних графіків, такою як Neo4j?

У SQL у вас є кілька таблиць з різними ідентифікаторами, що їх пов'язують. Потім вам потрібно приєднатися, щоб з’єднати таблиці. З точки зору новачка, чому б ви розробляли базу даних, щоб вимагати об'єднання, а не мати явні зв’язки як ребра з самого початку, як для бази даних графіків. Концептуально для новачка не було б сенсу. Імовірно, для цього є дуже технічна, але неконцептуальна причина?

За обома стилями насправді стоїть концептуальне міркування. Вікіпедія реляційної моделі та баз даних графіків дає хороший огляд цього.

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

Це має важливі наслідки:

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

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

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

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

Як натякнув Dan1111, більшість баз даних графіків не страждають від такого болю приєднання, оскільки вони виражають відносини на фундаментальному рівні. Тобто відносини фізично існують на диску, і вони називаються, спрямовуються і можуть бути самі прикрашені властивостями (це називається моделлю графіка властивостей, див .: https://github.com/tinkerpop/blueprints/wiki/Property-Graph -Модель ). Це означає, що якщо ви вирішили, ви можете подивитися відносини на диску і побачити, як вони "приєднуються" до сутностей. Отже, відносини є першокласними сутностями в базі даних графіків і семантично набагато сильніші за ті, що маються на увазі відношення, реафіфіковані під час виконання в реляційному сховищі.

То чому ви повинні дбати? З двох причин:

1. Графічні бази даних набагато швидші, ніж реляційні бази даних для підключених даних - сила базової моделі. Наслідком цього є те, що затримка запиту в базі даних графів пропорційна тому, яку частину графіка ви вибрали для дослідження у запиті, і не пропорційна обсягу збережених даних, тим самим знешкоджуючи бомбу приєднання .
2. Графічні бази даних роблять моделювання та запити набагато приємнішими, що означає швидший розвиток та меншу кількість моментів WTF. Наприклад, висловлення друзів-друзів для типової соціальної мережі на мові запитів Cypher від Neo4j є справедливим MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf.

Dan1111 вже дав відповідь, позначену як правильну. Кілька додаткових пунктів, які варто відзначити побіжно.

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

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

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

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

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

За допомогою реляційної бази даних ми можемо моделювати та запитувати графік, використовуючи зовнішні ключі та самоз’єднання. Те, що RDBMS містять слово relational, не означає, що вони добре обробляють відносини. Слово реляційне в СУБД походить від реляційної алгебри, а не від стосунків. У СУБД відносини самі по собі не існують як об'єкт. Він повинен бути представлений явно як зовнішній ключ, або неявно як значення у таблиці посилань (при використанні загального / універсального підходу до моделювання). Посилання між наборами даних зберігаються в самих даних.

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

У певних ситуаціях легше змінити модель даних у базі даних графіків, ніж у СУБД, наприклад, у СУБД, якщо я змінив відношення таблиці з 1: n на m: n, мені потрібно застосувати DDL з потенційним простоєм.

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

Я обговорюю деякі інші плюси і мінуси у своєму дописі в блозі щодо графічних баз даних для зберігання даних

Хоча реляційна модель може легко представити дані, що містяться в графічній моделі, на практиці ми стикаємося з двома важливими проблемами:

1. SQL не має синтаксису, щоб легко виконувати обхід графіків, особливо обходів, де глибина невідома або необмежена. Наприклад, використання SQL для визначення друзів ваших друзів досить просто, але важко вирішити проблему “ступенів розлуки”.
2. Продуктивність швидко погіршується, коли ми переходимо графік. Кожен рівень обходу значно додає час відповіді на запит.

Довідково: Бази даних наступного покоління

Бази даних графіків варто дослідити щодо випадків використання, в яких вони перевершуються, але я мав певні підстави сумніватися у деяких твердженнях у відповідях вище. Зокрема:

Реляційна база даних набагато швидша при роботі з величезною кількістю записів (перший маркер dan1111)

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

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

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