Pull to refresh

Comments 47

У редиса есть шардирование из коробки. Позволяет хранить там много данных с равномерной производительностью. А у тарантула как с горизонтальным ростом?
У вас новый шардинг уже в публичном доступе. Вот об этом была бы интересна статься. Почему от старого отказались? Какие вкусности будут в новом?
За ссылку спасибо!
А вот по ссылке выше жеж все расписано
Наверное потому, что он не совсем БД.
а остальные совсем БД что ли?
Хазелькаст предоставляет доступ к хранимой информации через объекты, реализующие стандартные интерфейсы, такие как List или Map, а не через запросы. В этой проекции любой HashMap можно назвать «базой данных», что будет очевидно не верным.
redis/memcached умеют предоставлять доступ через запросы?
В спринге вы через redisTemplate что по сути дела делаете? Фактически запрос данных. Это несколько отличается от хазелькаста, где вы работаете с переменной в которой лежат значения. По-моему разница очевидна.
Можно привести пример на C#, Python?
Спасибо.
Не пишу на С# или Python, попробуйте спросить у гугла.
Способ доступа к ПО через фреймворк языка не является характеристикой этого ПО.
Поэтому redis такая же БД, как и file.txt :)
Побенчим редиску против файла? Хотя стоп, бенчат же как раз эффективность работы с данными, так что без ПО обеспечивающего доступ не обойтись. ч0рт, как же быть?
В общем приходим к выводу: питонщик джависта не разумеет :)
И прекращаем тред.
В tarantool есть блокирование ключей? Aka cache stampede protection
Оно не требуется, поскольку база и кеш находятся в одном инстансе и, более того, работает это всё в один поток :).
Ну если я хочу использовать Tarantool как кеш сервер, а как БД есть чтото другое? Или использовать Tarantool-а только как кеш сервера не рекоменуется?
Я бы не стал использовать тарантул просто как кеш :). Он умеет намного больше, и странно этим не пользоваться.
Смена системы кеширования относительно не сложна обычна, а вот смена основной СУБД может означать переписывания большей части приложения.

Tarantool нету в AWS. Это сильно ограничивает возможность применения для многих проектов

UFO just landed and posted this here

Это просто кастомная AMIшка. Точно так же можно посоветовать apt-get install tarantool. Никакой интеграции с инфраструктурой AWS тут нет. Шардинг, репликация, метрики, alarms, autoscaling — все нужно будет настраивать самому. Сравните с тем, как организовано взаимодействие в ElasticSearch, например.


Redis/Memcached кластер на 10 инстансов внутри VPC можно поднять при помощи простого CFN темплейта за 10 минут. По этому показателю Тарантул и рядом не валялся.

UFO just landed and posted this here
Можно добавить сравнение с Apache Ignite?
Спасибо.
UFO just landed and posted this here
UFO just landed and posted this here
Не слышал. Гугл показывать только гитхаб. Исходники читать лень :) Там что-то интересное должно быть?

А что с комьюнити у Reindexer. Просто сделать что-то своё, оставив только себе же нужное, пробовали многие, но потом все равно добавляется то, что нужно людям, и без поддержки со стороны сообщества (как идейной, так и технической) редкий автор оригинальной разработки не забрасывает ее поддержку "для людей".

UFO just landed and posted this here
Дайте ссылку на телеграм-чат коммьюнити (или слак или еще куда-то)
UFO just landed and posted this here

Не завели еще таких. Но скоро заведем — под какой нибуть подходящий инфоповод :)

UFO just landed and posted this here
Обратите внимание на объектную обёртку — можно описывать схему данных, работать с базой в стиле ООП, есть поддержка миграций, синхронизация хранимок с исходным кодом и многое другое.
Например, можно просто писать классы, через аннотации указывать типы и связи сущностей.
Про эту фичу можно посмотреть в ридми: 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 работала)?

Давайте мы оценим этот объем. Можете прислать детальное описание? Лучше на email — anikin@corp.mail.ru
Из всех in-memory дб лучше переменная массива или объекта на том языке на котором пишешь, быстрее в 2-5 раз любой другой, простата и независимость точно, с остальными да если нужно масштабирование луче юзать готовые решения.
Вопросы проблем с простатой на этом ресурсе, наверное, не рассматриваются )
Sign up to leave a comment.