Чаще ограничения по индексам. Например - только по первичному ключу или только 2 вторичных, только числовые (а не хеш) и пр.. Это в свою очередь влияет на варианты репликации и технологию шардирования. А само содержимое - как правило бинарное - хотите туда data-record закладывайте, а хотите JSON-data . но главное - в логике соединений наборов данных- как правило все это на клиента отдается - ни сложных, ни вложенных select-ов в key value почти не бывает

Пример неприятных данных - погодные api, даже профессиональные погодные сайты не для "смертных", а для авиации, например, отдают эти данные очень странно. Они не вложены как надо и не нормализованы. Даты отдельно, время отдельно, сдвиг часового пояса отдельно, нарезки температур отдельно и т.д. Вот если не обработал положить эти данные не в документную, а в key-value бд, то будет боль фильтрации. Когда нужно много срезов по разным погодным моделям.

Пример почти искусственный, его можно решить обработкой, но это пример плохих данных для РСУБД и key-value или graph.

Изначально Монга приобрела популярность благодаря schema less и удобству работы с JSON (можно искать, индексировать)

Да, пришлось пожертвовать ACID, включая D (duration). По крайней мере на начальном этапе

Почти все noSQL хранят индексы и данные в памяти. чтобы хоть чем то от RDBMS отличаться в лучшую сторону 😉 Но SQL тоже догоняют - данные в памяти уже есть и у Oracle, и у MS SQL

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

Любую СУБД нужно очень хорошо знать, как разработчикам, так и инженерам, которые её эксплуатируют.

То есть нужно учить массу людей или нанимать уже с опытом.

Плюс поддержка.

Так это все есть и в key-value и при этом я не вижу в mongo каких-то специальных решений для упрощения работы с версиями или со связями или с индексами, все примерно на уровне key-value.
При этом тот же PG/JSONB даст даже больше возможностей и не меньше производительности.

Добрый день!

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

Кому будет интересно, можете посмотреть по ссылке:

https://youtu.be/dUeFaucs-pw

При наличии честного ACID, людей на рынке и возможности купить поддержку (в хорошем смысле)

В PgSQL работа со сложным JSONB это мат) И он там просто как есть. Это одно толстое значение, а не разобранная структура. И да, крутые key-value вроде CouchBase умеют почти все то же самое.

Эээ, ты что?
jsonb - это именно разобранная структура. И синтаксис работы с json в PG гораздо лучше, нежели в той же монге.

Видимо давно не пробовали монгу) я говорю относилтно специальных бд для json, а не тех, куда впихивается json и потом языком вроде asm можно вынуть.

У нас давно и успешно Монга используется в энтерпрайзе для хранения логов в виде документов. И не из-за ее бесплатности.  Ее поддерживаем сами.

Всё что угодно где-то успешно используется. Вообще всё

Так синтаксис запросов в монге не менялся же? Он как был чудовищным, так и остался (да и вообще json как структура запроса - это кошмар)
При этом в PG сейчас json - это нормальный базовый тип, с полноценной поддержкой поверх.
Понятно, что сделать удобный инструмент работы с json вообще очень не просто (как и с любыми иерархическими данными), но в PG очень неплохо справились с этой задачей.

да на них много Enterprise построены и даже форков на ее модифицированных вроде AWS DocumentDB или где Mongo Enterprise идет в составе другого платного решения.

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

Хранения логов? OMG...

Так что за ниша? Где монга чем-то лучше своих конкурентов?

Так, давайте снизим накал)

Монга в своё время была действительно очень удобной, потому что завораживала идея Schemaless.
Лично мне она тоже нравилась.

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

Вопрос в другом, имеет ли смысл на сегодня "затаскивать" её в ладншафт (зоопарк) со всеми вытекающими последствиями.

я уже писал. слабосвязанные документы. неструктуированное хранение. Часто CRM на них строят или WiKi-системы со свободными данными.

угу. А чем при этом монга удобнее того же PG (в котором тоже легко делать слабосвязанные документы или неструктурированное хранение) или Couchbase (аналогично)?
При том, что сложные запросы проще делать на PG, а масштабирование лучше на Couchbase