Записки на полях

Вчера, пока Америка голосовала за Трампа, я выступил на юбилейной конференции HighLoad++, которая в этот раз проводилась в Школе Управления Сколково. Это было мое третье выступление на HL++ (предыдущие -- в 2012 и 2013гг) и, наверное, самое успешное. Рассказывал я про Яндекс.ClickHouse -- аналитическую массивно-параллельную СУБД, разработанную Яндексом для своих потребностей и выпущенную в OpenSource летом этого года.

Надо сказать, что Яндекс произвел некоторую революцию. КликХаус -- это очень быстрая и очень хорошо масштабируемая система, которая по скорости может померяться с кем угодно, включая Vertica. Яндекс -- большие молодцы, что ее сделали, и еще большие, что открыли для всех желающих. В КликХаусе применен ряд удачных технических решений, за счет чего достигаются впечатляющие результаты производительности на тестах и реальных задачах. Впрочем, в большей степени они впечатляют тех, кто до этого имел дело только с простыми OLTP базами данных или с Хадупом. Интерес к КликХаусу в России и в ИТ-мире большой и вполне заслуженный. Яндекс выступил с докладом и провел несколько митапов. А потом выступал я.

В моей компании я веду проект по миграции части инфраструктуры на КликХаус и мы сполна вкусили всю его специфику. Надо сказать, что у Яндекса нет опыта продвижения OpenSource проектов, и они не понимают, как это делать и зачем. Я безуспешно пытался выяснить их планы развития, roadmap -- не раскрывают. После моего доклада, надеюсь, что они поняли свои ошибки, хотя бы некоторые. Если в своей презентации ребята из Яндекса рассказывали, какой КликХаус хороший и как он замечательно решит все проблемы, то я указал на существенные недостатки и ограничения КликХауса, которые делает его использование для задач вне Яндекса неудобным, а возможный переход с другой инфраструктуры -- весьма болезненным. Конечно, все проблемы решаемы, и некоторые из решений я предложил и обсудил в своем выступлении, но они существенно усложняют использование продукта. Хотя многие из недостатков и ограничений могли бы быть достаточно легко устранены, если бы Яндекс обращал большее внимание на пожелания OpenSource сообщества.

По окончании, ребята из Яндекса не полезли драться, а поблагодарили за конструктивную критику и пообещали, что многие из отмеченных мною недостатков скоро будут устранены.

А Сколково -- http://school.skolkovo.ru/ru/ -- мне понравилось.

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

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

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

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

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

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