Вывод #5: Memcached Plugin жив (но пока только в MySQL 8x)
Последний, 5й вывод, который я сделал после прошлогоднего тестирования, касается эко-системы MySQL. Поскольку она сейчас не очень популярна в РФ, напишу кратко.
В MySQL удачно сделана “слоеная” структура СУБД , которая позволяет полноценно делать pluggable storage engines. Поэтому в свое время в MySQL оказалось так много разных прикольных движков: помимо основного транзакционного ACID-движка InnoDB есть 2 других, интересных для нашей кеш-нагрузки: HEAP (он же Memory) и Memcached Plugin. Вообще в MySQL был миллион разных движков: даже Pinba (до сих пор самая крутая штука для backend observability, которую я не видел ни у кого) - тоже была сделана в виде движка MySQL.
Два последних мы потестили на кеш-нагрузке, и оказалось, что Memcached plugin не только жив, но и прекрасно работает, показывает отличную производительность при большом количестве одновременных соединений (см. слайды, ссылка ниже).
HEAP же наоборот немного разочаровал: показывая очень хорошие результаты для low concurrency workloads он быстро “сдувается” и показывает невысокую производительность на high concurrency – скорее всего кто-то где-то намудрил с блокировками. Наверное это можно обойти, реализовав что-то типа хэш-слотов и разбив ключи по разным inmemory-таблицам, но в целом это костыль, и мало ли что ещё вылезет.
Кстати, HEAP engine иногда прямо вот очень нас спасал в Badoo, так что учитывайте эту особенность, если вы тоже его используете.
Для справки:
- Исследование PostgreSQL/MySQL/Redis/Valkey/Memcached (HighLoad MSK-2024)
- Вывод #1 (Робкое напоминание о железе и гибридном подходе)
- Вывод #2 (PostgreSQL “сгладил” родовую травму)
- Вывод #3 (Valkey “сгладил” родовую травму Redis)
- Вывод #4 (MySQL, и PosgreSQL легко вывозят “простые” 1.000.000 RPS)
Последний, 5й вывод, который я сделал после прошлогоднего тестирования, касается эко-системы MySQL. Поскольку она сейчас не очень популярна в РФ, напишу кратко.
В MySQL удачно сделана “слоеная” структура СУБД , которая позволяет полноценно делать pluggable storage engines. Поэтому в свое время в MySQL оказалось так много разных прикольных движков: помимо основного транзакционного ACID-движка InnoDB есть 2 других, интересных для нашей кеш-нагрузки: HEAP (он же Memory) и Memcached Plugin. Вообще в MySQL был миллион разных движков: даже Pinba (до сих пор самая крутая штука для backend observability, которую я не видел ни у кого) - тоже была сделана в виде движка MySQL.
Два последних мы потестили на кеш-нагрузке, и оказалось, что Memcached plugin не только жив, но и прекрасно работает, показывает отличную производительность при большом количестве одновременных соединений (см. слайды, ссылка ниже).
HEAP же наоборот немного разочаровал: показывая очень хорошие результаты для low concurrency workloads он быстро “сдувается” и показывает невысокую производительность на high concurrency – скорее всего кто-то где-то намудрил с блокировками. Наверное это можно обойти, реализовав что-то типа хэш-слотов и разбив ключи по разным inmemory-таблицам, но в целом это костыль, и мало ли что ещё вылезет.
Кстати, HEAP engine иногда прямо вот очень нас спасал в Badoo, так что учитывайте эту особенность, если вы тоже его используете.
Для справки:
- Исследование PostgreSQL/MySQL/Redis/Valkey/Memcached (HighLoad MSK-2024)
- Вывод #1 (Робкое напоминание о железе и гибридном подходе)
- Вывод #2 (PostgreSQL “сгладил” родовую травму)
- Вывод #3 (Valkey “сгладил” родовую травму Redis)
- Вывод #4 (MySQL, и PosgreSQL легко вывозят “простые” 1.000.000 RPS)