Почему в tarantool\redis хранимые процедуры если не на SQL, то на Lua?

Василий Банников, ну так ты специально всякую гадость собрал. Причем с Rust я тоже сталкивался как с гадостью. Что как бы говорит о том, что в целом языков не так много странных. Ну и Delphi понятное дело не Си-подобный, да и устарел он.. А остальное - экзотика, некоторые еще и устарели тоже.

Какая in-memory база данных поддерживает триггеры во внешний мир, которых можно ждать?

Сергей Горностаев, я не понимаю, как те же брокеры могут работать, если там не триггеры и не поллинг. Как можно иначе отследить изменения в БД?

Какая in-memory база данных поддерживает триггеры во внешний мир, которых можно ждать?

Сергей Горностаев, спасибо.
(А ведь триггер был бы куда меньшим злом :) )
А как оно работает без триггеров и без поллинга? Можно ли сделать что-то нормальное, используя только тот lua, который внутри тарантула, и микросервис, скажем, на node.js, который является прослойкой между тарантулом и клиентом? Но не используя готовый брокер, а реализовав нужный функционал на lua и в микросервисе.

Какая in-memory база данных поддерживает триггеры во внешний мир, которых можно ждать?

Сергей Горностаев, ага, понял... но будет ли это лучше, чем то, что я придумал с 100 мсек :)

Какая in-memory база данных поддерживает триггеры во внешний мир, которых можно ждать?

Сергей Горностаев,

Кто рекомендует?

Это сложно найти, где я вычитал, что прям рекомендуют :)
Но вот есть штука: https://github.com/tarantool/queue
А вот компания-разработчик Tarantool пишет статью о том, как эту штуку использовать: https://habr.com/ru/company/mailru/blog/271513/
Правда, я пока понятия не имею, как эта штука работает и подойдет ли она для того, что я тут описываю... И будет ли она лучше, чем то, как я хочу сделать - просто тарантуловский select дергать каждые 100 мсек и это для каждого пользователя (у каждого свой сеанс в микросервисе на node.js), пока у него открыт клиент...

Какая in-memory база данных поддерживает триггеры во внешний мир, которых можно ждать?

Сергей Горностаев, однако Tarantool рекомендуют для создания брокеров сообщений. Да и брокер сообщений можно использовать только как брокер сообщений, он же не заменит БД. А тут есть и другие вещи, которые тоже желательно в той же БД хранить.
А почему избегают триггеров и что используют вместо них? Тот же брокер сообщений внутри себя имеет же некую свою собственную "БД", ну или попросту контейнер с данными. Разве там не триггер?

Почему в tarantool\redis хранимые процедуры если не на SQL, то на Lua?

Сергей Горностаев, это хорошая такая инструкция на тему того, как добавить в тарантул какую-нибудь мелочь :) А тут, если на то пошло, то я боюсь, что идею проще будет отвергнуть, чем смотреть все нюансы десятков тысяч строк ее реализации.

Какая in-memory база данных поддерживает триггеры во внешний мир, которых можно ждать?

Максим Федоров, я все-таки не тороплюсь с выводами типа "если мне хочется попасть в дом через окно, то надо ко всем окнам приделать лестницы, а двери не нужны"

Какая in-memory база данных поддерживает триггеры во внешний мир, которых можно ждать?

Сергей Горностаев, не выглядит эта функциональность мало востребованной.
Можно, конечно, соорудить обходной механизм, который при добавлении в очередь будет непосредственно сообщать об этом ждущему роуту. Но такое не всегда удобно, тем более с HTTP, а не WebSocket.

Почему в tarantool\redis хранимые процедуры если не на SQL, то на Lua?

ayazer,

использование тут джаваскрипта я вообще никогда не видел

Я, конечно, извиняюсь... а то, что в браузере, чем не встраиваемый скриптовый язык-то?
И да, с песочницей там все хорошо. Относительно. Ни разу не видел рабочего и современного эксплойта на JS (социальная инженерия типа "Ваш браузер устарел, скачайте вот этот троян" сюда не относится).

Почему в tarantool\redis хранимые процедуры если не на SQL, то на Lua?

Сергей Горностаев,

Нельзя. MongoDB - это документоориентированное хранилище, ориентированное на распределённость. Redis - это key-value хранилище, ориентированное на легковесность. Монга не сравнится с тарантулом по производительности и гарантиям ACID, а редис не сравнится с тарантулом по функциональности. Это разные системы с разным назначением.

Ну вот, как видишь по соседнему вопросу, функциональность у тарантула тоже че-то как-то оставляет желать лучшего.
Думаю, что я бы и в функциональность Redis ужался со своим брокером очереди сообщений, который собственно и пишу. Коль скоро самого главного (что и описано в том вопросе) в Tarantool все равно нету.
А вот про Mongo и ее плохое быстродействие... может быть. Ок, не буду рассматривать ее для своего брокера. Но тогда вообще непонятно - а в каких случаях Mongo хороша, кроме тех, когда нужна распределенность? Тот же Tarantool вполне документоориентированный со своими space'ами. А вот с посредственным быстродействием Mongo - да, сталкивался.

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

А насколько реально стороннему разработчику это реализовать? На текущем этапе развития Tarantool. И будет ли кто-то пользоваться такой версией Tarantool?

Какая in-memory база данных поддерживает триггеры во внешний мир, которых можно ждать?

А больше нигде что ли нет? Вот тебе раз. И почему? Почему этого в том же Tarantool нет?

Почему в tarantool\redis хранимые процедуры если не на SQL, то на Lua?

Сергей Горностаев,

Во-первых, а почему ВАЗ-2170 такой медленный?

А почему Python - это "таз"?

Во-вторых, может перед разработчиками CPython и V8 стоял иной класс задач и встраивание не было главной целью?

У Python и JS есть и другие интерпретаторы.

Что можно взять вместо Tarantool?

Многое, Redis можно, Mongo можно. Посмотри мой другой вопрос за сегодня. Там наглядно видно, что на простейшей задаче, требующей быстродействия, оказалось, что Tarantool не так уж и крут, а задача толкового решения на нем не имеет. Хотя в остальном в нем гораздо больше наворотов, чем в том же Redis... но не в Mongo, кстати.

И опять же, может у разработчиков Tarantool приоритеты иные, чем обеспечивать поддержку других языков в хранимках?

Не других, а какого-то одного языка, более популярного, чем Lua.

Какая виртуальная машина лучше для мак?

БЕСПЛАТНО

мак

ну как обычно

Почему в tarantool\redis хранимые процедуры если не на SQL, то на Lua?

ayazer, ну меня больше in-memory БД интересуют...

луа это вполне себе стандарт для использования в качестве скриптового языка (он для этого первоначально и создавался)

С учетом того, что я его сравниваю с JS и Python, этот аргумент звучит примерно как "что лучше, бмв или мерседес? - мерседес, потому что он автомобиль и изначально как автомобиль создавался". Как бы некая доля смысла есть, но маленькая.

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

Почему в tarantool\redis хранимые процедуры если не на SQL, то на Lua?

А почему интерпретатор Python такой огромный и медленный? А JS?
А "встраивается проще" - вообще странный аргумент... Проще вообще не создавать свою СУБД, а взять готовую. Не поверишь, но я бы так и поступил.

Как обойти капчу на selenium?

Ася, ну ты Ася)) кто тебе сказал, что такие методы вообще существуют? На то она и капча, чтобы их не было. Не считай себя самой хитрой Асей.

На чем сделать нечто похожее на PUSH-уведомления, но чтобы они приходили не в уведомления ОС, а просто в фронт-енд по ws/http?

ZB Venom, приколы? от моторолы?
А если десктоп и мобилка, а если два разных компа. Да и как опрашивать localStorage, чтобы определить, что туда вдруг что-то прилетело, по таймеру что ли... Вот если не имеешь опыта с темой - зачем пишешь?

На чем сделать нечто похожее на PUSH-уведомления, но чтобы они приходили не в уведомления ОС, а просто в фронт-енд по ws/http?

AJAX polling - это частый опрос? Но я же пишу, что хочу использовать долгий опрос (long polling). По-моему, это даже лучше.

Встречались ли вам овер-инженеры среди джунов и миддлов? Как надо с такими поступать?

Важна скорость разработки

Сомнительно заявление.
Во-первых, качество тоже важно, иначе эта скорость обернется катастрофой. Все как при езде по трассе.
Во-вторых, скорость тоже отнюдь не всегда дает выгоду! Если вы сделаете недельную задачу за сегодня, это не значит, что завтра вам дадут еще одну недельную задачу. Мешает этому многое, начиная от ритма, в котором заказчик обдумывает новые задачи и обсуждает с партнерами, и заканчивая тем, что у него просто денег не хватит оплачивать такую "молниеносность".