MySQL · MySQL 8.4
Долгое время Slack делил MySQL по workspace_id: все данные рабочего пространства — на одном шарде. С ростом крупных клиентов их шарды упёрлись в самое мощное доступное железо, хотя остальной парк был недогружен. При переезде на Vitess сообщения перешардировали по другому ключу. Сейчас Vitess обслуживает 99 % запросов Slack, пик — 2,3 млн запросов в секунду.
Представим таблицу messages (message_id, workspace_id, channel_id, user_id, ts, text). Один клиент даёт 30 % всей нагрузки на сообщения, у него 40 тысяч каналов. Почти все запросы — «последние 50 сообщений канала» и «вставить сообщение в канал».
В работе: Шардирование мессенджеров, комментариев, журналов событий — везде, где крупный арендатор может перерасти один сервер.
Источник: кейс Slack: переезд MySQL-шардов на Vitess, 2020. Условие пересказано своими словами.
По какому ключу шардировать messages?
- channel_id
- workspace_id, как раньше
- message_id (хеш)
- user_id автора
- ts (диапазоны по времени)