Слабые стороны с различными типами баз данных NoSQL

Вот мой вопрос: каковы недостатки с различными типами баз данных NoSQL? В частности, каковы недостатки хранилищ значений ключей, хранилищ данных графиков и хранилищ документов?

Мне было легко найти сильные стороны, но документы о слабых сторонах кажутся скуднее.

Изменить: по сравнению друг с другом, и реляционных баз данных.

Самая большая сила / слабость любого распределенного хранилища данных проистекает из теоремы CAP. См. Http://blog.nahurst.com/visual-guide-to-nosql-systems для краткого изложения того, что это означает на практике для большого количества систем NoSQL, которые там существуют.

Если вы сравниваете их с реляционными базами данных, очевидным недостатком является то, что хранилища ключ-значение не являются реляционными. Следовательно, может быть сложнее писать отчеты с использованием хранилищ значений ключей, чем с использованием реляционной базы данных, для которой такие отчеты и извлечение данных специально предназначены.

Это очень субъективно, то, что вы думаете, может быть слабостью, кто-то может подумать, что это его самая сильная сторона.

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

Таким образом, недостатком любого продукта является его неспособность делать то, что вам нужно, чтобы делать это эффективным образом во времени или пространстве.

Начну с того, что мне нравятся базы данных NoSQL, и я нахожусь в процессе отказа от наших баз данных и приложений на основе SQL, где это имеет смысл. Этот процесс выявил одну серьезную слабость - оперативной истории просто еще нет. Что я имею в виду под этим:

• NoSQL по-прежнему быстро движущаяся цель. Вы должны быть очень близко знакомы с этим, чтобы знать, что изменилось между версиями. С оперативной точки зрения это создает несколько трудностей - системные администраторы используются для обоснованного документирования материалов с лучшими практиками. Когда лучшие практики не определены, им становится немного страшно.
• Очень, очень немногие люди знакомы с управлением ими за пределами сообщества разработчиков. Это усложняет задачу, когда вы хотите передать продукт операциям и покончить с ним.
• Лучшие типы операций, как правило, способны обрабатывать легкий SQL и, по крайней мере, распознавать его. Json или что-нибудь из того, что говорит ваш nosql, является чем-то вроде кривой обучения.
• Репутация - сложная вещь - потеря данных очень страшна для типов операций. Они пришли к убеждению, что базы данных SQL переживут ядерную катастрофу. NoSQL будет чем-то вроде коммерческой работы там.

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