Добротно ражеван вопрос хранимок.
Чуть не хватает примера интеграции с приложением.
Как в приложении обращаться и правильно взаимодействовать с бд/хранимкой?

Взаимодействие стоит реализовывать используя один из коннеторов, например tarantool-python:


import tarantool

server = tarantool.connect('127.0.0.1', 3331)

response = server.call('auth.registration', ('example@mail.ru', ))
# response содержит результат вызова метода registration
# [[True], ['email': 'example@mail.ru', 'code':'af045da638fd3a8e3b5f8352866c3a13']]

Подробнее вопрос взаимодействия с приложением будет рассмотрен в третьей части цикла.

На проде всё часто выглядит несколько иначе. Обвешено таймаутами, контролем ошибок коннекта/выполнения.
Нашел задание таймаута для коннектора на питоне. Не нашел на пыхе.
Будет очень кстати статья про эксплуатацию на проде с приведением всех этих моментов.
Возможно не в тему статьи, но тут говорилось про сессии и разлогинивание на стороне сервера :)

Уже в гуглгруппе вопрос задавал с год назад, повторю здесь. Сессии на тарантуле это хорошо, но для удаления по произвольному ключу надо писать хранимую процедуру в которой будет сначала space:select() и затем в цикле удаление.

Удаление не по первичному ключу может понадобится как минимум для удаления истекших сессий и возможности удаления всех сессий конкретного пользователя (что бы разлогинить на всех устройствах).

Собственно вопрос: Нет ли в планах сделать удаление записей по запросу, а не только по первичному ключу?
Что-то вроде селекта, но для удаления — params = {iterator = 'LT'}
space.index[index_name_or_id]:delete(index_key, params)

Когда столкнулся с подобной проблемой, решил ее удалением в цикле. В данной ситуации число удаляемых записей всегда небольшое (не больше числа поддерживаемых социальных сетей).


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

Зачем NoSQL базе SQL запросы? И там и там множества ведь. JSONPath работает? Если нет, то какой это NoSQL?!!!

NoSQL чаще означает NoACID
Может это не обосновано, но вообще объедение бизнес логики и БД в одном флаконе что-то мне напоминает… была в своё такая популярная коммерческая система MUMPS кажется называлась… Тоже быстро работала, только когда проекты разрастались люди начинали плакать кровавыми слезами… Но скорее всего в этом проекте уже сделаны соотвествующие вывода из прошлого?
Превратить в ад можно практически любой проект, особенно если инструменты/технологии для его реализации выбраны неправильно и не учитывают дальнейшего роста продукта.
В этом смысле тарантул со своей кооперативной многозадачностью не дает расслабиться с самого начала и заставляет думать о том как параллелить базу и вычисления еще на этапе проектирования.

Что касается самой статьи и разбираемого в ней модуля, то здесь как раз и показана хорошая практика написания приложений для тарантула:
  • инстанцирование приложения, те можно на одной ноде тарантула запустить сразу несколько вариантов апликейшена с разными настройками;
  • в коде есть простая схема данных, облегчающая работу с таплами;
  • внутреннее устройство приложения скрыто от внешних глаз, а наружу отдаются только ручки, необходимые для работы клиентов;
  • конфиг приложения можно вынести в отдельный файл конфигурации, чтобы для изменений настроек не надо было залезать в луашный код;
  • библиотека покрыта тестами;

Красиво. Я немного начал писать на луа только из-за тарантула.
Собственно весь синтаксис я выковырял из татантутовского туториала.


user_tuple = user.create({
            [user.EMAIL] = email,
            [user.TYPE] = user.COMMON_TYPE,
            [user.IS_ACTIVE] = false,
        })

Это ваще круть, у меня по всему коду user[1], user[121] и в отдельных файлах спеки какой номер у какого поля.
Так и хочется спросить — где вы были раньше )))

Ориентация на Lua обозначило печальный тренд, который будет сохранятся в tnt и дальше. Скорее всего мы не увидим jsonnet подобных систем когда код является частью данных, а не наоборот. Именно в этом истинный смысл хранимости и реактивности. Точка, точка, два крючочка. Это уже проходили. Что мы еще не увидим? Мы не увидим систем с гибким расширением ядра плагинами и работы с помощью перепрограммируемых запросов, а не жёстких методов. Это важно для проектирования, адаптирования и тестирования систем без переписывания значительной части кода. Но программистов считающих, что tnt "круть" достаточно. Поэтому фронт работ для них предопределён… В конце концов какая разница за, что платится бабло. Главное, что оно платится.
Стоит отметить и сильные стороны tnt. Это безусловно мультизадачность, использование MsgPack. и механизма копирования при записи COW. Остальным смело можно пренебречь.

>сконфигурировать и запустить сервер методом box.cfg
вот тут бы отдельный материал, с указанием оптимальных вариантов под 1,7 и 1,8

Вышла вторая часть цикла: https://habrahabr.ru/company/mailru/blog/336648/

Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.