Комментарии 18
Одна из команд в компании использовала тарантул для обновления записей в mysql, потому что mysql не справлялся с обновлением по ключам, результат превзошел все ожидания, это реально быстро.
Обновление данных в оперативе и скидывать их снапшотами в другую бд - это генеально.
Спасибо за статью! А подскажите, tarantool может хранить данные, больше чем есть оперативной памяти? Вся ли бд в единицу времени должна лежать в оперативке или данные подгружаются с диска? И есть ли сравнение по потреблению памяти для данных с конкурентами?
Если мы рассматриваем in-memory движок, то все данные должны помещаться в RAM. Иначе это уже не in-memory.
Для сценариев хранения данных больших, чем объём памяти есть несколько подходов. Можно либо воспользоваться встроенным дисковым движком на базе LSM-дерева (vinyl), либо воспользоваться подходящим внешним хранилищем, как вспомогательным, например Postgres. У Tarantool в поставке есть готовый коннектор к Postgres.
Но если мы говорим про интерактивные транзакции, то есть отдельный MVCC движок. Он позволяет выполнять в режиме serializable уже интерактивные транзакции, но придётся дополнительно обрабатывать потенциальные конфликты транзакций.
Можно подробнее расписать этот тезис:
- что подразумевается под «интерактивностью» транзакций?
- как реализовано версионирование таплов в рамках MVCC движка?
- как происходит обработка конфликтов — вручную, отдельной логикой после процессинга транзакции?
В обычных реляционных базах таблица в памяти — это не персистентное хранилище, используемое для каких-то быстрых операций.
Очень спорное суждение. Поясните его, пожалуйста.
Кооперативная многозадачность и экономия ресурсов системы за счёт отсутствия блокировок по причине исключительно однопользовательского доступа к структурам данных в памяти. Это именно то, что было реализовано?
В статье втречается термин «тапл», по контексту можно предположить, что это то же самое, что и тьюпл (tuple- кортеж)?
А как у вас реализуется кооперативная многозадачность? есть аналог Yeld или длинная задача в fiber заблокирует остальные запросы?
Каждая нода кластера содержит полную копию данных? есть возможно разделения данных по признаку и хранить в разных нодах кластера? Кластер Master-Slave или Master-Master?
Split brain syndrome - только ручное разрешения конфликтов?
Есть разница в производительности на каких системах работает server SMART или NUMA?
В чем преимущества в сравнению например с Oracle TimesTen? тоже продукт вырос из кеша. По описанию аналогично snapshot+redo log
Спасибо за вопросы.
А как у вас реализуется кооперативная многозадачность? есть аналог Yeld или длинная задача в fiber заблокирует остальные запросы?
Асинхронная операция делает yield. Такие операции: обращение в сеть, на диск, коммит транзакции.
Есть явная функция передачи управления fiber.yield().
Если задача длинная и не делает асинхронных операций или fiber.yield — она заблокирует остальные запросы.
Каждая нода кластера содержит...
Ноды могут объединятся в репликасет. В репликасете возможна топология master-slave или multimaster.
Репликасеты могут объединятся в кластер. Данные будут шардированы между репликасетами по признаку, который задаст пользователь.
только ручное разрешения конфликтов
Да
Oracle TimesTen
Выглядит по-другому, сравнить сложно
Архитектура in-memory СУБД: 10 лет опыта в одной статье