Комментарии 47
Tarantool нету в AWS. Это сильно ограничивает возможность применения для многих проектов
Это просто кастомная AMIшка. Точно так же можно посоветовать apt-get install tarantool. Никакой интеграции с инфраструктурой AWS тут нет. Шардинг, репликация, метрики, alarms, autoscaling — все нужно будет настраивать самому. Сравните с тем, как организовано взаимодействие в ElasticSearch, например.
Redis/Memcached кластер на 10 инстансов внутри VPC можно поднять при помощи простого CFN темплейта за 10 минут. По этому показателю Тарантул и рядом не валялся.
Спасибо.
Зачем исходники, вот статья целая была https://habrahabr.ru/post/346884/ :)
А что с комьюнити у Reindexer. Просто сделать что-то своё, оставив только себе же нужное, пробовали многие, но потом все равно добавляется то, что нужно людям, и без поддержки со стороны сообщества (как идейной, так и технической) редкий автор оригинальной разработки не забрасывает ее поддержку "для людей".
На хабре было — habrahabr.ru/post/122054
И есть на чистом РНР — github.com/tarantool-php/client
Например, можно просто писать классы, через аннотации указывать типы и связи сущностей.
Про эту фичу можно посмотреть в ридми: github.com/tarantool-php/mapper#annotation-plugin
Одна из интересных фич сервера приложений Tarantool — возможность взаимодействовать с другими, более медленными базами данных с целью кеширования информации, хранящейся в них, и тем самым ускорять их работу: это относится к Oracle, IBM DB2, MySQL, MS SQL Server и PostgreSQL.
В Tarantool эта проблема решается с помощью «умного» кеширования: обновление завершится только после успешного обновления сопряжённой БД. То есть вместо взаимодействия с двумя уровнями приложение взаимодействует только с Tarantool, который отвечает за обновление сопряжённой БД.
А можно подробнее об этом кейсе? Вот есть приложение на PHP с MySQL в качестве основного хранилища и Redis в качестве кеша. В приложении порядка 10000 разных SQL-запросов по сотне таблиц, треть из них — это чистый CRUD сущностей для бизнес-логики выбором по id и связями (джойнами) по ним же, треть — UI запросы (фильтры, сортировки, поиск по разнообразным критериям), а треть — аналитика. Основное использование Redis — кеш для CRUD операций и базовых UI-запросов по обычной схеме: для селект-запросов по id проверили запись в кеше, если есть отдали её, если нет, полезли в базу. По CUD — просто очистка кеша в основном по успешному выполнению запросов.
Бывают проблемы обычные для такой схемы, основные — множественные одинаковые запросы при прогреве кеша, плюс десинки кеша и хранилища, например из-за сетевых проблем после успешной записи данных в хранилище кеш не инвалидируется.
Как видится, Tarantool мог бы помочь в качестве умного кеша хотя бы для CRUD (UI и аналитику почти всегда можно на реплики пускать), но каков будет объём работы примерно? Перенести ~3000 запросов из приложения куда-то в Tarantool с обвязкой в несколько строк Lua, а на их месте написать ~3000 запросов на языке запросов Tarantool (или каких-то RPC сервера, типа как ISAM работала)?
Сравниваем Tarantool с Redis и Memcached