"Sharding - patterns & antipatterns". Доклад Алексея Рыбака (Badoo) и Константина Осипова (Mail.ru)

Editor's Notes

• #3: Если мы будем обсуждать тему за пивом, то шардинг будем обсуждать в широком смысле: и мы одновременно поднимем кучу других тем: как выбрать ключ по которому шарить, собственно шардинг, как выбрать функцию шардинга, то есть алгоритм разбиения данных по серверам как поддерживать систему: решардить данные при добавлении нод или замене выбывших DDL, то есть обслуживание схемы данных и эволюция схемы данных распаралеливание запрсоов (запрашивать данные с нескольких нод, менять данные консистентно и т.д. Сегодня мы сфокусируемся на одной области, чтобы попытаться раскрыть её.
• #4: То есть, мы смотрим конкретно на тему шардинга. Какие тут главные вопросы? Мы утверждаем, что это: то как мы разбиваем данные на кластер - функция шардинга как мы находин нужный при запросах, то есть адресация и роутинга как всем этим управлять, т.е. добавлять новые ноды
• #5: Шардинг функция почему мы об этом говорим сначала Всё три части взаимосвязаны, но естественно когда данные перестают помещаться на одну машину, первое о чём мы думаем, это как их поделить. И это принципиальный вопрос - поделишь - получишь неработоспособную архитектуру, дорогую подддержку на долгие годы вперёд (т.к. downtime недопустим)
• #6: Во-первых, имейте в виду, что размер объекта должын быть достаточно мал, чтобы шардинг был равномерным (тебе не повезло, ты на шарде с Джастином Бибером). Во-вторых, часто оказывается, что для определенных случаев вам либо нужно постоянно делать запросы к разным нодам, либо дублировать данные. Не бойтесь дублировать данные. В этом мире у нормальных форм не такая ценность, как в теории, забейте на нормальные формы, постройте всё вокруг сценария использования данных. Наконец, может оказаться, что размер ключа - это половина размера объекта, поэтому совершенно не обязательно ключ должен храниться в самих данных.
• #7: Давайте рассмотрим примеры. Что скоре всего имеет маленький размер и размажется равномерно? Сессия, заказ. А данные пользователя? Уже не во всех случаях (комментарии к постам Джастина Бибера, но есть нюансы - если в соцсети по нескольку джастинов биберов на шард, то ок). Равномерность нужна не только для всех данных, но и для горячей части. Поэтому есть и совсем прохие примеры выбора ключа - например, дата заказа/поста, в этом случае данные размазываются равномерно, но горячие данные либо сидят на совсем небольшой части кластера, либо почти любая операция должна подгружать данные со многих нод. Реальная история из твиттера и выборов обамы - добавляли по несколько нод в день на новые твиты, порвали два баяна во время выборов Обамы, в итоге сменили схему шардинга.
• #8: Есть парочка “олдскульных” рабочих способов, которые обеспечат шардинг в разумных пределах (условно, от 1 до 50 серверов). деление на двойку рулит, потому что решардинг только половины данных с каждой ноды каждый раз пиздец приходит на больших числах, т.к. нужно закупать много железа очень рабочий и удобный вариант когда вы знаете что в пределе не может быть данных больше чем X X < 50 узлов replication based doubling - это йогурт для админов завиточки к предыдущей схеме - 2*3*4 - фишеру не забыть их рассказать
• #9: примеры на предыдущем слайде это уже функция хэширования - например выраженная в виде crc + остаток от деления, либо first login letter Ага! Идея - что мы ещё можем использовать как функцию хэширования Например first login letter - это как раз совершенно не гарантирует равномерность распределения, крайне неудобен в поддержке, когда окажется что одна буква не влезает в несколько серверов
• #10: если предполагается полностью эластичный рост на тысячи серверов если нужно решение “из коробки” методы
• #11: мы конфигурируем отображение ключа на шард заданное с помощью таблицы ключ на бакет отображается с помощью хэш функции бакет на шард отражается с помощью таблицы соответствия вопрсо: где мы храним эту таблицу? На центральном серевере либо на координаторе. В любом случае, возникает проблема распространения конфиугурации при её изменении максимально р может быть задано распределение центральный сервер как только ты используешь математику, ты теряешь в свободе = ты не можешь конкретный ключ при желании положить в конкретное место (это если есть промежуточные бакеты). Так что от бакетов иногда имеет смысл отказаться
• #12: главная проблема - минимизировать количество ребалансировки при добавлении шарда 9/11 first victim, one of the founders of AKAMAI, consistent hashing and merkle trees - for load balancing of content delivery network you need a lot of virtual points otherwise you don’t have sufficient randomness библиотеки есть в open source - профит решардинг - при больших данных - положит вам сеть в любом случае,потому что заливка шарда всё равно положит роутер в стойке в которой находится этот шард таким образом, нерезиновый
• #13: однозначная функция, принимает два числа и выдаёт server_id < n_servers очень ровно режет диапазон не имеет состояния (удобно разместить как на клиенте, так и на сервере, так и на прокси - всц равно где) минусы - долго работает при большом количестве шардов, сложность - N^2
• #21: forget about it on petabyte scale patterns of avoiding resharding: update is a move expire