Рандомизирующая база данных для вставки
Вечером все, я недавно прочитал следующий пост в блоге о шардинге в Pinterest, и я думаю, что там есть кое-что отличное https://engineering.pinterest.com/blog/sharding-pinterest-how-we-scaled-our-mysql-fleet
В чем я не уверен, так это в том, как лучше всего решить, куда следует добавить нового пользователя.
Так что для тех, кто не знает или не удосужился прочитать вышеупомянутую статью, Pinterest имеет несколько осколков, каждый из которых имеет несколько баз данных. Они генерируют идентификаторы для объектов на основе 64-битного сдвига, который определяет шард, тип объекта (пользователь, пин-код и т. Д.) Для определения таблицы и локального идентификатора автоинкремента для рассматриваемого объекта. Теперь они пытаются поместить булавки и т. Д. В ту же базу данных, что и «доска», на которой они находятся. Но для совершенно нового объекта, что будет лучшим способом определения «осколка», на котором он живет?
Для пользователей, которые входят через Facebook, они используют модуль, например
shard = md5(“1.2.3.4") % 4096 //4096 is the number of shards
Но если бы у меня была простая форма регистрации по электронной почте / паролю, как вы думаете, использование подобного подхода к адресу электронной почты сработало бы для разработки начального шарда? Я бы предположил, что в этом случае это будет электронная почта, иначе у них не будет возможности узнать, с какой базой данных проверять учетные данные. Кроме того, я знаю, что это сообщение от 2015 года, поэтому оно не слишком старое, и вычислительная мощность быстро меняется, но будет ли лучший вариант, чем использовать md5 здесь? Я знаю, что вероятность столкновения незначительна — тем более, что мы здесь говорим о хешировании адреса электронной почты, но стоит ли использовать другой алгоритм? Я в основном заинтересован в том, как определить осколок здесь и решить, как к нему вернуться (поэтому я думаю, что это должен быть адрес электронной почты)
Надеюсь, что все это имеет смысл!
(p.s не воспринял это с тегом Pinterest, так как похоже, что это только для api dev, но если кто-то думает, что вопрос может стать лучше, то не стесняйтесь добавлять его)
Решение
При использовании MD5 для определения осколка нет риска столкновений: если столкновения происходят, то они просто попадают в тот же осколок. MD5 не является ключом в этом осколке (так что именно здесь устраняется риск столкновения).
Основная проблема в этом методе сегментов заключается в том, что количество сегментов является фиксированным, поэтому в конечном итоге может возникнуть проблема с производительностью (перераспределение работающей среды является непростым, поэтому в этом случае вы по-прежнему зависите от более быстрых компьютеров, если есть больший рост, чем ожидалось).
Другие решения
Других решений пока нет …