У нас был сервис на golang, отдельный топик kafka, clickhouse, gitlab-ci и падающий пайплайн, протухший ssh-ключ и вот это вот все, а еще сезон отпусков, жуткие ливни в городе, сломавшийся ноутбук, алерты по ночам, и горящий прод. Не то, чтобы это все было нужно для этой статьи, но раз показываешь типичные будни тестировщика, то иди в своем намерении до конца. Единственное, что меня беспокоило — это p0. В мире нет ничего более отчаянного, мрачного и подавленного, чем тестировщик, который пропустил это на прод. Но я знала, что довольно скоро я в это окунусь.
Читать полностью »
Рубрика «clickhouse» - 4
Настройка ClickHouse для интеграционного тестирования в gitlab-ci
2019-07-13 в 10:26, admin, рубрики: clickhouse, docker, sql, интеграционное тестирование, Тестирование IT-системАнализ производительности запросов в ClickHouse. Доклад Яндекса
2019-07-08 в 13:05, admin, рубрики: big data, clickhouse, highload, open source, perf, performance, базы данных, Блог компании Яндекс, высокая производительность, Серверное администрированиеЧто делать, если ваш запрос к базе выполняется недостаточно быстро? Как узнать, оптимально ли запрос использует вычислительные ресурсы или его можно ускорить? На последней конференции HighLoad++ в Москве я рассказал об интроспекции производительности запросов — и о том, что даёт СУБД ClickHouse, и о возможностях ОС, которые должны быть известны каждому.
Каждый раз, когда я делаю запрос, меня волнует не только результат, но и то, что этот запрос делает. Например, он работает одну секунду. Много это или мало? Я всегда думаю: а почему не полсекунды? Потом что-нибудь оптимизирую, ускоряю, и он работает 10 мс. Обычно я доволен. Но все-таки я стараюсь в этом случае сделать недовольное выражение лица и спросить: «Почему не 5 мс?» Как можно выяснить, на что тратится время при обработке запроса? Можно ли его в принципе ускорить?
How to speed up LZ4 decompression in ClickHouse?
2019-06-25 в 14:42, admin, рубрики: bayesian optimization, big data, c++, clickhouse, data compression, databases, highload, lz4, lz77, open source, performance, Блог компании Яндекс, высокая производительностьWhen you run queries in ClickHouse, you might notice that the profiler often shows the LZ_decompress_fast function near the top. What is going on? This question had us wondering how to choose the best compression algorithm.
ClickHouse stores data in compressed form. When running queries, ClickHouse tries to do as little as possible, in order to conserve CPU resources. In many cases, all the potentially time-consuming computations are already well optimized, plus the user wrote a well thought-out query. Then all that's left to do is to perform decompression.
So why does LZ4 decompression becomes a bottleneck? LZ4 seems like an extremely light algorithm: the data decompression rate is usually from 1 to 3 GB/s per processor core, depending on the data. This is much faster than the typical disk subsystem. Moreover, we use all available CPU cores, and decompression scales linearly across all physical cores.
Читать полностью »
Обфускация данных для тестов производительности
2019-06-24 в 9:17, admin, рубрики: big data, c++, clickhouse, compression, data obfuscation, encryption, machine learning, open source, testing, Алгоритмы, базы данных, Блог компании Яндекс, машинное обучениеПользователи ClickHouse знают, что его главное преимущество — высокая скорость обработки аналитических запросов. Но как мы можем выдвигать такие утверждения? Это должно подтверждаться тестами производительности, которым можно доверять. О них мы сегодня и поговорим.
Такие тесты мы начали проводить в 2013 году, задолго до того, как продукт стал доступным в опенсорсе. Как и сейчас, тогда нас больше всего интересовала скорость работы данных сервиса Яндекс.Метрика. Мы уже хранили данные в ClickHouse с января 2009 года. Часть данных записывалась в базу с 2012 года, а часть — была переконвертирована из OLAPServer и Metrage — структур данных, которые использовались в Яндекс.Метрике раньше. Поэтому для тестов мы взяли первое попавшееся подмножество из 1 миллиарда данных о просмотрах страниц. Запросов в Метрике ещё не было, и мы придумали запросы, больше всего интересные нам самим (всевозможные виды фильтрации, агрегации и сортировки).
ClickHouse тестировался в сравнении с похожими системами, например, Vertica и MonetDB. Для честности тестирования его проводил сотрудник, который до этого не был разработчиком ClickHouse, а частные случаи в коде не оптимизировались до получения результатов. Похожим образом мы получили набор данных и для функциональных тестов.
После того, как ClickHouse вышел в опенсорс в 2016 году, к тестам стало больше вопросов.
Как ускорить разжатие LZ4 в ClickHouse
2019-05-21 в 11:14, admin, рубрики: bayesian optimization, big data, c++, clickhouse, highload, lz4, lz77, open source, performance, базы данных, Блог компании Яндекс, высокая производительность, сжатие данныхПри выполнении запросов в ClickHouse можно обратить внимание, что в профайлере на одном из первых мест часто видна функция LZ_decompress_fast. Почему так происходит? Этот вопрос стал поводом для целого исследования по выбору лучшего алгоритма разжатия. Здесь я публикую исследование целиком, а короткую версию можно узнать из моего доклада на HighLoad++ Siberia.
Данные в ClickHouse хранятся в сжатом виде. А во время выполнения запросов ClickHouse старается почти ничего не делать — использовать минимум ресурсов CPU. Бывает, что все вычисления, на которые могло тратиться время, уже хорошо оптимизированы, да и запрос хорошо написан пользователем. Тогда остаётся выполнить разжатие.
Вопрос — почему разжатие LZ4 может быть узким местом? Казалось бы, LZ4 — очень лёгкий алгоритм: скорость разжатия, в зависимости от данных, обычно составляет от 1 до 3 ГБ/с на одно процессорное ядро. Это уже существенно больше скорости работы дисковой подсистемы. Более того, мы используем все доступные ядра, а разжатие линейно масштабируется по всем физическим ядрам.
FAQ по архитектуре и работе ВКонтакте
2019-04-24 в 7:40, admin, рубрики: clickhouse, kittenhouse, kphp, Анализ и проектирование систем, Блог компании Конференции Олега Бунина (Онтико), высокая производительность, Компьютерное железо, хранение данныхИстория создания ВКонтакте есть в Википедии, её рассказывал сам Павел. Кажется, что ее знают уже все. Про внутренности, архитектуру и устройство сайта на HighLoad++ Павел рассказывал еще в 2010 году. Много серверов утекло с тех пор, поэтому мы обновим информацию: препарируем, вытащим внутренности, взвесим — посмотрим на устройство ВК с технической точки зрения.
Алексей Акулович (AterCattus) бэкенд-разработчик в команде ВКонтакте. Расшифровка этого доклада — собирательный ответ на часто задаваемые вопросы про работу платформы, инфраструктуры, серверов и взаимодействия между ними, но не про разработку, а именно про железо. Отдельно — про базы данных и то, что вместо них у ВК, про сбор логов и мониторинг всего проекта в целом. Подробности под катом.
Продуктовая аналитика ВКонтакте на базе ClickHouse
2019-03-26 в 10:52, admin, рубрики: big data, big data analytics, clickhouse, sql, анализ данных, аналитика, базы данных, Блог компании ВКонтакте, Вконтакте, продуктовая аналитика, статистический анализ
Развивая любой продукт, будь то видеосервис или лента, истории или статьи, хочется уметь измерять условное «счастье» пользователя. Понимать, делаем мы своими изменениями лучше или хуже, корректировать направление развития продукта, опираясь не на интуицию и собственные ощущения, а на метрики и цифры, в которые можно верить.
В этой статье я расскажу, как нам удалось запустить продуктовую статистику и аналитику на сервисе с 97-миллионной месячной аудиторией, получив при этом чрезвычайно высокую производительность аналитических запросов. Речь пойдёт о ClickHouse, используемых движках и особенностях запросов. Я опишу подход к агрегации данных, который позволяет нам за доли секунды получать сложные метрики, и расскажу о преобразовании и тестировании данных.
Сейчас у нас около 6 миллиардов продуктовых событий в сутки, в ближайшее время дойдём до 20–25 миллиардов. А дальше — не такими быстрыми темпами поднимемся до 40–50 миллиардов к концу года, когда опишем все интересующие нас продуктовые события.
1 rows in set. Elapsed: 0.287 sec. Processed 59.85 billion rows, 59.85 GB (208.16 billion rows/s., 208.16 GB/s.)
Подробности под катом.
Читать полностью »
Как из-за открытой базы ClickHouse могли пострадать персональные данные пациентов и врачей (обновлено)
2019-03-18 в 5:07, admin, рубрики: clickhouse, shodan, Администрирование баз данных, информационная безопасность, телемедицина, утечка данных, утечка информации, утечки информацииЯ много пишу про обнаружение свободно доступных баз данных практически во всех странах мира, но новостей про российские базы данных, оставленные в открытом доступе почти нет. Хотя недавно и писал про «руку Кремля», которую с перепугу обнаружил голландский исследователь в более чем 2000 открытых базах данных.
Может сложиться неверное представление, что в России все замечательно и владельцы крупных российских онлайн-проектов подходят ответственно к хранению данных пользователей. Спешу развенчать этот миф на данном примере.
Российский медицинский онлайн-сервис DOC+ судя по всему, умудрился оставить в открытом доступе базу данных ClickHouse с логами доступа. К сожалению, логи выглядят настолько детальными, что вероятной утечке могли подвергнуться персональные данные сотрудников, партнеров и клиентов сервиса.
Обо всем по порядку…
Разгоняем обработку событий до 1,6 миллионов в секунду
2019-03-05 в 9:00, admin, рубрики: big data, clickhouse, Hadoop, highload, LSD, php, Блог компании Badoo, Блог компании Конференции Олега Бунина (Онтико), высокая производительность, обработка событий, Разработка веб-сайтовКогда участники HighLoad++ пришли на доклад Александра Крашенинникова, они надеялись услышать про обработку 1 600 000 событий в секунду. Ожидания не оправдались… Потому что во время подготовки к выступлению эта цифра улетела до 1 800 000 — так, на HighLoad++ реальность превосходит ожидания.
3 года назад Александр рассказывал, как в Badoo построили масштабируемую систему near-realtime обработки событий. С тех пор она эволюционировала, в процессе росли объёмы, приходилось решать задачи масштабирования и отказоустойчивости, а в определённый момент потребовались радикальные меры — смена технологического стека.
Из расшифровки вы узнаете, как в Badoo заменили связку Spark + Hadoop на ClickHouse, в 3 раза сэкономили железо и увеличили нагрузку в 6 раз, зачем и какими средствами собирать статистику в проекте, и что с этими данными потом делать.
О спикере: Александр Крашенинников (alexkrash) — Head of Data Engineering в Badoo. Занимается BI-инфраструктурой, масштабированием под нагрузки, руководит командами, которые строят инфраструктуру обработки данных. Обожает всё распределённое: Hadoop, Spark, ClickHouse. Уверен, что классные распределенные системы можно готовить из OpenSource.Читать полностью »
Как без даунтайма масштабировать базы данных в Яндекс.Облаке. Пример с тремя хостами
2018-12-21 в 7:40, admin, рубрики: clickhouse, cloud, database migrations, database tools, mongodb, postgresql, Администрирование баз данных, базы данных, Блог компании Яндекс, облачные сервисы, облачные хранилища, яндексПост подготовили участники команды Яндекс.Облака: Иван Веткасов — архитектор, Леонид Клюев — редактор
Недавно мы рассказали об архитектуре Яндекс.Облака. Теперь давайте перейдем от теории к практике. В Облаке есть несколько сервисов для автоматизированного контроля за СУБД: Managed Service for ClickHouse, Managed Service for PostgreSQL и Managed Service for MongoDB. Все они являются платформенными и позволяют сосредоточиться на задаче хранения данных, а не на администрировании инфраструктуры. Но иногда бывает важно контролировать ещё и виртуальные машины кластера. Например, может возникнуть задача масштабирования в ответ на увеличение или снижение нагрузки. Обычно этот сценарий — один из самых трудоёмких с практической точки зрения. Сегодня мы расскажем, как Яндекс.Облако позволяет автоматизировать сложные задачи масштабирования, и убедимся, что база остаётся доступной в процессе изменения размера кластера.