в статье будет написано как создавать высокопроизводительный код, выполняемый на стороне сервера Tarantool в основном потоке сервера - т.е. рядом с данными.
А как у вас реализуется кооперативная многозадачность? есть аналог Yeld или длинная задача в fiber заблокирует остальные запросы?
Асинхронная операция делает yield. Такие операции: обращение в сеть, на диск, коммит транзакции. Есть явная функция передачи управления fiber.yield(). Если задача длинная и не делает асинхронных операций или fiber.yield — она заблокирует остальные запросы.
Каждая нода кластера содержит...
Ноды могут объединятся в репликасет. В репликасете возможна топология master-slave или multimaster. Репликасеты могут объединятся в кластер. Данные будут шардированы между репликасетами по признаку, который задаст пользователь.
Кстати да.
Но есть ещё ограничение: нет ролбека в случае, если реплик мы не дождались. Ролбек можно конечно делать на апп уровне, но тогда может быть уже проще искать хранилище с полностью синхронной репликацией.
Согласен, хотя facebook выстрелил (но оно скорее нейтральное).
У Тарантула есть «Cartridge» для построение приложений. Это название может оказаться более подходящим.
Redis fork механизм выполняет консистентный снапшот, потому что используется механизм OS copy-on-write.
Tarantool механизм также выполняет консистентный снапшот, потому что используется внутренний механизм read view.
Я не уверен, что это возможно. В протоколе же msgpack. msgpack с динамической типизацей.
Только если придумать парсер протокола на захардкоженной схеме и перенести ответственность на пользователя коннектора, но я думаю, что авторы библиотек не любят идти на такие риски.
Да, типы данных в статье представлены куце. В Redis и Tarantool они немного ортогональны друг другу. В плагины залазить тоже пока что сложно. Надо подумоть над какими-то пересекающимися кейсами и правильным их сравнением.
Спасибо за разъяснения, но их сложно соотнести конкретно с Redis и Tarantool.
Данные там живут ровно до момента выключения питания.
И Redis и Tarantool имеют механизм записи всех транзакций в журнал прежде чем сгенерировать ответ клиентскому приложению.
Если его сохранять часто при больших объемах данных и однопоточной архитектуре, то от производительности останется пшик.
И Redis и Tarantool периодически неблокирующе сохраняют снапшот in-memory данных. Redis с помощью fork, Tarantool с помощью read view.
in-memory архитектура хранит (не кеширует) сразу все данные и индексы в памяти, тем самым избавляясь от механизма кеширования/вытеснения страниц данных с диска/на диск. Какие именно данные уже зависит от архитектуры хранения конкретной БД.
Например, вы можете установить Tarantool и воспользоваться SQL, и соответствующими структурами как в традиционных РСУБД.
С какой точки зрения?
Спасибо)
Это так, да. В статье решил минимизировать Lua, чтобы у бекендеров не складывалось впечатление что Tarantool == Lua.
Создаем высоконагруженное приложение на Tarantool
Поапдейтил статью
okay(
Спасибо за вопросы.
Асинхронная операция делает yield. Такие операции: обращение в сеть, на диск, коммит транзакции.
Есть явная функция передачи управления
fiber.yield()
.Если задача длинная и не делает асинхронных операций или fiber.yield — она заблокирует остальные запросы.
Ноды могут объединятся в репликасет. В репликасете возможна топология master-slave или multimaster.
Репликасеты могут объединятся в кластер. Данные будут шардированы между репликасетами по признаку, который задаст пользователь.
Да
Выглядит по-другому, сравнить сложно
1млн хешей (миллиарды долго ждать)
redis_test.go
tarantool
tarantool>
tarantool_test.go
Тесты
go test -cpu 12 -test.bench .
redis
tarantool вместе со вторичными индексами
Вывод:
Я в лоб накидал схему на Redis и Tarantool:
Два insert-а в Redis
Один insert в Tarantool
redis_test.go
tarantool
tarantool>
tarantool_test.go
Тесты
go test -cpu 12 -test.bench . -test.benchtime 10s
Вывод:
В Redis приходится делать два инсерта.
В Tarantool один, и Tarantool поэтому быстрее.
Такой вид задачи и в Redis и в Tarantool удобнее решать через две таблицы:
То есть суть сведётся к предыдущему тесту
И Redis и Tarantool такое умеют из коробки. Синтаксис Redis попроще, Tarantool более общий
tarantool>
redis_test.go
tarantool_test.go
Запуск на 10 секунд на 12 потоков
Результаты примерно равны
У Redis для того, чтобы не доставать запись, существуют разные операции для таких вот структур данных
У Tarantool, чтобы не доставать данные, есть операции update,upsert. А если их не хватит то хранимки на LuaJIT.
Такие механизмы в redis, tarantool решаются способами: или денормализацией, или логикой на аппсервере, или хранимыми процедурами
Не совсем понимаю как эти действия применить к redis и wait и не получить грязные чтения
Ролбек нужен, чтобы откатить данные, которые на лидере закомитились.
Кстати да.
Но есть ещё ограничение: нет ролбека в случае, если реплик мы не дождались. Ролбек можно конечно делать на апп уровне, но тогда может быть уже проще искать хранилище с полностью синхронной репликацией.
http://antirez.com/news/66
Согласен, хотя facebook выстрелил (но оно скорее нейтральное).
У Тарантула есть «Cartridge» для построение приложений. Это название может оказаться более подходящим.
А Микрософт исправлились и выпустили XboX )
Redis fork механизм выполняет консистентный снапшот, потому что используется механизм OS copy-on-write.
Tarantool механизм также выполняет консистентный снапшот, потому что используется внутренний механизм read view.
Я не уверен, что это возможно. В протоколе же msgpack. msgpack с динамической типизацей.
Только если придумать парсер протокола на захардкоженной схеме и перенести ответственность на пользователя коннектора, но я думаю, что авторы библиотек не любят идти на такие риски.
Да, типы данных в статье представлены куце. В Redis и Tarantool они немного ортогональны друг другу. В плагины залазить тоже пока что сложно. Надо подумоть над какими-то пересекающимися кейсами и правильным их сравнением.
Спасибо за разъяснения, но их сложно соотнести конкретно с Redis и Tarantool.
in-memory архитектура хранит (не кеширует) сразу все данные и индексы в памяти, тем самым избавляясь от механизма кеширования/вытеснения страниц данных с диска/на диск. Какие именно данные уже зависит от архитектуры хранения конкретной БД.
Например, вы можете установить Tarantool и воспользоваться SQL, и соответствующими структурами как в традиционных РСУБД.
https://www.tarantool.io/en/doc/latest/reference/reference_sql/sql_beginners_guide/
Команда wait в Redis и аналог в Tarantool — это «частично» синхронная репликация.
Представим:
В этой ситуации у нас появляются грязные чтения. Синхронная репликация в этом плане работает лучше.
Титанически практический, на мой взгляд, труд об этом можно прочитать в этой статье:
https://habr.com/ru/company/mailru/blog/540446/
Тогда похоже на timeseries (отдельный модуль)
https://oss.redislabs.com/redistimeseries/commands/