Hey guys!



In this session we're going to shed a light on the following problem.



You store your data in a database using one physical machine. OK, a couple of machines -- a master and a replica. At some point, the workload goes up and a single machine can't handle it.



As long as it is "reading" workload, you set up replicas to handle the problem. Right?



But then you get "writing" workload, and you can't stand it. OK, you shard your database across several nodes. Good point.



So you end up with a cluster of replicas and shards that grows infinitely and handles ultimate workloads. Is that the end of the story? No! There are new problems bumping into you. I'm talking about bad latency, no transactions , no stored procedures, and the huge overall cost of the solution.



What's your next move? Caching, of course. Does it cover everything above? Well, partially. Read latency -- yes. Write latency -- no. Costs -- hmm, maybe (I mean, you get rid of replicas, but shards are still there). Transactions and other database things - definitely, no.



Are you familiar with that problem? What the solution could be?



No worries, we'll cover it at our session. Come & see! :)



Schedule:



7:00 p.m. - 7:30 p.m.



Database & Caching talk. How to get every last drop of performance out of your hardware



by Dennis Anikin, CTO Email & Cloud at Mail.Ru Group



Database & caching overview



• Performance issues with traditional on-disk databases



• Issues with popular in-memory databases & caches



Use-cases overview



• MySQL + Tarantool (Mail.Ru)



• Push notifications + Tarantool



• Vertica + Tarantool (Avito)



• Hadoop + MySQL + Tarantool (MyTarget)



• REST Service + Tarantool



7:30 p.m. - 7:45 p.m.



Q&A on the talk above



7:45 p.m. - 7:50 p.m.



Coffee break



7:50 p.m. - 8:30 p.m.



A roundtable on database & caching problems



Moderator: Dennis Anikin EVP Cloud Mail.Ru Group



The main purpose of this roundtable is exchanging of experience between attendees.



Each participant is welcomed to say about they issues with database and caching or discover they own use-case. The speech is limited by time, approx. 3 minutes (depends on number of attendees). Other partiсipants can ask some questions and say some remarks after the speech.