NoSQL использует сценарии использования или КОГДА использовать NoSQL

При всей рекламе кажется очень трудно найти достоверную информацию о том, когда использовать это. Поэтому я задаю следующие вопросы, и я сожалею, если это действительно глупые вопросы заранее:

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

Я предполагаю, что нет? И я чувствую, что NoSQL - это просто для быстро доступных вещей, из которых это нормально, чтобы потерять данные. Но я также читал, что приложения NoSQL имеют встроенную избыточность, поэтому я не теряю данные?

Также, если приведенные выше 2 примера плохие, не могли бы вы дать мне конкретные примеры использования бизнеса, где я бы использовал NoSQL? Я вижу много общих описаний, но не очень много реальных примеров. Единственное, что я могу придумать, это обмен сообщениями и аналитикой пользователя.

Спасибо!

Ответы

Ответ 1

Это действительно вопрос "это зависит". Некоторые общие баллы:

  • NoSQL, как правило, хорош для неструктурированных/"без схемы" данных - обычно вам не нужно явно определять свою схему заранее, и вы можете просто включать новые поля без всякой церемонии
  • NoSQL обычно предпочитает денормализованную схему из-за отсутствия поддержки JOIN в мире RDBMS. Таким образом, у вас обычно будет плоское, денормализованное представление ваших данных.
  • Использование NoSQL не означает, что вы можете потерять данные. Разные БД имеют разные стратегии. например MongoDB - вы можете выбрать уровень компромисса между производительностью и потенциалом потери данных - лучшая производительность = больше возможностей для потери данных.
  • Часто очень легко масштабировать решения NoSQL. Добавление большего количества узлов для репликации данных - это один из способов а) обеспечения большей масштабируемости и б) обеспечения большей защиты от потери данных в случае отказа одного узла. Но опять же, зависит от БД/конфигурации NoSQL. NoSQL не обязательно означает потерю данных, как вы делаете вывод.
  • ИМХО, сложные/динамические запросы/отчеты лучше всего обслуживать из РСУБД. Часто функциональность запросов для БД NoSQL ограничена.
  • Это не должен быть 1 или другой выбор. Мой опыт использования RDBMS в сочетании с NoSQL для определенных случаев использования.
  • БД NoSQL часто не имеют возможности выполнять элементарные операции над несколькими "таблицами".

Вам действительно нужно посмотреть и понять, что представляют собой различные типы хранилищ NoSQL, и как они обеспечивают масштабируемость/безопасность данных и т.д. Трудно дать общий ответ, поскольку все они на самом деле разные и по-разному решают проблемы..

Для MongoDb в качестве примера, посмотрите их Use Cases, чтобы увидеть, что они предлагают как "хорошо подходящие" и "менее подходящие" варианты использования MongoDb.

Ответ 2

Я думаю, что Nosql является "более подходящим" в этих сценариях по крайней мере (более приветствуется дополнение)

  • Простота масштабирования путем добавления большего количества узлов.

  • Запрос на большой набор данных

    Представьте, что тонны твитов отправляются на твиттер каждый день. В RDMS могут быть таблицы с миллионами (или миллиардами?) Строк, и вы не хотите делать запрос в этих таблицах напрямую, даже не говоря уже о большинстве случаев, объединения таблиц также необходимы для сложных запросов.

  • Узкое место для дискового ввода/вывода

    Если веб-сайт должен отправлять результаты различным пользователям на основе информации о реальном времени пользователей, мы, вероятно, говорим о десятках или сотнях тысяч запросов чтения/записи SQL в секунду. Тогда диск i/o станет серьезным узким местом.