О загрузке данных

Редкая запись на тему моей профессиональной деятельности :)

Вот тут один товарищ пишет, как в Фейсбуке (не соц.сети, а компании) с его, видимо, помощью сделали систему, загружающую в СУБД Вертика 35TB/час данных (или 10GB/сек). Это нижняя планка, SLA, а пиковая производительность должна быть в полтора-два раза выше, чтобы реагировать на колебания нагрузки, незначительные задержки и прочее. Необходимо заметить, что параллельно непрерывной загрузке система обслуживает запросы клиентов. В нашей компании мы загружаем данных меньше, но в расчете на узел кластера, думаю, примерно столько же. Я давно хочу написать статью на Хабре про оптимизацию скорости загрузки в Вертику, но чтобы не быть голословным, надо заново перепрогнать тесты в разных конфигурациях, нарисовать таблички и графики, а это время и лень. Тем не менее, базовые принципы, изложенные в статье выше, верные и могут быть применены к любой массивно-параллельной системе управления данными, не только к Вертике. Попробую их тут обобщить, по ходу дела комментируя некоторые моменты вышеуказанной статьи.

Для начала, некоторые предварительные соображения. Далее я буду употреблять слово файл для обозначения порции данных (обычно довольно большой). Можно заливать напрямую потоком через сеть, но такое решение не очень устойчиво к отказам сети или заливающего узла кластера. Кроме того, я буду употреблять слово сервер для обозначения узла кластера, мне кажется это более естественным. И последнее, я буду писать диск понимая под этим дисковую подсистему.

Скорость загрузки или правильнее говорить пропускная способность системы на запись, так как загрузка происходит во много потоков, определяется сочетанием трех основных факторов:

1. Скоростью обработки и загрузки одного файла на одном сервере.
2. Масштабируемостью по числу параллельных загрузок в пределах одного сервера.
3. Масштабируемостью по числу параллельных загрузок в пределах всего кластера.

Сверху скорость, очевидно, ограничена производительностью дисковой подсистемы.
( Read more... )