Какая in-memory база данных поддерживает триггеры во внешний мир, которых можно ждать?
Собственно, требования такие:
1. Чтобы была in-memory.
2. Чтобы поддерживала триггеры вообще. Тут вроде все просто. Да хоть Tarantool.
3. Чтобы триггеры можно было опрашивать извне. То есть пусть не все драйвера (клиентские библиотеки), но некоторые из них должны поддерживать эти триггеры. Чтобы микросервис, использующий эту БД, мог повесить callback на какую-то таблицу - и он бы вызвался, когда в таблицу добавятся данные.
И вот с этим пунктом уже начинается жесткий геморрой. Тот же Tarantool - триггеры-то есть, а вот чтобы какой-то драйвер их пробрасывал вовне, я ничего не нашел абсолютно, кроме одной ишью к одному из драйверов, где разработчик отвечает, что подключение в библиотеке реализовано по сеансовому принципу и поэтому триггеры наружу не поддерживаются и никогда не будут.
4. И не просто опрашивать извне, а чтобы можно было ждать аля await, когда сработает триггер. Допустим, в БД у нас некая очередь, которая иногда пополняется. А в микросервисе есть роут, который опрашивается клиентом по принципу HTTP long polling. Клиент делает запрос, роут вешает триггер... и ждет await'ом, пока триггер не сработает. А как сработает - возвращает данные клиенту, а очередь чистит. И тогда клиент заново делает запрос и все повторяется.
На мой взгляд это вполне логичная идея и даже странно, как это in-memory БД в 2021 году может такого не иметь.
Однако, в том же хваленом Tarantool я не нашел ничего лучшего для этой ситуации, кроме как тупо опрашивать очередь select'ами каждые N*100 мсек. При том, что сами триггеры-то в БД есть.
даже странно, как это in-memory БД в 2021 году может такого не иметь.
Вы нашли нехватку в софте — ваш час для своего проекта и популярности. Весь софт не купленный — сделан усердием людей и компаний и оплачен личным временем и деньгами. Вы можете внести вклад в это
Максим Федоров, я все-таки не тороплюсь с выводами типа "если мне хочется попасть в дом через окно, то надо ко всем окнам приделать лестницы, а двери не нужны"
beem7, я не разработчик Tarantool, не знаю. Может у этого есть инженерные препятствия в рамках выбранного архитектурного подхода, может это мало востребованная функциональность, а может что-то ещё.
Сергей Горностаев, не выглядит эта функциональность мало востребованной.
Можно, конечно, соорудить обходной механизм, который при добавлении в очередь будет непосредственно сообщать об этом ждущему роуту. Но такое не всегда удобно, тем более с HTTP, а не WebSocket.
Сергей Горностаев, однако Tarantool рекомендуют для создания брокеров сообщений. Да и брокер сообщений можно использовать только как брокер сообщений, он же не заменит БД. А тут есть и другие вещи, которые тоже желательно в той же БД хранить.
А почему избегают триггеров и что используют вместо них? Тот же брокер сообщений внутри себя имеет же некую свою собственную "БД", ну или попросту контейнер с данными. Разве там не триггер?
Это сложно найти, где я вычитал, что прям рекомендуют :)
Но вот есть штука: https://github.com/tarantool/queue
А вот компания-разработчик Tarantool пишет статью о том, как эту штуку использовать: https://habr.com/ru/company/mailru/blog/271513/
Правда, я пока понятия не имею, как эта штука работает и подойдет ли она для того, что я тут описываю... И будет ли она лучше, чем то, как я хочу сделать - просто тарантуловский select дергать каждые 100 мсек и это для каждого пользователя (у каждого свой сеанс в микросервисе на node.js), пока у него открыт клиент...
Сергей Горностаев, спасибо.
(А ведь триггер был бы куда меньшим злом :) )
А как оно работает без триггеров и без поллинга? Можно ли сделать что-то нормальное, используя только тот lua, который внутри тарантула, и микросервис, скажем, на node.js, который является прослойкой между тарантулом и клиентом? Но не используя готовый брокер, а реализовав нужный функционал на lua и в микросервисе.
Средний
