[Это давно ожидаемая запись в блоге, представляющая собой третью часть серии статей о Happ, нашем проекте Assignment 3. Предыдущая часть здесь.]

Мне задавали этот вопрос столько раз, но я так и не смог дать окончательный удовлетворительный ответ. Итак, сегодня я попытаюсь провести некоторое сравнение между ними, а ближе к концу я кратко объясню, какая база данных должна быть более подходящей для Happ.

Давайте сначала развеем несколько мифов.

Миф №1: noSQL лучше/хуже, чем SQL

Нет, ни один из них.

Некоторые проекты лучше подходят для использования реляционной базы данных SQL. Некоторым нужна гибкость noSQL. Некоторые могут даже использовать оба для более специализированных целей.

В настоящее время современные платформы приложений можно настроить для быстрого использования нескольких баз данных за считанные минуты.

Миф №2: NoSQL = отсутствие SQL

Вместо того, чтобы ограничиваться таблицами в реляционных базах данных, в базах данных NoSQL существуют различные способы хранения данных. Поэтому предпочтительнее понимать NoSQL как Не только SQL.

Вот основные 5 категорий с некоторыми наиболее известными представителями:

  • Документ: MongoDB, CouchDB, база данных Firebase
  • Параметр "ключ-значение":Redis, Firebase Remote Config, Aerospike (очень интересное хранилище типа "ключ-значение", в котором используется функция нулевого копирования твердотельных накопителей для максимальной скорости чтения/записи).
  • Столбец:HBase (знакомый тем, кто работает с большими данными).
  • График: Neo4j. Те, кто сдает CS3233 — соревновательное программирование, знают, что графики — это круто.
  • Мультимодель: базы данных, поддерживающие как минимум две модели, например FoundationDB.

Все эти варианты NoSQL еще раз иллюстрируют тот факт, что существует несколько типов баз данных, которые соответствуют различным требованиям, поэтому вопрос «SQL или noSQL» без конкретного контекста просто бессмысленен.

Миф №3: буква "С" в словах ACID и CAP одинаковая

На самом деле это довольно распространенное заблуждение. Давайте сначала вернемся к некоторым теоретическим пикантным моментам.

Вот определения вместе с соответствующими ссылками на термины, точно так же, как список Википедии на страницах:

ACID= Атомарность, Последовательность, Изоляция, Долговечность
CAP = Последовательность , Доступность, Допуск разделения

Обратите внимание, что Consistency в обеих аббревиатурах указывает на одну и ту же ссылку https://en.wikipedia.org/wiki/Consistency_(database_systems)? Ой. На самом деле это два совершенно разных понятия.

Непротиворечивость в смысле ACID означает, что база данных будет следить за тем, чтобы данные соответствовали всем определенным правилам и ограничениям. В реляционном мире это означает, что должны выполняться ограничения целостности. Некоторые примеры:

  • Установка NOT NULL для заданного поля.
  • Поле INTEGER гарантированно не допускает строковых данных.
  • внешний ключ (ограничение ссылочной целостности), который не позволяет удалить строку в таблице department, если в таблице employee есть записи, ссылающиеся на >отдел.

Базы данных NoSQL не поддерживают ограничения целостности. Ссылочные и другие типы ограничения целостности должны быть вручную встроены в само приложение. Таким образом, эти базы данных никогда не могут быть полностью совместимы с ACID; строгая согласованность уступает место более высокой масштабируемости, лучшей производительности при работе с огромным потоком данных и постоянной доступности.

MongoDB Забавный факт №1: MongoDB не обеспечивает ACID-согласованности даже на уровне документации, в отличие от того, что они заявляют в официальный FAQ.

Однако, когда вы слышите, как люди, использующие NoSQL, говорят об непротиворечивости, скорее всего, они говорят не о букве «C» в ACID, а скорее об ограничении, которое распределенная база данных должна иметь. превосходить.

Распределенная база данных обычно реплицирует часть данных на несколько машин. Когда эта часть информации обновляется на одном из компьютеров, потребуется неизбежная задержка во времени (обычно миллисекунды), прежде чем обновленное уведомление достигнет всех других экземпляров компьютера. Хотя отставание небольшое, его нельзя не заметить: есть вероятность, что вы можете получить старую информацию, которая не обновлялась на реплике. Традиционно в реляционном мире вы, возможно, слышали об этом как об грязном чтении.

Забавный факт о MongoDB №2.Чтобы защитить их вводящее в заблуждение заявление о совместимости с ACID, FAQ по MongoDB вместо этого выявляет распределенную согласованность.

Некоторые другие авторы предложили бы линеаризуемость как лучшую альтернативу распределенной согласованности, но это нормально, если мы четко понимаем, о чем говорим. Распределенная согласованность, наряду с двумя другими аспектами, составляет суть теоремы CAP.

Теорема CAP утверждает, что в распределенной системе вы можете одновременно обеспечить не более двух из трех гарантий Непротиворечивость, ДоступностьилиРазделение. толерантность. Толерантность к разделению — это не выбор, которым мы можем поступиться, как довольно подробно объясняется здесь:

Чтобы распределенная (т. е. многоузловая) система не требовала устойчивости к разделам, она должна работать в сети, которая гарантирует отсутствие потери сообщений (или даже доставку опаздывают) и чьи узлы гарантированно никогда не умрут. Мы с вами не работаем с такими системами, потому что их не существует.

Некоторые базы данных NoSQL жертвуют распределенной согласованностью ради доступности, что делает их AP. Тем не менее, они предоставляют альтернативную (более слабую) гарантию, известную как согласованность в конечном итоге, которая просто означает, что реплики будут совместно использовать одни и те же данные через некоторое конечное времяпродолжительность.

Вот хорошее визуальное руководство, в котором представлены версии NoSQL и то, как они вписываются в CAP:

Дело Хэппа

Happ, будучи приложением на основе местоположения, должно хранить большое количество геопространственных объектов. На самом деле существует несколько геопространственных решений как для реляционных, так и для noSQL:

и многое другое.

Первоначально мы выбрали PostgreSQL + PostGIS для MVP Happ (чтобы повторно использовать коды из более ранних проектов и сэкономить время), но в ретроспективе лучшим выбором был бы noSQL.

Наиболее важными объектами в Happ являются happs (публикации, добавленные пользователями) и события. Хотя они имеют одну и ту же цель предоставления информации для размещения маркеров на карте, их основные атрибуты различны. Поэтому в нашей базе данных мы извлекли общие атрибуты двух объектов в другую таблицу: thing. Каждая строка из таблиц happ и event должна относиться к вещи.

По общему признанию, было сложно реализовать это на бэкэнде, но, к счастью, дизайн принёс большую пользу интерфейсу. Например, пользователи могут голосовать или комментировать как события, так и события. Благодаря этой абстракции эти действия можно было отнести к более абстрактному понятию вещь (например, /thing/vote и /thing/comment), таким образом стандартизировав API.

Поскольку мы, возможно, продолжим разработку Happ после окончания семестра, мы могли бы рассмотреть возможность замены PostgreSQL документной альтернативой в качестве основной базы данных. Таким образом, мы можем хранить как события, так и события в одной и той же коллекции thing, что упрощает реализацию серверной части.

Тем не менее, наше время, проведенное с PostgreSQL, дало нам некоторое представление о базе данных, что станет темой моего следующего сообщения в блоге из этой серии. Быть в курсе.