Лямбды в сэндбоксе

[ermouth]

В начале декабря 2016 я писáл про песочницу для лямбд. Оно у нас взлетело на днях, и я нарадоваться не могу на удобство концепта.

В самом деле эта песочница – просто расширение концепта дизайн-документов в CouchDB. Один из первых кривых эскизов выглядел так:

Дизайн-документы в CouchDB – специальные документы, в которых хранятся не (не только) данные, а код, обычно map-reduce функций и фильтр-функций репликации. Каждый дизайн-документ исполняется в отдельном инстансе JS-энджина, то-есть в отдельном процессе.

Первый раз я этот концепт расширил, дополнив список функций раутером – он также хранится в дизайн-документах и тоже, как и map-reduce, js-функция. JS-rewrite (так это называется) теперь встроенная фича CouchDB 2.0. У меня JS-rewrite используется в бою, вот тут можно почитать, например.

Теперь мы этот концепт ещё расширили и дополнили всю эту кухню хуками.

Хуки как концепт – это упрощённая калька с Amazon Lambda. То-есть, по событиям обновления данных в БД выборочно запускаются функции, которые, в отличие от мап-редьюса и рерайта, могут быть асинхронными и могут произвольно читать из базы.

Писать в базу во время исполнения хуки не могут, список доков на сохранение – результат ресолва промиса хука. То-есть, документы пишутся в БД только когда хук завершился, а не во время его работы. Такой подход позволяет резко уменьшить вероятность рэйсов и inconsistency в данных.

Также хукам могут предоставляться (раздельно каждому через ключи в конфиге CouchDB) права на специальный функционал – отправку почты, СМС, возможность ходить в сеть и тп. Если исходный код или права доступа для хука меняются, хук принудительно перезапускается по-горячему.

В сущности, хуки совместно с потоком обновлений документов в БД образуют message queues, причём мессиджи – это просто обновлённые документы в БД.

Это всё, конечно, работает вне CouchDB, потому что тут без node.js никак – встроенный в CouchDB Spidermonkey бедноват для такой задачи. Тем не менее, оно плотно с CouchDB интегрировано и вокруг хуков воссоздаётся окружение очень близкое к нативной CouchDB.

Всё это писалось как неспециализированное решение, поэтому как закончим проект – заопенсорцим эту красоту.

Comments

[grayscaler.livejournal.com]

По описанию больше похоже на кальку с триггеров в SQL-серверах.

[ermouth.livejournal.com]

На noSQL сиквельные решения калькой вообще не переносятся ) Сходство тут внешнее.

Триггеры исполняются внутри транзакции, хуки принципиально нетранзакционны и асинхронны (это например значит невозможность хуков типа триггеров before update).

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

Ещё хук не обязательно должен сидеть на локальной БД, он может слушать удалённую – то-есть хуки скэйлятся независимо от БД.