Когда стоит дилемма, какое DBMS решение выбрать, то приходится принимать во внимание много факторов — latency, bandwidth, ACID-complience, наличие/отсутствие server-side-scripting, возможности репликации, удобство развертывания и администрирования, наличие известных багов или maintenance window и т.д.
Я хочу рассказать лишь об одном из факторов, который имеет особенное значение на проектах с многомиллионными аудиториями — это Total Cost of Ownership или, по-простому, цена. Чем больше аудитория у проекта, тем больше эта аудитория создает нагрузку на базы данных, тем больше должно быть серверов с базами данных, тем больше финансовых затрат это требует.
Можно экстенсивно наращивать количество серверов, но до определенного предела, когда становится понятным, что далее дешевле будет внедрить новое, более производительное решение, которое позволит радикально снизить цену и количество железа.
Мой рассказ будет посвящен тому, как мы в Почте@Mail.Ru перешли на Tarantool, и как его использование сэкономило нам миллион долларов.
6. Solution: replication
APPAPP DB MasterDB Master
Update
DB SlaveDB Slave
Replication
Select
DB SlaveDB Slave
DB SlaveDB Slave
DB SlaveDB Slave
DB SlaveDB Slave
77. Look back
• Shard, replica, cache, smart cache
• Shard exists, replicaback,
• Persistent cache, replication, acid.
Now cacheisaDB
• 2 instances could be enough
78. Cache. Why not?
• Dependable, durable
• You’reon theroad to cache
• No ACID, no consistency, no
durability
• Leavecozy DB for cache
• Tarantool helps come over
• No magic, just anew tool
81. Mail.Ru Users’ Profiles
$1.2M upfront
$300K each year
128x MySQL128x MySQL 4x Tarantool4x TarantoolVS
$20K upfront
$5K each year
60 times!!!
Saved more than $1 000 000