Масштабирование Pinterest Пользовательские таблицы шардинга и обеспечение согласованности при открытии новых шардов

Question

Так что это очень концептуальный вопрос (как бы мне не хотелось создавать миллиардное пользовательское приложение, я не думаю, что это произойдет).

Я прочитал статью в Pinterestо том, как они масштабировали свой парк MySQL несколько раз (https://medium.com/@Pinterest_Engineering/sharding-pinterest-how-we-scaled-our-mysql-fleet-3f341e96ca6f), и я до сих пор не понимаю, как они «открывают новые осколки», не затрагивая существующих пользователей.

В статье говорится, чтокаждый стол на каждом осколке, включая стол User.Поэтому я предполагаю, что когда пользователь регистрируется и ему назначается случайный шард, это должно быть сделано с помощью функции, которая всегда будет возвращать один и тот же результат независимо от количества шардов.

например, если я подпишувместе с test@example.com они могли бы использовать это электронное письмо для определения идентификатора шарда, и это должно было бы учитывать количество «открытых» шардов в настоящее время.Мое первоначальное предположение состояло в том, что они будут использовать что-то вроде модового шарда, который они упоминали позже в статье, например,

  md5($email) % number_of_shards

Но когда они откроют количество шардов, это изменит результат функции.

Тогда я подумал, что, возможно, у них есть отдельная БД для хранения чисто пользовательской информации для целей аутентификации, и это также будет содержать столбец с назначенным shard_id, но, как я уже сказал, статья подразумевает, что даже таблица пользователей находится в каждом шарде.

Есть ли у кого-нибудь еще идеи или идеи о том, как что-то подобное может работать?

Answer 1

Вы шардируете на "пользователя", правильно?Я вижу 3 основных способа разделить пользователей.

Подход по модулю к шардингу имеет большую проблему.Когда вы добавляете шард, большинству пользователей внезапно нужно перевести большинство пользователей в другой шард.

Другой крайностью (по модулю) является подход "словарь".У вас есть какой-то поиск, который говорит, на каком шарде находится каждый пользователь.С миллионами пользователей обслуживание словаря становится дорогостоящей головной болью.

Я предпочитаю гибрид:

1. Do по модулю 4096 (или какое-то достаточно большое число)
2. Используйте словарь с 4096 записями.Это сопоставляет 4096 значений с текущим числом шардов.
3. У вас есть пакет для переноса пользователей из одного шарда в другой.(Это жизненно важный компонент системы - вы будете использовать его для обновления, серьезных сбоев и т. Д., Балансировки нагрузки и т. Д.)
4. Добавление осколка включает перемещение нескольких из 4096 в новый осколок и изменениесловарь.Перемещение пользователей, вероятно, будет происходить из «самых загруженных» осколков, тем самым уменьшая давление на них.

Да, пункт 4 влияет на некоторых пользователей, но только на небольшой процент из них.Вы можете смягчить удар, выбрав для перемещения «холостых», «маленьких» или «спящих» пользователей.Это потребовало бы вычисления некоторой метрики для каждого из 4096 скоплений.