База данных документов и реляционная база данных: как выбрать?

Я парень по SQL, но я знаю, что есть не только базы данных SQL - в основном документ-база данных. Как и в большинстве технологий, у каждой технологии есть свои плюсы и минусы.

Я прочитал несколько статей, но они были слишком теоретическими. То, что я хотел бы, это два реальных случая:

1. когда переход с реляционной базы данных на документ дал улучшение
2. когда переход от документа к реляционной базе данных дал улучшение

Улучшение - это любая вещь, которая делает лучшие программы - меньше времени разработки, масштабируемости, производительности, всего, что связано с программированием. Есть предостережение для 2.: истории вроде «возврата к реляционной базе данных, потому что все знают SQL» - это не хорошо

В последние годы основной причиной выбора базы данных NoSQL была доступность . Для таких компаний, как Amazon, Google и Facebook час простоя или около того недопустим. Чтобы обеспечить высокую доступность, вам необходимо уменьшить число точек отказа, а это означает, что вам нужно использовать распределенную систему с несколькими компьютерами, в случае сбоя компьютера служба все еще доступна.

Традиционные базы данных Relatione не очень хороши в распределенной установке с несколькими мастерами. Вот почему NoSQL был так популярен в последнее время. Поэтому, если вам нужна высокая доступность, вы можете выбрать базу данных NoSQL, такую ​​как Riak, Cassandra, HBase, S3 или BigTable.

Есть хороший пост в блоге об Amazon Dynamo, который является хорошим введением в распределенные базы данных NoSQL.

Теперь термин NoSQL очень широк, поэтому есть много баз данных NoSQL, которые не распространяются. Но они решают другие проблемы. Например, Neo4j - графическая база данных хороша для запросов, для которых традиционные СУБД не оптимизированы. Или как в вашем случае база данных документов, где вам не нужно менять схему, если вы хотите добавить некоторые поля для некоторых документов. Другими словами, база данных документов хороша, когда большинство постов (документов) имеют разные поля, поэтому реляционная таблица с предопределенными столбцами не может использоваться.

Однако большинство баз данных NoSQL не так гибки, как традиционные базы данных RDBMS, поэтому рекомендуется использовать традиционную базу данных RDBMS, пока она больше не сможет решить ваши проблемы.

У меня есть простой подход, чтобы определить базу данных, которая лучше всего соответствует данным.

Я просто спрашиваю себя: если у меня нет базы данных, я бы предпочел сохранить большинство и важные данные в виде документа или сохранить их в электронной таблице.

Когда ответом является «Электронная таблица», это явный признак того, что реляционная модель и традиционная СУБД лучше всего подходят для большинства задач. Если данные действительно простые, например, только пары ключ-значение или простые таблицы, а ссылочная целостность не является темой, то база данных NoSQL, вероятно, лучше всего подходит для этой задачи и может значительно повысить производительность!

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

Когда данные больше похожи на документы, например, иерархически структурированные текстовые данные без четких отношений, я сразу же вспоминаю XML-базу данных, которая позволяет легко хранить иерархически структурированные документы. Иногда лучше использовать программное обеспечение для управления документами.

Итак, чтобы дать конкретный и простой ответ на оба ваших вопроса: это зависит от данных.

когда переход с реляционной базы данных на документ дал улучшение

Когда вам необходимо сохранить иерархически структурированные текстовые данные, база данных Xml может стать большим улучшением с точки зрения удобства сопровождения и, возможно, также масштабируемости.

когда переход от документа к реляционной базе данных дал улучшение

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

Нам пришлось отказаться от реляционной модели, потому что данные, которые мы получали, не имели простой, очевидной, фиксированной, статической схемы.

Пользователи и пользовательские истории не имели фиксированной статической схемы.

Мы пытались навязать фиксированную статическую схему RDBMS, но это было ошибкой.

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

Если бы мы рассматривали каждую запись как «документ» с общим подмножеством элементов и уникальным (а также плохо определенным) набором дополнительных элементов данных, мы были бы намного счастливее.

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

Фиксированная статическая схема реляционной модели не соответствовала нашим сценариям использования.