October 5, 2012 at 02:14Abstracts for the report on Highload ++ “Experience in creating your own key / value repositories for small highly loaded projects”
Under the cat theses, I want to know what will arouse interest and what to cut. The
report is designed for aspiring architects and leading programmers. The first part of the report will review how the modern Dating Service from the inside is structured using LovePlanet.ru as an example. The concept of modular architecture will be proposed when a separate module is responsible for a specific task, which is implemented as an independent service or daemon. What gives us such an architecture and what is the advantage over the execution of ordinary WEB pages.
One of the modules of our architecture is the “Preferences Storage” Service, which is implemented as a key / value store with additional logic. Why did we have to create our own NoSQL storage, why didn't memcached, membase, redis, tarantool or MongoDB come up? This and much more can be found in the second part of this speech. What bicycles we had to invent and what we took ready-made, as well as:
- Exchange protocol, why we chose memcached
- Extension of the protocol and use of the native memcached client. What works and what remains theory.
- How the storage is arranged inside (based on the key / value Hash & Tree), you will have to learn a little boring theory to understand how and why to tune the storage.
- How we organized the monitoring.
- What problems did you encounter when switching from memcached to your own storage?
report is designed for aspiring architects and leading programmers. The first part of the report will review how the modern Dating Service from the inside is structured using LovePlanet.ru as an example. The concept of modular architecture will be proposed when a separate module is responsible for a specific task, which is implemented as an independent service or daemon. What gives us such an architecture and what is the advantage over the execution of ordinary WEB pages.
One of the modules of our architecture is the “Preferences Storage” Service, which is implemented as a key / value store with additional logic. Why did we have to create our own NoSQL storage, why didn't memcached, membase, redis, tarantool or MongoDB come up? This and much more can be found in the second part of this speech. What bicycles we had to invent and what we took ready-made, as well as:
- Exchange protocol, why we chose memcached
- Extension of the protocol and use of the native memcached client. What works and what remains theory.
- How the storage is arranged inside (based on the key / value Hash & Tree), you will have to learn a little boring theory to understand how and why to tune the storage.
- How we organized the monitoring.
- What problems did you encounter when switching from memcached to your own storage?