Abstracts for the report on Highload ++ “Experience in creating your own key / value repositories for small high-load projects”
Under the cut theses, I want to know what will be of interest from this and what to cut
The report is designed for novice architects and leading programmers. In the first part of the report there will be a review of how the modern Dating Service is designed from the inside using the example of LovePlanet.ru. The concept of a modular architecture will be proposed when a separate module is responsible for a specific task, which is implemented as an independent service or demon. What gives us such an architecture and what is the advantage over the implementation of conventional WEB pages.
One of the modules of our architecture is the Service “Storage of Preferences”, which is implemented as key / value storage 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 many other things can be found in the second part of this speech. What bicycles we had to invent and what we took already finished, as well as:
- The exchange protocol, why you chose memcached
- Expansion of the protocol and use of the native memcached client. What works and what remains as theory.
- How the storage is arranged from the inside (based on 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?
The report is designed for novice architects and leading programmers. In the first part of the report there will be a review of how the modern Dating Service is designed from the inside using the example of LovePlanet.ru. The concept of a modular architecture will be proposed when a separate module is responsible for a specific task, which is implemented as an independent service or demon. What gives us such an architecture and what is the advantage over the implementation of conventional WEB pages.
One of the modules of our architecture is the Service “Storage of Preferences”, which is implemented as key / value storage 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 many other things can be found in the second part of this speech. What bicycles we had to invent and what we took already finished, as well as:
- The exchange protocol, why you chose memcached
- Expansion of the protocol and use of the native memcached client. What works and what remains as theory.
- How the storage is arranged from the inside (based on 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?
')
Source: https://habr.com/ru/post/153667/
All Articles