Когда я должен использовать базу данных NoSQL вместо реляционной базы данных? Можно ли использовать оба на одном сайте?

Решения NoSQL обычно предназначены для решения проблемы, когда реляционные базы данных либо недостаточно подходят для использования, либо слишком дороги в использовании (например, Oracle), либо требуют, чтобы вы реализовали что-то, что в любом случае нарушает реляционную природу вашего db.

Преимущества обычно специфичны для вашего использования, но если у вас нет какой-либо проблемы моделирования ваших данных в СУБД, я не вижу причин, по которым вы выбрали NoSQL.

Я сам использую MongoDB и Riak для конкретных проблем, когда RDBMS не является жизнеспособным решением, для всех остальных я использую MySQL (или SQLite для тестирования).

Если вам нужен NoSQL db, который вам обычно известен, возможны следующие причины:

• клиент хочет 99,999% доступность сайт с высоким трафиком.
• Ваши данные нет смысла в SQL, вы оказываетесь выполнение нескольких запросов JOIN для доступ к некоторой части информации.
• вы нарушаете реляционные модель, у вас есть CLOB, которые хранят денормализованные данные, и вы генерируете внешние индексы для поиска этих данных.

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

О, и по второму вопросу совершенно прекрасно использовать любую технологию в сочетании с другой, поэтому, чтобы полностью завершить мой опыт, MongoDB и MySQL работают отлично вместе, пока они не находятся на одной машине

У Мартина Фаулера есть отличный видео, который дает хорошее объяснение базам данных NoSQL. Ссылка идет прямо на его причины, чтобы использовать их, но все видео содержит хорошую информацию.

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

• Несоответствие объектно-реляционного импеданса - Объекты вашего домена не очень хорошо подходят в схеме базы данных relaitional. NoSQL позволяет вам сохранять свои данные в виде документов (или графиков), которые могут значительно приближаться к вашей модели данных.

NoSQL - это система баз данных, в которой данные помещаются в документ (MongoDB), пара ключ-значение (MemCache, Redis), форма структуры графика (Neo4J).

Возможно, здесь возможны вопросы и ответы на вопрос "Когда идти за NoSQL":

• Требовать гибкую схему или иметь дело с древовидными данными?
  Как правило, в гибкой разработке мы начинаем разрабатывать систему, не зная все требования в авангарде, где в дальнейшем по всей системе баз данных разработки могут потребоваться частые изменения в дизайне, демонстрируя MVP (минимально жизнеспособный продукт). Или вы имеете дело с схемой данных, которая носит динамический характер. например Системные журналы, очень точный пример - журналы AWS cloudwatch.

• Набор данных обширен/большой?
  Да База данных NoSQL является лучшим кандидатом для приложений, где база данных должна управлять миллионами или даже миллиардами записей без ущерба для производительности.

• Обмен между масштабированием по консистенции
  В отличие от RDMS, база данных NoSQL может потерять небольшие данные здесь и там (примечание: вероятность -.x%), но ее легко масштабировать с точки зрения производительности. Пример. Это может быть полезно для хранения людей, которые находятся в режиме онлайн-обмена сообщениями, токенов в db, регистрации статистики трафика веб-сайта.

• Выполнение операций геолокации: MongoDB поддерживает богатую поддержку операций GeoQuerying и Geolocation. Мне очень понравилась эта особенность MongoDB.

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

Я столкнулся с этим вопросом, ища убедительные основания для отклонения от проекта РСУБД.

Существует большой post Джулиана Брауна, который проливает свет на ограничения распределенных систем. Эта концепция называется теоремой Brewer CAP, которая в общем сводится к следующему:

Три требования распределенных систем: Согласованность, Доступность и Толерантность раздела (CAP вкратце). Но вы можете иметь только два из них за раз.

И вот как я обобщил это для себя:

Лучше пойти на NoSQL, если Consistency - это то, что вы жертвуете.

Некоторая существенная информация отсутствует, чтобы ответить на вопрос: какие варианты использования базы данных должны быть доступны? Должны ли выполняться сложные анализы из существующих данных (OLAP) или приложение должно обрабатывать многие транзакции (OLTP)? Какова структура данных? Это далеко не конец вопроса.

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

Радость разработчиков со словом "схема меньше" в NoSQL в начале тоже очень велика. Это модное слово быстро разочаровывается после технического анализа, потому что оно правильно не требует схемы при записи, но вступает в игру при чтении. Вот почему он должен правильно быть "схемой при чтении". Может возникнуть соблазн иметь возможность писать данные по собственному усмотрению. Но как я могу справиться с ситуацией, если есть существующие данные, но новая версия приложения ожидает другую схему?

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

Если вы примете аргумент о том, что Google и Amazon разработали свои собственные базы данных, потому что обычные РСУБД перестают обрабатывать поток данных, вы можете только сказать: вы не Google и Amazon. Эти компании являются лидером, около 0,01% сценариев, где традиционные базы данных больше не подходят, но для остального мира они есть.

Что незначительно: SQL существует уже более 40 лет, а миллионы часов развития перешли в большие системы, такие как Oracle или Microsoft SQL. Это должно быть достигнуто некоторыми новыми базами данных. Иногда также легче найти администратора SQL, чем кого-то для MongoDB. Это подводит нас к вопросу обслуживания и управления. Тема, которая не совсем сексуальна, но это часть технологического решения.