Вопрос по – Сценарии сценариев использования NoSQL или КОГДА использовать NoSQL [закрыто]

220

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

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

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

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

Благодарность

Ваш Ответ

2   ответа
156

генеральны точки

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

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

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

Заявление о том, что NoSQL не поддерживает объединения, вводит в заблуждение. Некоторые базы данных NoSQL на самом деле гораздо лучше объединяются, чем реляционные базы данных. Некоторые вообще их не поддерживают. Этот ответ, кажется, больше относится к MongoDB в частности, чем к NoSQL в целом. Alan Plum
Отличное резюме. @AlanPlum, на какие конкретные базы данных NoSQL вы ссылаетесь? brian
@ Брайан Я участник ArangoDB Arangodb.com), представляющий собой смесь базы данных документов (например, MongoDB) и базы данных графов (например, Neo4J) с не только дешевыми объединениями, но и реальными транзакциями. Тем не менее, базы данных NoSQL не являются однородной группой, и невозможно обобщить одну базу данных NoSQL до всей «категории». Alan Plum
8

что Nosql, по крайней мере, «более подходит» в этих сценариях (приветствуются дополнительные)

Легко масштабировать, просто добавляя больше узлов.

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

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

Узкое место ввода-вывода диска

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

Я не понимаю, что может быть проблемой с СУБД для # 2. А у NoSQL меньше дискового ввода-вывода, как у # 3? avi
Как говорит @avi, я думаю, что проблема №2 не проблема, если вы запрашиваете таблицы по индексу. Миллионы строк? Хорошо, получите только те индексы, которые я хочу использоват Xtreme Biker
# 2 и 3 оба ложные. В течение двух я провел тесты производительности при импорте / экспорте данных и видел, как SQL Server 2014 сокрушил Mongo при импорте и экспорте больших данных. Для 3 строго типизированные данные в SQL обычно занимают (я видел более 50% до сжатия) гораздо меньше места, чем базы данных документов. brian
Да, и даже для # 1, я просто не понимаю. Расширение является частью контракта на кластеризацию, который предлагают все основные rdbm Sebas

Похожие вопросы