Коли слід використовувати документ відносно реляційної та графічної бази даних? [зачинено]

Для цілей обговорення розглянемо сценарій FourSquare.

Сценарій

Суб'єкти:

• Користувачі
• Місця

Відносини:

• Checkins: користувачі <-> місця, багато-багато
• Друзі: користувачі <-> користувачі, багато-багато

Дизайн баз даних

Вони, швидше за все, матимуть помилки, будь ласка, вкажіть їх.

RDBMS

Таблиці:

• Користувачі
• Місця
• Перевірки (перехід)
• Друзі (перехрестя)

Плюси:

• CAP: послідовність, доступність

Мінуси:

• CAP: толерантність до перегородки, відома також як шардінг
• схеми = негнучка структура
• погана тиражування?

Графік

Об'єкти:

• Користувачі
• Місця

Краї:

• Друзі: Користувач <-> Користувач
• Checkins: Користувач -> Місця
  • містить часову позначку

Плюси:

• CAP: послідовність, доступність?
• об'єкти та краї, що легко змінюються, без змін
• запити проходження графіків, наприклад:
  • кластеризація
    • знаходження груп друзів
    • знаходження ресторанів, які сподобалися подібним людям
  • будь-які інші поширені / корисні запити?

Мінуси:

• CAP: толерантність до розділів?

Документ / об’єкт

3 окремі бази даних?

• Користувачі
  • список друзів
• Перевірки
  • мітка часу
  • користувач
  • місце
• Місця

Плюси:

• CAP: наявність, толерантність до перегородки
• схематично об'єкти, що легко змінюються

Мінуси:

• CAP: консистенція

Запитання

Для запису вони закінчилися використовувати MongoDB. На додаток до всіх цих знаків питання вище:

1. Я не впевнений, як реалізувати базу даних документів.
2. Як бази даних документів набувають толерантності до розділів?
3. Щоб отримати контрольні реєстрації для одного користувача, я припускаю, що операція проаналізувала б усі перевірки та відфільтрувала б метадані на ім’я користувача (map + filter). Продуктивність розбору 1000 000+ документів для кожного користувача була б жахливо поганою. Я припускаю, що це не правильна поведінка?
4. Які ще є плюси?

Ваше запитання може бути темою семестрового курсу коледжу. Вам потрібно розбити її на керовані шматки. Як такий я просто викину часткові відповіді.

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

Далі - як ви ставитесь до властивостей кислотних кислот: Атомність, Консистенція, Ізоляція та Міцність. Бази даних SQL надають суттєві гарантії щодо всіх 4. Бази даних NoSQL, як правило, не обіцяють усіх 4, і шляхи їх відхилення є одними з ключових відмінностей, що розмежовують різні реалізації баз даних NoSQL. З іншого боку, неможливо гарантувати послідовність та доступність перед розділом (див . Торем CAP Brewer ), тому жодна база даних SQL не зробить, якщо ви наполягатимете на повній доступності перед розділом. Особисто я дуже дбаю про довговічність даних у базі даних, оскільки я зазвичай працюю з даними, де навіть втрата даних 0,0001% неприйнятна, а набори даних досить малі, що мені не потрібно хвилюватися про розділи, тому я сильно віддають перевагу базам даних SQL.

Ще одне дуже практичне врахування - це якість серверного коду, наявність адміністраторів баз даних та програмістів, якість підтримки, доступної для проблем, що виникають, якість та доступність інтерфейсних бібліотек для підключення вашого додатка до бази даних тощо. MySQL існує вже майже 2 десятиліття, обробляється переважна більшість помилок, дуже широко використовується, тому має як велику підтримку, так і велику доступність персоналу, і, ймовірно, буде підтримуватися протягом наступних 10 років. Ти не можеш сказати жодної речі про Riak.

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