Высоконагруженные системы

Миллионы запросов в секунду. Сотни серверов с десятками ядер и терабайтами оперативной памяти. Много пользователей и данных. И их становится всё больше. Да, это всё HighLoad. Но HighLoad не только это.

В основе хороших высоконагруженных систем лежит тщательно спроектированная архитектура. Благодаря этому, системы постоянно масштабируются, а их ресурсов хватает для работы с текущими нагрузками. И тогда HighLoad-конференции не превращаются в дискуссии Как сэкономить на ресурсах при штатно выросшей нагрузке или Куда девать все имеющиеся у нас мощности.

Но что насчет безопасности и защиты данных при высоких нагрузках? Что думают разработчики и эксперты о внешних угрозах, которые тоже могут вывести систему из строя? О сохранении данных, их правильной передаче и использовании? Артём Гавриченков в Программном комитете отвечает за эту область на конференции HighLoad++. Сегодня он расскажет, чем наша долгожданная офлайн-встреча Highload++ Весна 2021 будет интересна и полезна любому разработчику. Доклады на конференции будут и о безопасности, и о шифровании, и о биометрии, и, конечно, о многих других смежных с безопасностью темах.

Артем, чем ты сейчас занимаешься и какое отношение имеешь именно к высоким нагрузкам?

На протяжении 10 лет я строил продукт Qrator по защите DDoS-атак. Тут, наверное, сразу понятно, где высокие нагрузки. Последние 5 лет был техническим директором этого продукта, даже больше пяти. В данный момент я директор по продукту в Servers.com это компания, которая занимается предоставлением инфраструктурных решений (bare metal cloud, облачное хранение данных, фаерволы, Managed Kubernetes), то есть опять же решения для больших нагруженных проектов.

Как давно ты в Программном комитете и как ты в него пришел?

Я выступал несколько раз на Highload, начиная с 2011 года. А в 2018-м мы пообщались с Олегом Буниным, и он пригласил меня в ПК как эксперта по защите информации, по высоким нагрузкам в плане DDoS-атак и по масштабируемым системам по сети и инфраструктуре.

Чем тебе нравится быть в ПК? Что это для тебя?

Это возможность пообщаться с очень интересными людьми, высокими профессионалами своего дела, как с членами ПК, так и докладчиками. Вы можете увидеть прямо весь bleeding edge технологий самые модные, и при этом уже немного проверенные в деле. То есть можно узнать, какие направления есть в индустрии, куда это все идет, что появляется каждый год, а на что не стоит тратить время. Программа HighLoad++ сама по себе дает такое понимание людям, поэтому и стоит на него ходить.

А в программном комитете я могу дополнительно пообщаться со всеми докладчиками. Конференция идет всего 2 дня, хоть и в несколько потоков при всем желании вы не успеете со всеми пообщаться. А у членов ПК есть возможность общаться с интересными докладчиками на протяжении полугода, пока мы отбираем доклады, а потом помогаем спикерам готовиться к выступлению. То есть здесь я снова получаю полный обзор всех актуальных технологий, которые существуют и появляются. Это, в том числе, и инструмент поддержания собственной компетентности и уровня awareness по технологиям.

Какие темы нас ждут в разделе безопасности в этом году на конференции?

В первую очередь, мы говорим про крупные системы, которые выдерживают серьезные нагрузки, то есть хорошо спроектированные системы. В рамках проектирования, создания архитектуры системы, написания кода необходимо решать и вопросы безопасности.

Безопасность это, как правило, дополнительные проверки и дополнительная нагрузка, в частности, криптография, проверка вводимых данных, проверка аутентификации хостов и т.д. Поэтому надо учитывать эти вопросы еще на этапе проектирования системы. Добавить безопасность потом в систему, которая уже работает, может быть очень сложно.

Также будет тема защиты систем управления базами данных (СУБД), отвечающая на не совсем тривиальные вопросы. Как усиление безопасности БД влияет на производительность? Что, если мы хотим применять защищенные соединения? Что, если у нас данные нужно хранить в зашифрованном виде? Как организовать аудит?

Еще будет близкая к этому тема шифрования соединений. Сейчас практически все соединения в интернете от браузера или мобильного приложения до сервера надежно шифруются, но криптография всегда повышает нагрузку. У нас будет Александр Крижановский (Tempesta Technologies) с рассказом о том, как написать быстрый TLS-хендшейк в ядре Linux. Это такой хендшейк, который эффективней на десятки процентов, чем стандартное решение он дает меньшее время задержки, то есть готов работать под большой нагрузкой.

Будет доклад от РТЛабс про единую биометрическую систему. Это мультивендорная система, которая обеспечивает возможность работы с любыми модальностями биометрии (лицо, голос и т.д.). Биометрия в последнее время в России это очень активный хайп, развертывание биометрической аутентификации в приоритете у правительства. И конечно, у людей есть опасения, как это может работать и что может пойти не так вопрос на самом деле серьезный. Поэтому мы включили в программу этот доклад, чтобы люди, кому важно и/или интересно устройство единой биометрической системы, могли узнать, как она работает.

Система РТЛабс рассчитана на 150 млн человек, и этого должно хватить для 136 миллионов россиян. Хотя в реальности, конечно, будет меньше. Но, с другой стороны, может быть, ее удастся расширить и на таможенный союз, например, на Беларусь.

Будут ли какие-нибудь новинки в решении известных задач безопасности?

На эту тему будет доклад от Касперского про быстрое детектирование спам-писем. Проблеме спама столько же лет, сколько электронной почте. Она никуда не уходит, с годами становится сложнее, потому что, например, Gmail или Яндекс собирают почту в большом объеме и более-менее умеют детектировать спам с минимальным количеством ошибок первого и второго рода. Но в финале это приводит к ситуации как с Ковидом. Иммунитет летучих мышей совершенно адский он выжигает вирусы каленым железом! Это очень стойкое животное. Но по каким-то эволюционным причинам эта иммунная система выборочно оставляет некие вирусы, которые летучей мыши уже вреда не причиняют, но там живут.

Так вот мы в спаме получаем ровно такую же ситуацию. Google, Яндекс и прочие гиганты выпалывают спам, который легко детектировать, но самый адский и хардкорный остается. Например, в той же корпоративной почте у нас нет доступа ко всему тому объему данных, и поэтому у нас не получается спам фильтровать так же просто. Никакие простые методы давно не работают, поскольку спам, который умеет обходить Google, он и нас обходит очень легко.

Хочу заметить, что проблема спама никогда никуда не уйдет. Есть даже категория шуток в IT-сообществе про Final Ultimate Solution to the Spam Problem. Примерно раз в год в каких-нибудь списках рассылки появляется человек, который утверждает, что он нашел уникальное полное решение проблемы спама и чего на практике никогда не случается.

Поэтому на рынке есть продукты для решения этой задачи до определенного уровня качества это лучше, чем есть сейчас. И одно из них от Касперского докладчик расскажет, как оно устроено внутри, какие были сложности, как они подошли к этой задаче и какие результаты получились.

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

Какие доклады, не связанные с безопасностью, тебе интересны самому?

По смежной теме будет доклад Василия Сошникова про API Gateway. Эта технология реально популярный хайп последних лет. Она очень часто встречается, в том числе, в over-engineering проектах. Поэтому в докладе будет обзор концепции и того, какие плюшки это нам дает и какие сложности возникают в эксплуатации. Что поможет найти ответ на вопрос: для нашего проекта API Gateway это полезный момент или просто хайп, на который не нужно тратить время?

Это действительно интересно. А ты сам на HighLoad++ собираешься посетить только то, что описал, или тебя интересуют еще какие-то доклады и мероприятия?

Уже принято 75 докладов, и есть, конечно, интересные и не только про безопасность. Например, доклад Сбербанка про борьбу с TCP Incast. Это как раз инфраструктурная часть как устроены центры обработки данных и как устроена сеть на большом проекте. Там возникают разные проблемы.

Очень интересная тема про маршрутизацию Яндекса каким образом Яндекс маршрутизирует машины, и как он это делает таким образом, чтобы экономить своим клиентам деньги, в том числе коммерческим компаниям (доставка документов, товаров и пр.). Правильным образом выстроенная простая оптимизация алгоритма начинает экономить клиентам по 100000 рублей в месяц.

Ты часто бываешь на конференциях?

С 2017 года я не пропускал ни одного HighLoad++, в том числе ни одного питерского, и ни одного РИТа, правда, в Сибирь я не ездил ни разу.

Ты сам предпочитаешь онлайн или офлайн?

Офлайн, конечно, потому что нам за год никому так и не удалось достойно заменить офлайн конференции. Онлайн это хорошо как дополнение, но очень многие офлайн-плюшки просто невозможны в онлайн-режиме: нетворкинг, например, или возможность реально познакомиться с интересными людьми вплотную, то есть выйти на какой-то уровень доверия.

Когда ты сам выступал в качестве спикера, что самое важное в построении докладов? Какие-то фишки есть, чтобы выступление было запоминающимся и интересным?

Структура это должно быть выстроено обязательно, над ней нужно очень плотно работать. Обязательно делать прогоны с таймингом и пониманием того, сколько времени будет потрачено и какие вещи нужно сказать обязательно. И крайне желательно иметь примеры из жизни, потому что примером можно показать намного больше. Один пример стоит десятка слайдов.

Доклад не должен быть комедийным. Если посмотрим, например, боевики последних лет (Мстители и т.д.), увидим, что там много времени уходит на юмор, перебивки, прибаутки и прочие штуки. То есть доклад не должен быть совсем уж развлекательным, но крайне желательно, чтобы часть entertainment в нем тоже присутствовала.

Что такое Highload лично для тебя? Как бы ты описал его человеку, который не член ПК, а просто приходит туда по собственному желанию?

Это уникальное сообщество профессионалов, специалистов в своем деле, работающих над уникальными по мировым меркам онлайн-проектами. Плюс возможность обменяться опытом с этими профессионалами. Большинство из них открыты для общения.

Конференция HighLoad++ 2021 пройдет уже 17 и 18 мая в Москве, в Крокус-экспо. Сейчас открыт дополнительный прием докладов по новым темам. Если вы хотите поделиться тем важным и интересным, что вы нашли, разработали и открыли во время онлайна в пандемию мы вас ждем!

Билеты можно купить здесь. И да, цена с 30 апреля вырастет, для решения осталось 2 недели.

Подписывайтесь на наши новости о конференции, чтобы быть в курсе всех изменений, новинок и интересностей!

Телеграм здесь и здесь, FaceBook, VK, Twitter.

Как считает Евгений Россинский, СТО должен быть одновременно и стратегом в настоящем, и мечтателем, смотрящим в будущее. Стратег должен очень хорошо понимать, где находится сейчас чтобы что-то улучшить, надо сначала померить и найти метрику качества. А мечтатель должен любить свое дело, чтобы заряжать людей вокруг и двигать дело вперед.

Евгений основал компанию по разработке высоконагруженных проектов Netstream (online-вещание и видео), а в 2012 году вместе со всей командой перешел в ivi, где является СТО до сих пор. C 2006 года преподает в МГТУ им. Баумана авторский курс Технологии командной разработки ПО, потому что однажды обнаружил, что не может найти грамотных разработчиков в команду.

Такой же стиль у него в Программном комитете HighLoad++ находить интересных спикеров и животрепещущие темы, чтобы показать их широкой аудитории и продвинуть в будущее. Накануне конференции мы встретились с Евгением, чтобы расспросить о докладах и спикерах HighLoad++ Весна 2021. Что было бы интересно, а что просто обязательно надо идти и слушать, если вы разработчик высоконагруженных систем.

Женя, расскажи, чем ты занимаешься и какое отношение имеешь именно к высоким нагрузкам?

Я технический директор ivi, а это очень нагруженный сервис. На каких-то сервисах у нас десятки тысяч запросов в секунду, на других доходит и до сотни. Я отвечаю за стратегию технического и технологического развития компании, одновременно отслеживая, чтобы все шестеренки крутились так, как это нужно бизнесу.

Какие доклады HighLoad++ ты курируешь как член Программного комитета?

3-4 года назад я пришел в Программный комитет на историю с бэкендом. Но так как с тех пор в ivi много чего интересного появилось, в ПК я теперь занимаюсь и другими темами докладов от баз данных до платежных систем.

Тебе нравится быть в ПК? Что это для тебя?

Да, мне нравится. Это прекрасное времяпрепровождение по четвергам вечером :)

Но на самом деле это дает много возможностей.

Во-первых, я встречаю много интересных людей, которые стараются в своих выступлениях показать то, что сообщество считает интересным. Во-вторых, так я могу свое видение интересного вывести на широкую аудиторию. А третий пункт это дает развитие мне самому. У нас распределение докладов между членами ПК происходит не только по принципу мне интересно и/или я разбираюсь в этом. Бывает, что хочешь тему понять глубже и становишься куратором докладчика.

Ты сам часто бываешь на конференциях?

На наших да. На HighLoad стараюсь попасть, но даже если не попадаю, всегда смотрю интересные доклады в записи. Некоторые вещи даже пересматриваю и делаю себе пометки.

Но офлайн круче онлайна?

Абсолютно так! Онлайн конференция это не конференция в моем понимании. Это просто набор лекций, семинаров и выступлений. В чатике даже знаниями обменяться нормально нельзя. Даже если после видео-выступления у тебя в сухом остатке осталась часть информации, ты ею можешь не так эффективно воспользоваться. Потому что даже в вопросах, которые люди из зала задают, может вскрыться очень много чего интересного. И да, я ни одного вопроса ни разу ни в одной онлайн-конференции не задал. Хотя в офлайне спрашиваю часто.

Я и выступать онлайн не люблю, потому что ты не понимаешь аудиторию. Говорить в монитор можно 5 минут или даже 10. Но за 40 минут, пока что-то рассказываешь, ты знать не знаешь может, все уже ушли кофе пить, а ты распинаешься. Я предпочитаю видеть аудиторию. Поэтому я за то, чтобы люди приходили и смотрели офлайн. Плюс я считаю, что конференция хороша, когда это совместная работа с обеих сторон и докладчиков, и слушателей которые к тому же находятся в одном помещении. Когда ты пришел, тебе уже, черт возьми, неудобно перед человеком, который стоит на сцене! Ты, конечно, в телефончике можешь что-то тыкать, но общий коэффициент полезного действия от слов докладчика сильно выше.

Как часто ты сам выступаешь?

На HighLoad я выступал последний раз в 2018 году, и у меня было 3 доклада. Пару раз был спикером на TeamLead Conf. А сейчас у меня пока нет таких вещей, которыми хотелось бы похвастаться. Можно, конечно, из пальца высосать какую-то тему. Даже она кому-то будет интересна потому что всегда найдутся люди, у которых нет твоего опыта и твои слова будут им нужны и интересны. Но хочется же, чтобы доклад нравился самому себе.

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

Как построить доклад, чтобы выступление было запоминающимся и интересным? Какие-то фишки есть у тебя?

Доклад должен нравиться мне самому. То есть я должен любить и верить в то, о чем я говорю. Если мне это нравится, я этим горжусь, то расскажу красиво, ярко и людям тоже понравится. Но я не люблю повторяться и мусолить одну и ту же тему на десятках конференций. Это неинтересно, так как доклад уже публичный, его теперь любой может найти и посмотреть. Можно рассказать примерно о том же самом и под другим углом, но максимум два раза. Потому что хочется больше новых интересных докладов.

В целом же ты должен понимать запросы аудитории, чтобы предложить конкретный практический опыт в том, о чем говоришь. Тогда можно привести примеры, которые зайдут аудитории и люди поймут, зачем им это нужно. Важно говорить на одном языке с аудиторией. И подсвечивать, не скрывая, проблемы, которые были у тебя. Есть доклады: У нас было все прекрасно! Сейчас мы сделали все еще более замечательно! но так не бывает. У всех всегда есть большая бочка дегтя и всего одна ложка меда, а все только про нее и рассказывают. А самое важное это как раз то, как бочку расхлебать.

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

Например, копнул слишком глубоко и видишь, что всем уже неинтересно выходишь на более популистский уровень. Когда на нем стало интересней, ты можешь снова погрузиться. Это очень ценная штука, когда ты работаешь с аудиторией и получаешь от нее обратную связь.

Что же ждет нас в этом году на HighLoad++ 2021?

Подготовка к HighLoad++ Весна 2021 из-за пандемии безумно растянулась во времени. Но зато и программа получилась плотная, классная. Сейчас самое время обкатать все сложившиеся темы, даже если некоторые подустарели за полтора года.

Например, будет хороший доклад про архитектуру процессора Эльбрус. Про них мне рассказывали, когда я был еще на военной кафедре в институте. А они все еще эволюционируют, это классная и интересная штука такая альтернативная архитектура, которая до сих пор успешно применяется. Даже Интеловсий Итаниум по сути их последователь. Так что доклад будет очень полезен для расширения кругозора и вообще для общего развития.

Хороший доклад от Ozon про Data Management Platform. Будет интересно узнать, как ребята автоматизировали фильтрацию пользовательских событий. Сама тема мне тоже довольно близка, поэтому я с удовольствием послушаю.

Очень интересный доклад Математика и разработка быстрых TLS-хендшейков. Мы в ivi довольно много в свое время помучились с хендшейками и тем, как разные устройства их осуществляют. Да и в общем сама тема о том, на чем построены все защищенные соединения очень животрепещущая.

Также всегда очень интересно послушать Андрея Аксенова даже когда он несет какую-то дичь, все равно это интересная дичь. В этот раз у него будет прикладная эзотерика. Хочу это послушать, потому что 80% его докладов фееричные. Ну и просто интересно узнать, что у человека в голове.

Доклад Погружение в Helm package manager пришел к нам по рекомендации, и после проверки тоже вошел в программу. Олег Вознесенский из X5 Retail group расскажет про Helm. Это как раз тот случай, когда мне интересно послушать конкретные use case и какие-то вещи, которых в документации нет, а человек уже их попробовал и у него есть экспертиза. И Олег очень просто и на пальцах объясняет те штуки, которые надо долго пробовать, чтобы накопить эту экспертизу.

Также всегда приятно послушать Алексея Миловидова. Он говорит про интересные вещи, которые иногда становятся основой для философии. К тому же мне очень интересно всё, что касается ClickHouse. В ivi мы его применяем тоже, и поэтому эта тема всегда очень острая для нас.

Еще в этом году будут выступать Коля Самохвалов, а Костя Осипов покажет паксос в картинках. Костя блестящий инженер и всегда режет правду-матку, не стесняясь ни регалий, ничего. Хочет кого-то отчихвостить расскажет всё, что думает. У него может быть честный, искренний доклад, а я такие люблю.

Денис Рожков и Георгий Тарасов в Информационной безопасности против HighLoad раскроют нужную и одновременно интересную тему про кибербезопасность. А Mail.ru расскажет историю про версионирование данных на Tarantool.

А еще Саша Тоболь! Мой хороший друг, прекрасный инженер, который великолепно рассказывает, прекрасно разбирается в материале и всегда очень глубоко погружается во все темы. Саша бывший лид Одноклассников, а сейчас СТО в ВК. Его всегда классно послушать, у него редкое сочетание, когда и докладчик хороший, и инженер классный.

Также у Яндекс.Такси будет пара интересных докладов. Про рефакторинг в большом проекте и отказоустойчивость сервиса. И особенно мне интересно, как аудитория воспримет доклад Максима Педченко. Его тема очень интересная, и работая с ним, я видел, что Максим старается сделать из своего выступления действительно нужный и полезный материал, рассказывая о проблемах популярного сервиса и способах решения типовых проблем.

В общем и целом какие боли затрагивает эта конференция и чем она поможет слушателям?

Как и в прошлый раз, будут тонны кейсов, которые рассмотрят тонны проблем. Начиная от баз данных, масштабирования, и заканчивая какими-то узкоспециализированными вещами про архитектуру или математику. Направленность конференции та же. Инженеры по-прежнему регулярно сталкиваются с кучей проблем: об одних им рассказывали в институте, о других не знает никто, но зато по части третьих уже есть опыт и практика. Ценность конференции в том, что ты приходишь, слушаешь и понимаешь ага, такой-то кластер проблем такая-то компания решила так-то и так-то.

И даже если у тебя была аналогичная задача, в твоей коллекции появится еще одна тропинка, по которой кто-то сходил и чего-то добился (либо нет). Ты можешь свое текущее решение сравнить с тем, что рассказывают коллеги на сцене. И даже можешь подойти потом и сказать: Ребята, вы идиоты! Зачем вы это сделали, можно ведь так, так и так. Тут неожиданно выясняется, что у тебя одна специфика, а у них другая, но вы находите какие-то интересные мысли друг у друга, и всем становится хорошо. Где вы такое найдете в онлайне или в статье?

Последний вопрос: что HighLoad лично для тебя?

Сначала это была просто тусовочка, а сейчас это работа, хобби, увлечение и сообщество.

HighLoad++ довольно интересная конференция, которая позволяет тебе посмотреть на свои проблемы под другим углом. Ты, может, и не найдешь решения своей конкретной задачи, но другие use cases могут тебя подтолкнуть на идеи, что можно еще и по-другому сделать. И в том направлении, о котором ты совсем не думал. Это и ценно в любой конференции. На HighLoad у меня было много таких открытий.

А самое интересное это люди, у которых можно проконсультироваться в случае чего. Даже когда ты сам выступаешь, к тебе постоянно приходят люди и спрашивают а это как? Постепенно у тебя нарабатывается свой ближний круг общения, чтобы можно было у кого-то что-то спросить и с кем-то поделиться.

С каким настроением идти на HighLoad++?

Хочешь узнать что-то новое приходи, общайся и слушай. Задавай вопросы, лови докладчиков в специальных зонах для вопросов, обсуждай кейсы. Да просто хорошо проведи время, потому что иногда необходимо поднять голову из внутреннего бега.

КонференцияHighLoad++ Весна 2021уже готовится к посадке 17 и 18 мая в Москве в Крокус-экспо мы все встретимся и обсудим всё то, что невозможно было обсудить в чатиках. Расписание ждет вас, а там в течение всех двух дней 8 потоков выступлений, 6 мастер-класов и пивная вечеринка!

Билеты можно купитьздесь. А подписавшисьна нашу рассылку, можно получить материалы мини-конференции Saint HighLoad++ 2020 :)

Алексей Миловидов делает ClickHouse и, конечно, знает его вдоль и поперек. В том числе и о том, как его можно использовать дополнительно к его штатным и всем хорошо известным функциям.

И сегодня расскажет про эти необычные способы его использования и, может быть, даже не для хранения и обработки данных.

ClickHouse для тестов железа

Самое простое, что можно сделать с ClickHouse, если есть свободные серверы это использовать его для тестов оборудования. Потому что его тестовый dataset содержит те же данные с production Яндекса, только анонимизированные и они доступны снаружи для тестирования. Про то, как подготовить хорошие анонимизированные данные, я рассказывал на Saint HighLoad++ 2019 в Санкт-Петербурге.

Ставим ClickHouse на любой Linux (x86_64, AArch64) или Mac OS. Как это сделать? мы собираем его на каждый коммит и pull request. ClickHouse Build Check покажет нам все детали всех возможных билдов:

Отсюда можно скачать любой бинарник с gcc и clang в релизе, в debug, со всякими санитайзерами или без, для x86, ARM или даже Mac OS. ClickHouse использует все ресурсы железа: все ядра CPU, шины памяти и грузит все диски. Какой сервер ему не дай проверит полностью, хорошо или плохо тот работает.

По этой инструкции можно скачать бинарник, тестовые данные и запустить запросы. Тест займёт около 30 минут и не требует установки ClickHouse. И даже если на сервере уже установлен другой ClickHouse, вы все равно сможете запустить тест.

В результате мы получаем публичный список протестированного железа:

Все результаты мы получаем от пользователей через краудсорсинг и выглядят они примерно так:

Вы можете выбрать серверы для сравнения для каждого можно посмотреть разницу в производительности. Конечно, и других тестов железа существует немало, например, SPECint и вообще куча тестов из организации SPEC. Но ClickHouse позволяет не просто тестировать железо, а тестировать рабочую СУБД на настоящих данных на реальных серверах откуда угодно.

ClickHouse без сервера

Конечно, обычно ClickHouse это сервер + клиент. Но иногда нужно просто обработать какие-то текстовые данные. Для примера я взял все исходники ClickHouse, собрал их в файл и сконкатенировал в файл под названием code.txt:

И, например, я хочу проверить, какие строчки в коде на C++ самые популярные. С помощью типичной shell-команды удалим из каждой строчки кода начальные пробелы и пустые строки, отсортируем и посчитаем количество уникальных. После сортировки видим, что, конечно, самая популярная строчка это открывающая фигурная скобка, за ней закрывающая фигурная скобка, а еще очень популярно return false.

Этот результат я получил за 1,665 секунд. Потому что все это было сделано с учетом сложной локали. Если локаль заменить на простую, выставив переменную окружения LC_ALL=C, то будет всего лишь 0,376 с, то есть в 5 раз быстрее. Но это всего-лишь шел скрипт.

Можно ли быстрее? Да, если использовать clickhouse-local, будет еще лучше.

Это как-будто одновременно и сервер и клиент, но на самом деле ни то, и ни другое clickhouse-local может выполнять SQL запросы по локальным файлам. Вам достаточно указать запрос, структуру и формат данных (можно выбрать любой из форматов, по умолчанию TabSeparated), чтобы обработать запрос на входном файле. За 0.103 секунд то есть в 3,716 раз быстрее (в зависимости от того, как вы запускали предыдущую команду).

Для демонстрации чего-то более серьезного давайте посмотрим на те данные, которые собирает GitHub Archive это логи всех действий всех пользователей, которые происходили на GitHub, то есть коммиты, создание и закрытие issue, комментарии, код-ревью. Все это сохраняется и доступно для скачивания на сайте https://www.gharchive.org/ (всего около 890 Гб):

Чтобы их как-нибудь обработать, выполним запрос с помощью ClickHouse local:

Я выбрал все данные из табличной функции file, которая берет файлы вида *.json.gz то есть все файлы в формате TSV, интерпретируя их как одно поля типа string. С помощью функции для обработки JSON я вытащил из каждой JSONины сначала поле 'actor', а потом поле 'login' в случае, когда оно равно Алексей Миловидов и выбрал таких первых 10 действий на GitHub.

Может возникнуть впечатление, что 890 Гб данных смогли обработаться за 1,3 секунды. Но на самом деле запрос работает потоково. После того, как находятся первые 10 строк, процесс останавливается. Теперь попробуем выполнить более сложный запрос, например, я хочу посчитать, сколько всего действий я совершил на GitHub. Используем SELECT COUNT... и через полторы секунды кажется, что ничего не происходит. Но что происходит на самом деле, мы можем посмотреть в соседнем терминале с помощью программы dstat:

И мы видим, что данные читаются с дисков со скоростью примерно 530 Мб/с и все файлы обрабатываются параллельно почти с максимальной скоростью насколько позволяет железо (на сервере RAID из нескольких HDD).

Но можно использовать ClickHouse local даже без скачивания этих 980 Гб. В ClickHouse есть табличная функция url то есть можно вместо file написать адрес https://.../*.json.gz, и это тоже будет обрабатываться.

Чтобы можно было выполнять такие запросы в ClickHouse, мы реализовали несколько вещей:

1. Табличная функция file.

2. Поддержка glob patterns. В качестве имени файлов можно использовать шаблон с glob patterns (звёздочка, фигурные скобки и пр.)

3. Поддержка сжатых файлов в формате gzip, xz и zstd из коробки. Указываем gz и всё работает.

4. Функции для работы с JSON. Могу утверждать, что это самые эффективные функции для обработки JSON, которые мы смогли найти. Если вы найдёте что-нибудь лучше, скажите мне.

5. Параллельная обработка файлов. Там несколько тысяч файлов, и будут использоваться все процессорные ядра. И даже один файл будет обрабатываться параллельно, потому что у нас есть параллельный парсинг форматов данных.

6. Тот самый параллельный парсинг.

Применять можно, само собой, для обработки текстовых файлов. Еще для подготовки временной таблицы и партиций для MergeTree. Можно провести препроцессинг данных перед вставкой: читаете в одной структуре, преобразовываете с помощью SELECT и отдаете дальше в clickhouse-client. Для преобразования форматов тоже можно например, преобразовать данные в формате protobuf с разделителями в виде длины в JSON на каждой строке:

clickhouse-local --input-format Protobuf --format-schema такая-то --output format JSONEachRow ...

Serverless ClickHouse

ClickHouse может работать в serverless-окружении. Есть пример, когда ClickHouse засунули в Лямбда-функцию в Google Cloud Run: https://mybranch.dev/posts/clickhouse-on-cloud-run/ (Alex Reid). Там на каждый запрос запускается маленький ClickHouse на фиксированных данных и эти данные обрабатывает.

Текстовые форматы

Для обработки текстовых данных, естественно, есть поддержка форматов tab separated (TSV) и comma separated (CSV). Но еще есть формат CustomSeparated, с помощью которого можно изобразить и тот, и другой в качестве частных случаев.

CustomSeparated:

format_custom_escaping_rule

format_custom_field_delimiter

format_custom_row_before/between/after_delimiter

format_custom_result_before/after_delimiter

Есть куча настроек, которые его кастомизируют. Первая настройка это правило экранирования. Например, вы можете сделать формат CSV, но в котором строки экранированы как в JSON, а не как CSV. Разница тонкая, но довольно важная. Можно указать произвольный разделитель типа | и пр. между значениями, между строками и т.п.

Более мощный формат это формат Template:

format_template_resultset

format_template_row

format_template_rows_between_delimiter

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

Есть формат Regexp:

format_regexp

format_regexp_escaping_rule

format_regexp_skip_unmatched

И тут clickhouse-local превращается в настоящий awk. Указываете регулярные выражения, в Regexp есть subpatterns, и каждый subpattern теперь парсится как столбец. Его содержимое обрабатывается согласно некоторому правилу экранирования. И конечно можно написать пропускать строки, для которых регулярное выражение сработало, или нет.

ClickHouse для полуструктурированных данных

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

Допустим, у вас есть таблица с логами, в ней есть столбец с датой и временем, а вот всё остальное вообще непонятно что. Очень соблазнительно всю эту кучу данных записать в один столбец 'message' с типом String. Если эта куча в формате JSON, функции для работы с JSON будут работать. Но неэффективно каждый раз, когда нам будет нужно только одно поле, например 'actor.login', читать придется весь JSON не будет преимущества столбцовой базы данных. С помощью ClickHouse мы легко это исправим прямо на лету, добавив с помощью запроса ALTER материализованный столбец:

После того, как материализованный столбец actor_login начнет записываться для новых данных в таблице, SELECT для новых данных будет читаться эффективно, а для старых будет вычисляться. Для материализации старых данных можно использовать несколько странный запрос для материализации всех данных в прошлом:

ALTER TABLE logs UPDATE actor_login = actor_login

И вы можете добавлять столбцы по мере необходимости, чтобы ускорить запросы.

Ускорение MySQL

В ClickHouse можно создать таблицу на основе табличной функции MySQL. Это просто: указываете хост: порт, БД, таблицу, имя пользователя и пароль (прямо так, как есть), делаем SELECT и всё выполняется за 15 секунд:

Работает это тоже без всякой магии: табличная функция MySQL переписывает запрос, отправляет его в MySQL и читает все данные назад, на лету на всё 15 секунд. Но что будет, если я тот же самый запрос выполню в MySQL как есть?

5 минут 41 секунда это позор! У ClickHouse тут как-будто нет преимуществ данные нужно переслать из MySQL в ClickHouse и потом уже обработать. А MySQL обрабатывает сам у себя локально почему же он так медленно работает?

Еще одна проблема результаты расходятся. У ClickHouse две строки счетчик (20577 и 13772), у MySQL один (44744), потому что он здесь учитывает collation (правила сравнения строк в разном регистре) при GROUP BY. Чтобы это исправить, можно перевести имя в нижний регистр, сгруппировать по нему и выбрать любой вариант:

Теперь счетчик один, данные почти совпадают и запрос даже ускорился. То есть ClickHouse быстрый независимо от того, какие выражения я напишу. Попробуем ускорить запрос еще больше. На основе данных из MySQL в ClickHouse можно создать словарь. Указываем в словаре ключ и источник MySQL со всеми этими данными:

Словарь будет периодически загружать таблицу в оперативку, она будет кэшироваться. Можно применять SELECT:

Получилось уже 6 секунд, хотя основное предназначение словаря использование для джойнов, когда, например, нам нужно получить данные динамически через другие столбцы. Можно также создать словари MySQL на каждом сервере в кластере ClickHouse и быстро с ними работать. Но если MySQL не выдержит нагрузки при обновлении словаря на каждом сервере в кластере, то можно создать из MySQL словарь на двух ClickHouse-серверах, и они будут доступны в виде таблиц в ClickHouse. Если с помощью движка Distributed создать таблицу, которая смотрит на эти два сервера как на реплики, то можно на всех ClickHouse-серверах создать словари из ClickHouse, которые смотрят на таблицу, которая смотрит на словарь MySQL.

Словари еще можно использовать для шардирования, если схема расположена во внешней мета-базе (и не обязательно в ClickHouse). Это тоже будет работать:

Есть вариант как радикально ускорить запрос, и для этого не нужны словари надо всего лишь переложить данные в полноценную таблицу типа MergeTree такой же структуры. Вставляем туда данные и делаем SELECT:

Видим, что SELECT выполняется за 0,6 с. Вот это настоящая скорость, какая должна быть это скорость ClickHouse!

В ClickHouse можно даже создать базу данных типа MySQL. Движок БД MySQL создает в ClickHouse базу данных, которая содержит таблицы, каждая из которых представляет таблицу, расположенную в MySQL. И все таблицы будут видны прямо в ClickHouse:

А вообще в ClickHouse много табличных функций. Например, с помощью табличной функции odbc можно обратиться к PostgreSQL, а с помощью url к любым данным на REST-сервере. И все это можно поджойнить:

Примечение: в свежих релизах ClickHouse появилась табличная функция postgresql, движок баз данных PostgreSQL и даже поддержка бинарного протокола PostgreSQL. Кажется это даже слишком круто.

Машинное обучение в ClickHouse

В ClickHouse можно использовать машинное обучение с помощью подключения готовых моделей CatBoost. После объявления модели в конфигурационном файле, она доступна для применения в виде функции modelEvaluate.

Это можно использовать для заполнения пропусков в данных. Пример: компания, занимающаяся недвижимостью, публикует объявления о квартирах с разными параметрами: количество комнат, цена, метраж. Часто некоторые параметры не заполнены например, квадратные метры есть, а количества комнат нет. В этом случае мы можем использовать ClickHouse с моделью CatBoost, чтобы заполнить пропуски в данных.

Более простые модели можно обучать прямо в ClickHouse. Модель машинного обучения у нас будет представлена как агрегатная функция например, стохастическая логистическая регрессия. Задаются гиперпараметры, значение предсказываемой функции и значения фич, причем обучение будет независимым для каждого ключа агрегации, если в запросе указан GROUP BY:

А еще мы можем добавить к агрегатной функции суффикс State:

SELECT stochasticLogisticRegressionState(...

Так можно обучить логистическую регрессию для каждого k и получить состояние агрегатной функции. Состояние имеет полноценный тип данных AggregateFunction(stochasticLogisticRegression(01, 00, 10, 'Adam'), ...), который можно сохранить в таблицу. Достать его из таблицы и применить обученную модель можно функцией applyMLModel:

Но и это еще не все. Мы можем обучить тысячи маленьких простых моделей, записать их в таблицу и сделать джойн из этой таблицы, чтобы применять свою модель для каждого ключа:

Более развернуто описано в этой презентации.

ClickHouse как графовая база данных

Конечно, ClickHouse это не графовая БД и никогда даже не планировался для этого, но тем не менее. Представьте, что таблицы представляют собой ребра графа. С помощью табличной функции можно записывать алгоритмы на графах, например, реализовать алгоритм pagerank:

Это работает, и говорят, даже быстрее, чем некоторые другие графовые базы данных. Разработал его наш друг, один из ведущих контрибьюторов Amos Bird. Правда, эта разработка не доступна в open-source. Но мы не обижаемся.

UDF в ClickHouse

Казалось бы, в ClickHouse нет возможности написать пользовательские функции (user defined functions). Но на самом деле есть. Например, у вас есть cache-словарь с источником executable, который для загрузки выполняет произвольную программу или скрипт на сервере. И в эту программу в stdin передаются ключи, а из stdout в том же порядке мы будем считывать значения для словаря. Словарь может иметь кэширующий способ размещения в памяти, когда уже вычисленные значения будут кэшированы.

И если вы пишете произвольный скрипт на Python, который вычисляет, что угодно пусть те же модели машинного обучения, и подключаете его в ClickHouse, то получаете вы как раз аналог user defined function.

Примечание: полноценная реализация UDF находится в roadmap на 2021 год.

ClickHouse на GPU и как Application Server

Это ещё два необычных примера. В компании nVidia ClickHouse заставили работать на графических ускорителях, но рассказывать я про это не буду.

А наш друг Zhang2014 превратил ClickHouse почти в Application Server. У Zhang2014 есть pull request, где можно определить свои HTTP-хэндлеры и этим хэндлерам приписать подготовленный запрос (SELECT с подстановками или INSERT). Вы делаете POST на какой-то хэндлер для вставки данных, или делаете вызов какой-то GET ручки, передаете параметры, и готовый SELECT выполнится.

Вывод

ClickHouse очень интересная система, в которой всегда можно найти что-то новое, причем, что интересно, что-то новое там всегда могу найти даже я. Многие разработчики удивляют меня тем, что они могут реализовывать внутри ClickHouse всего лишь чуть-чуть поменяв его код. И эти штуки будут работать и в production!