Вопрос с собеседования · System design

Данные шардированы по хешу от идентификатора клиента. Несколько крупных клиентов дают около 80% нагрузки, и она приходится на один шард. Что здесь поможет?

SeniorМасштабирование
Ещё спрашивают так:
  • Что делать, если один шард перегружен крупным клиентом?
Коротко

Перекос создаёт сам ключ: данные крупного клиента по определению в одном шарде. Добавление шардов не поможет — лечат гранулярностью ключа и выделением тяжёлых клиентов.

  • Составной ключ: клиент + второе измерение (период, регион, id сущности)
  • Тяжёлых клиентов — в отдельные шарды через справочник
  • Для горячего чтения — кэш и реплики, для записи — шардированные счётчики

А ещё Хеш выравнивает ключи, но не нагрузку на ключ

Подробно

Хеширование выравнивает распределение ключей, но не распределение нагрузки по ключам: если один клиент генерирует пятую часть трафика, его данные всё равно окажутся на одном шарде, сколько бы шардов ни было. Поэтому удвоение числа шардов ничего не меняет — оно лишь дробит и без того равномерную часть. Рабочих подходов два, и обычно их сочетают: сделать ключ составным, добавив к клиенту второе измерение (период, регион, идентификатор сущности), чтобы данные крупного клиента распределялись по нескольким шардам, и вынести самых тяжёлых клиентов на отдельные шарды или в отдельный кластер, где их можно масштабировать независимо. Распределение по кругу разрушает локальность: любой запрос по клиенту превратится в обход всех шардов, а задержка станет равна самому медленному из них. Реплика на чтение снимает часть чтений, но не помогает записи и не устраняет причину перекоса — это смягчение симптома, а не решение.

Что хотят услышать

  • Почему хеширование не спасает от тяжёлого ключа.
  • Составной ключ и выделение крупных клиентов.
  • Почему увеличение числа шардов бесполезно.

Частые ошибки

  • Считать, что равномерное хеширование ключей означает равномерную нагрузку.
  • Решать перекос увеличением числа шардов.

Проверьте себя

Один верный вариант. Подумайте, потом откройте ответ.

Показать варианты и ответ
  • ✗Удвоить число шардов — нагрузка распределится равномернее
  • ✗Распределять новые записи по шардам по кругу, не привязываясь к клиенту
  • ✗Добавить к горячему шарду несколько реплик на чтение — они снимут весь перекос нагрузки
  • ✓Дробить ключ шардирования (клиент + измерение) и вынести крупных клиентов отдельно

Что спросят дальше

  • Как перевести действующую систему на новый ключ шардирования без простоя?
  • Чем плох запрос, требующий обхода всех шардов?

Разбор темы

Связанные вопросы

Партнёр платформы

Разбор собеседования с sotto

После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.

Разбор собеседования