NoSQL СУБД

Excel.

NoSQL всё разные, это ж собирательное название.

Очевидный тарантул очевиден

Да, тут промахнулся. Уточню задачу - хранятся документы (редакции) и ошметки понятия «товар», «профиль пользователя», «страница». Все это счастье сейчас живет на Mongodb.

А она разве не для InMemory в основном?

А монго разве не для инмемори в основном? Но при этом у вас вполне себе работает

libmdbx же!

In memory для монги по моей практике наоборот не частый кейс. Скорее как исключение и когда в редиску не хотят по каким-то причинам

Так и в тарантуле можно инмемори движок хранения использовать, а можно для дискового хранения - винил, на базе lsm деревьев, как в монге

Хм, кстати вспомнился тут ferretdb, не смотрели?

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

задачи сугубо под NoSQL подходят

Ты же понимаешь, что NoSQL это базворд мало что значущий, и все эти nosql СУБД отличаются чуть менее чем полностью?

Ну это вообще классический Postgres.

Мускул. И похапэ

Важно не что хранится, а какие запросы к БД и в каком виде результат.

Тебе для каких целей база данных нужна? И по каким параметрам в ней искать что-то будешь?

0. Хранение аккаунтов пользователей. В них информация нужная исключительно для аутентификации.
1. Профили аккаунта. Их может быть N типов. В себе содержат ошметки от аккаунтов. Фактических из них уже формируется список доменных пользователей.
2. Каталог товаров - это разные ссылки, в GridFS изображения, характеристики и прочее. Фактически каждый тип товара имеет мало общего с другим.
3. Иерархия отдельно, для каждого типа товаров (хранится в отдельной коллекции). Получаем сущность «каталог типа Х».
4. Ворох плоских справочников (предзаданных), состоят из ключ/значение.
5. Ворох не плоских справочников (пользовательских), состоят из ключ/значение.

По сути - все.

По итогу, в БД хранится или слепок страницы конкретной фактически, или агрегат из нескольких коллекций.

Русский не родной? Я ничего не понял.

Вроде как монга, которую ты используешь, прекрасно справится с хранением данных.

Каталог товаров - это разные ссылки, в GridFS изображения, характеристики и прочее. Фактически каждый тип товара имеет мало общего с другим.

У тебя затык будет именно с полученным результатом от БД.

Монга подходит). На ней сейчас все и крутится.

Вопрос - есть ли аналоги безопасные во времена санкций (стало интересно).

И что из этого плохо ложится на реляционную БД (кроме, вероятно, каталога товаров, для чего, в принципе, и придумывают всякие документные расширения реляционных СУБД, насколько они хороши — вопрос отдельный)?

А что если ничего не лохится хорошо на РСУБД в принципе?

тхинк аут оф зе бокс, типа

Монга подходит). На ней сейчас все и крутится.

Вопрос - есть ли аналоги безопасные во времена санкций (стало интересно).

а чем монга не безопасна ?

есть ещё https://couchdb.apache.org/, тоже документная база, хранит json, поддерживает ревизии документов.

как вариант, тарантул или эластиксеарч. Но по поводу санкций не понял, это вроде как опенсорс.

Реляцию не предлагать - задачи сугубо под NoSQL подходят

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

И что из этого плохо ложится на реляционную БД (кроме, вероятно, каталога товаров

Каталог товаров тоже хорошо ложится на РСУБД, инфа 100)

Postgresql. Когда он с этими задачами и твоей нагрузкой не справится, напиши, придумаем как оптимизировать.

Уточню задачу - хранятся документы (редакции) и ошметки понятия «товар», «профиль пользователя», «страница». Все это счастье сейчас живет на Mongodb.

Задача у тебя под реляционку (кроме документов, я хз что там, понятие оч. общее). У тебя каша вместо структуры данных. Тебе нужна какая-то nosql под кашу, потому что ты не хочешь все это структурировать. Чем тебе не нравится твоя монга? Она же оперсорц, какая разница. Ну тарантула возьми, если хочешь отечественного производителя, у тебя бд влазит в память и не нужны какие-то поехавшие запросы. Там всё валится на диск так или иначе.

Они все инмемори. У всех есть какие-то кэши в памяти и на диске. Разница в том, что есть классический acid с журналами транзакций, консистентностью, индексами и вот этом вот всем, и прочие поделки, для acid надо делать велик, зато они выигрывают по скорости, например.

Все ложится на РБД, а что не ложится, можно засунуть в eav.