Архитектура хранилища фотографий ВКонтакте
Евгений Курпилянский на прошедшем 29 августа митапе VK Tech Talks | Engines & KPHP рассказал гостям и онлайн-зрителям об архитектуре хранилища фотографий ВКонтакте. Презентуем расшифровку его выступления.
Начнём с цифр:
В начале поговорим про схемы репликации. Я расскажу вам про четыре схемы репликации, и мы разберём их по четырём параметрам.
В строках «Потеря данных» и «Временная недоступность» будет записывать сколько дисков (серверов) должны сломаться, чтобы это произошло.
Перейдём к деталям и как они реализованы.
Начнём с самого старого хранилища, где две копии на одном сервере.
Photo-engine — это база данных, которая хранит данные о пользовательских альбомах.
Исправим это недоразумение и сделаем, чтобы хранилось три копии на трёх случайных серверах.
Доклад окончен? Всё сделали?Представим, что у нас сломался четвёртый сервер и нам необходимо каким-то образом восстановить данные, которые на нём лежали. Давайте просто скопируем туда фотографии, которые там лежали. Да, это долго, а есть ли у нас другой выход? Нет.
Добавим дополнительный уровень и получим двухуровневую архитектуру. Движки назовём manager'ами. Основная функция менеджера — знать актуальное место хранения фотографии.
Мы скажем менеджерам, что на четвёртом сервере сломался диск — пожалуйста, сделай копию в другом месте. Все менеджеры параллельно найдут все фотографии, которые лежали на том диске, и скомандуют storage, чтобы они скопировали их.
В итоге все они скопируют разные фотографии с разных мест в разные места. За счёт этого параллелизма замена диска будет занимать меньше часа. Теперь нам не нужно заполнять четвёртый сервер старыми фотографиями — он сам заполнится новыми.
Схема отдачи фотографии:
Важно отметить, что у нас появилось свойство «Дедупликация»: если пользователь зальёт ту же самую фотография второй раз, то мы можем сделать так, чтобы она не загружалась повторно.
Как мы можем это сделать: ключи, хранящиеся у менеджера, могут быть случайными, а могут быть детерминированными (определяемыми) по какому-то контенту фотографии.
Как устроены три копии на трёх случайных серверах — .разобрались.
Как мы сделаем очень крутое хранилище с кодами восстановления потерь?
Посмотрим, что же такое коды восстановления потерь. Например, XOR.
XOR — это битовая операция «исключающее или», возвращающая 0, если биты одинаковые, и 1, если они разные. Её также можно применять и к набору битов, файлов. При потере какого-либо блока мы легко можем восстановить его из двух других.
Таким образом если мы положим три файла на три разных сервера, то всегда, при потере одного диска мы можем его восстановить.
Есть ещё один код восстановления, но чуть сложнее — EVENODD.
Нам необходимо взять количество файлов, равное какому-либо простому числу (3, 5, 7, 11 …), и посчитать их коды избыточности. Преимущество этого кода в том, что мы можем всё восстановить даже при потере двух дисков.
Но нам этого мало! Мы хотим ещё лучше.
Давайте возьмём 2 трлн фотографий и разобьём их на группы по 15, примерно одинакового размера, и выстроим в матрицу. Далее посчитаем EVENODD для каждой строки. Теперь посчитаем XOR по столбцам. Матрица была 3х5, а стала 4х7.
Рассмотрим схему этого метода:
Что мы имеем в итоге:
Давайте переезжать. У нас есть 200 петабайт старых данных и нам хочется их перенести в новое хранилище.
Если мы сделаем так, как написано на фотографии выше, то мы сломаем все старые URL, потому что нет старого хранилища и нечего отдавать.
Нет! Нужно это исправить!
В заключении итоговая схема (qps — количество запросов в секунду):
На этом доклад Евгения подходит к своему логическому завершению. Полную версию выступления можно посмотреть ниже:
The Brown Room — независимое интернет-издание про социальные сети и современные технологии
Автор: Сергей Котов
Корректор: Арсений Метелёв
Слайды и данные: VK Tech