Комментарии 23
.
Деплоя с конфигом явно не хватало. А как миграции происходят. Например, я запускаю инстанс в докере и хочу добавить индекс. Просто меняю конфиг и дергаю какую-то ручку? Или все же миграции нужно запускать руками в виде скриптов?
замечательная новость, вы большие молодцы!
есть ли планы по выпуску актуального докер образа?
пока что на докер хабе только предыдущие релизы видны
докеры появятся в самое ближайшее время
а насколько ближайшее? хотя бы примерно.
хочется уже погонять в тестовом окружении :)
не хочу показаться назойливым, но почти месяц прошёл, а докер образ так и не появился. когда примерно планируете собрать?
Оттранслировал ваш вопрос людям, которые ближе всего к этому делу, ответят - сообщу о результатах :)
Говорят залили для x86 уже, проверяйте.
да, вижу полчаса назад появился, спасибо!
https://hub.docker.com/layers/tarantool/tarantool/3.0/images/sha256-d10025d9423bfd418a920047d58518b6968a3f893a65d4e056085dfa06fbd486
Во времена моей работы в ВТБ от Тарантула плевались, а потом и вовсе отказались. Надеюсь, сейчас ситуация исправилась
Не понимаю почему нужно создавать какие-то сценарии на Lua и зачем это делать в принципе. Почему нельзя сделать нормальный сетевой API? Существует целый DDL и непонятно чем он плох. Поднял сотню другую экземпляров простучался каким-то менеджером он прошелся и настроил все мигграции, связал их всех в группы и т.д. Тут же по сети опросил статистику. Перетаскивание на сторону DevOps-ов схем данных выглдяит как какая-то попытка скинуть задачу по настройке данных. Короче непонятна цель этого всего. Берем всем понятный Redis на сколько помню там тоже есть Lua. Хотим отправляем код по сети он отрабатывает выплевывает результат. Так же с PostgreSQL хотим создаем хранимку отправляем код запускаем получаем результат. В чем профит делать это на инстрансе?
Не понимаю почему нужно создавать какие-то сценарии на Lua и зачем это делать в принципе.
Существует два подхода к API.
Дать, собственно API. Этот подход имеет следующий недостаток: по мере развития API приходится расширять дополнительными запросами. Если Вы посмотрите на Redis, который Вы упоминаете, то увидите, что у него 432 API-запроса в настоящее время документировано.
Дать минималистичный API и язык, который позволит делать что-то сложное.
Tarantool пошёл по второму пути (Redis, как сказано выше - по первому).
Увы, если составлять список плюсов и минусов к каждому подходу, то список минусов будет не пуст и в одном и другом случае.
Насчёт простоты изучения приведу пример из совсем другой области (чтобы никто не мог сказать, что я о конкурентах плохо что-то говорю и это не показалось рекламой).
Итак, вот у нас был SysV init. Чтобы им пользоваться нужно было знать язык программирования bash. Вообще, как по мне, bash - простой язык: пяток стандартных конструкций if, case, for и while, возможность определить функцию и с десяток стандартных линуксовых команд которые можно использовать везде (всякие ls, pidof, truncate и так далее).
Долгое время некоторые пользователи ныли: "не хотим учить bash"
В итоге для них сделали systemd (по аналогии с API - перешли к безъязыковому API).
Что получилось?
В systemd юните можно написать 1525 уникальных директив
Понимаете? Тыща пятьсот двадцать пять ключевых слов!
Update: И это я посмотрел свою Linux. Сунулся на сайт freedesktop, там уже почти 1700.
(Я про API редиса выше писал, у него - 432 API метода)
Да, декларативный язык с виду кажется проще, но
Писать на таком языке без справочника под рукой нельзя (на bash - можно)
При этом справочник нужен только категорийный ибо пользователь для поиска инструкций будет использовать нечётко сформулированные запросы "мне нужна какая-то вот такая фиговина" (которую на bash, как правило - 10-50 строк изобразить)
Выучить bash ИМХО можно за примерно 1 день и он пригодится не только в init
systemd-скрипты всё равно без bash не обходятся, а там где bash "хочется всё же избежать" начинают встраивать в язык разнообразные шаблонные подстановки
Нет, я не говорю, что способ A однозначно лучше/хуже способа B (хотя по мне SysV init именно однозначно лучше). Я говорю о том, что серебряной пули, увы нет ни на той дороге, ни на этой. Была бы - и спорить было бы не о чем.
Слой SystemD срезает типовые сценарии старта сервиса и делает анализ типового сервиса проще. Теперь мы имеем пару десятков директив (библиотеку) причем строго классифицированную. Можно конечно передать управление сценариям на Bash по желанию, но вместо этого сейчас создают все новые и новые директивы создавая все более интересную гидру.
Что касаемо тарантула, так тут так же API может быть таким же из дюжены вызовов на типовых структурах данных, но можно пойти ниже и дать некоторый Bash подобный Lua и предоставить доступ из сценариев к типовым API вызовам (создании схемы и т.д.) и позволить пользователю перетащить туда всю свою логику приложения.
Почему эти сценарии не разрешить передавать по сети? Скажем старт сервиса просто предоставляет API, который уже может выполнить некоторую хранимку на Lua. Зачем в это вовлекать системных админимтратров, систему оркестратрации файлов и т.д. Похоже что просто перекладывают работу между отделами с оджной головы на другую.
Почему эти сценарии не разрешить передавать по сети? Скажем старт
сервиса просто предоставляет API, который уже может выполнить некоторую
хранимку на Lua.
возможно, вы удивитесь, но такой механизм есть в Тарантул
о нем даже когда-то была статья на хабр, но потом статью удалили
но оригинал остался здесь
https://unera.net/all/2018/04/04/tarantool-session-storage.html
Да, декларативный язык с виду кажется проще
Зато он универсальный для всех инсталляций. Приходишь в другой проект — а там те же директивы. А у скриптинга в другом проекте так, как написали, стили другие, наименования другие, логика другая. Сидишь, разбираешься. Но это так, комментарий, я тоже согласен что серебряной пули нет.
Отзыв о Тарантуле из топ3 банка РФ
Tarantool 3.0