> Redis vs Tarantool - если поискать, то наверное у "редиски" есть что-то
> отсутствующее в тарантуле.
> Но с учетом всех возможностей тарантула я бы на редиску даже не
> смотрел.Думаю как раз суперпродвинутые и не нужны будут. Хотя я теперь понял что все эти редиски про in-memory т.е. для горячих данных которые злым клиентам надо быстро отдавать - у нас такой задачи по большому счёту нет.
> Скорее всего ваша задача полностью решается в тарантуле, ибо там есть "винил"
> и SQL.
> Но если аналитики много, то clickhouse.
Для аналитики вполне хватает SQL, там в основном отчеты.
> Более-менее гибкие права доступа есть только в SQL.
> В мире NoSQL это не затребовано и (как-правило) реализуется на уровне логики
> приложения, хотя всегда есть исключения...
Да, аутентификацию/авторизацию всегда можно возложить на тот же LDAP в приложениях.
> LDAP для другого - это прежде всего справочник пользователей, который редко меняется
> и много читается.
Нет, я знаю, где обычно применяются сервера справочников. Я сам для интереса поднимал openldap с другими службами.
Но знаю, что применяется и как БД (более) общего назначения.
> Но относительно подходит, так как в принципе это key-value ("путь в иерархии"
> -> "набор атрибутов").
Вот на это расчет и есть, что может зайдёт. Опасения именно что привычного из SQL будет не хватать, вроде тех же изменений схемы.
> Причем чем больше вам подходит key-value, тем больше подходит и LDAP.
> Сам бы я не смотрел на LDAP при наличие тарантула, с одним
> исключением - для LDAP возможна мульти-мастер синхронизация содержимого (aka репликация)
> без привязки к линейной истории транзакций, а таратнуле наоборот (репликация примерно
> как replay транзакций).
Дело в том, что у нас нет задачи сделать высоконагруженно-доступно-быстро. И хранить в памяти входящие данные точно не надо.
Мульти-мастер точно не нужен, мастер один в текущей БД (ораклЪ) и менять этот факт ничто не заставляет.
> Думаю вам надо пробовать - потратить неделю на тарантул.
> Принципиально более полного ответа вам никто не даст, только вы сами.
Спасибо, пока это всё даже не планы, а ранние прикидки. Чую, что свалят опять всё в SQL, чтобы не разбираться.
По правде может это и не столь плохо, ибо никого высоконагруза так-то нет, просто данных иерархических много...
