Tarantool крутой, но он прожорливый и требует знаний и тщательной настройки при релизе что в k8s, что без него + так как он написан на c и lua нужно учиться его настраивать и тратить ресурсы на изучение стека. Это интересно, безусловно, но, увы, некогда
Я бы его поставил на всю компанию, будь у меня во-первых, выделенная команда инженеров способных фуллтайм заниматься его настройкой, тюнингом и поддержкой, а, во-вторых, на несколько порядков больше нагрузки
Я чет не написал про нагрузку в статье - у нас в пике может быть до 3 RPS у всей системы и средний размер модели это 1МБ, но операций чтения/записи на порядок больше в силу архитектуры скоринга - до 10 RPS на чтение и столько же на запись - это объективно не тот порядок, ради которого нужно рассматривать большие решения вида Tarantool
ScyllaDB не подошла из-за требований по ресурсам, это Cassandra-like решение и память оно потребляет безумно (ровно как и кассандра). У них в рекомендациях к железу 4ГБ на ядро. Это хорошее производительное решение для супер больших объемов данных, а мы тут со своими крохами ни к селу, ни к городу.
А вот DragonflyDB даже хотели взять, пока не посмотрели доклад Андрея Комягина на highload и решили что Redis-like решения мы рассматривать не будем, вне зависимости от того как их поменяли (туда же ValKey, KeyDB, ArDB и прочие-прочие) - все-таки ключевые проблемы, из-за которых решено отказаться от Redis, в наследниках также присутствуют
Tarantool крутой, но он прожорливый и требует знаний и тщательной настройки при релизе что в k8s, что без него + так как он написан на c и lua нужно учиться его настраивать и тратить ресурсы на изучение стека. Это интересно, безусловно, но, увы, некогда
Я бы его поставил на всю компанию, будь у меня во-первых, выделенная команда инженеров способных фуллтайм заниматься его настройкой, тюнингом и поддержкой, а, во-вторых, на несколько порядков больше нагрузки
Я чет не написал про нагрузку в статье - у нас в пике может быть до 3 RPS у всей системы и средний размер модели это 1МБ, но операций чтения/записи на порядок больше в силу архитектуры скоринга - до 10 RPS на чтение и столько же на запись - это объективно не тот порядок, ради которого нужно рассматривать большие решения вида Tarantool
ScyllaDB не подошла из-за требований по ресурсам, это Cassandra-like решение и память оно потребляет безумно (ровно как и кассандра). У них в рекомендациях к железу 4ГБ на ядро. Это хорошее производительное решение для супер больших объемов данных, а мы тут со своими крохами ни к селу, ни к городу.
А вот DragonflyDB даже хотели взять, пока не посмотрели доклад Андрея Комягина на highload и решили что Redis-like решения мы рассматривать не будем, вне зависимости от того как их поменяли (туда же ValKey, KeyDB, ArDB и прочие-прочие) - все-таки ключевые проблемы, из-за которых решено отказаться от Redis, в наследниках также присутствуют