Какие вещи нужно учесть при переходе от php-агрегатора на ClickHouse?



Поделитесь опытом использования ClickHouse пожалуйста.Задача: сделать разные (желательно adhoc) отчеты по большом объему событий нескольких типов.Сейчас прирост событий в среднем +2000 в сек. Php агрегирует сырые лог-файлы и пишет агрегаты в mysql. Из mysql уже строятся отчеты. Проблема в том, что каждый новый отчет требует нового кода в php-агрегаторе, и при увеличении числа отчетов он сильно усложняется. Хочется что-то более простое в использовании. Поэтому рассматриваем переход на ClickHouse. Пока что присматриваемся, планируем писать события каждого типа в свою таблицу и потом в реалтайме строить для пользователя отчеты. Сейчас делаем замеры - насколько быстро будут работать отчеты по данным за один месяц.Вопросы:1. быстро ли работают joinы в ClickHouse? Для некоторых отчетов придется джойнить большие таблицы.2. какие, возможно, неочевидные вещи нужно учесть при переходе от php-агрегатора на ClickHouse?
1541   69  

Comments

  1. Станислав Осипов
    Станислав Осипов 5 лет назад
    1. Из-за колоночной архитектуры там гораздо эффективнее сильная денормализация БД. Т.е. ты можешь сделать 5000 колонок в таблице и это никак не повлияет на выборку по 3 колонкам.2. Он совсем другой. Нет, например, операции UPDATE. И delete там тоже нетипичный.
    • Павел Вейник
      Павел Вейник 5 лет назад
      1. то есть, следует подумать как свести разные типы ивентов в одну большую таблицу? чтобы избавиться от join?
    • Станислав Осипов
      Станислав Осипов 5 лет назад
      Павел Вейник Да, мы так и сделали.
    • Павел Вейник
      Павел Вейник 5 лет назад
      Станислав Осипов спасибо за направление )
    • Станислав Осипов
      Станислав Осипов 5 лет назад
      Павел Вейник не стоит благодарностей, это в каждом подкасте о нем говорится.
  2. Станислав Осипов
    Станислав Осипов 5 лет назад
    Даже InfiniDB была гораздо ближе к традиционному SQL чем CH.
  3. Антон Герасимов
    Антон Герасимов 5 лет назад
    Лучше скажите, как у CH с потерей данных и консистентностью реплик?
    • Станислав Осипов
      Станислав Осипов 5 лет назад
      Консистентность реплик на 100% ответственность DBA, приставленного к CH. Причем, главный прикол - то, что DBA теперь должен сам админить зукипер и данные в нем.
    • Антон Герасимов
      Антон Герасимов 5 лет назад
      Станислав Осипов Короткая версия - у СН никак с консистентностью и сохранностью данных.
    • Павел Клеменков
      Павел Клеменков 5 лет назад
      А к чему вопрос? Clickhouse он webscale, где на констстентность должно быть плевать до определённого момента.
    • Антон Герасимов
      Антон Герасимов 5 лет назад
      Павел Клеменков webscale - это мантра, которая позволяет любой БД терять данные и быть eventually consistency?Короткий ответ - нет(тм)
    • Павел Клеменков
      Павел Клеменков 5 лет назад
      Погоди, ты сейчас начал натягивать презерватив на глобус, зачем?
    • Антон Герасимов
      Антон Герасимов 5 лет назад
      Павел Клеменков потому что глобус в опасности Потому, что CH имеет узкокоспециализированное применение. Отличный инструмент, если тебе не важна потеря данных и их консистентность и webscale тут не при чем.
    • Paul Tru
      Paul Tru 5 лет назад
      Мне казалось что общим местом является что DBMS не должны терять данные, но видимо господа считают по-другому?
    • Антон Герасимов
      Антон Герасимов 5 лет назад
      Олег Царёв см. выше. TSDB тоже не имеет права пробывать данные.
    • Денис Габайдулин
      Денис Габайдулин 5 лет назад
      Если у вас есть допустим три реплики, то вероятность потерять данные безвозвратно стремится к нулю. Просто гарантия, что после записи вы сразу увидите самые актуальные данные, прочитав их с любой реплики отсутствует.
    • Антон Герасимов
      Антон Герасимов 5 лет назад
      Олег ты не находишь странным противоположность утверждений "за сохранность реплицированных данных можно быть спокойным" и "ответ клиенту выдаётся при записи на одну реплику, кворумной записи нет"?
    • Антон Герасимов
      Антон Герасимов 5 лет назад
      Олег Царёв только про это "если" никто не знает в т.ч и клиент. Так что, можно сказать - если повезёт, то данные сохранятся М на репликах.
    • Антон Герасимов
      Антон Герасимов 5 лет назад
      Олег Царёв а я и не спорю, что СН предназначен для данных, которые можно безболезненно пролюбить. Для того и писался, но потенциал у него больше.
    • Антон Герасимов
      Антон Герасимов 5 лет назад
      Олег Царёв : вот скажи мне, как в финтех аналитике вы боритесь с потерей данных? (Точнее, как определяете факт этой потери)
    • Антон Герасимов
      Антон Герасимов 5 лет назад
      Олег Царёв > скоро эти проблемы станут неактуальными.
    • Антон Герасимов
      Антон Герасимов 5 лет назад
      И зукипер выкинуть. Совсем.
    • Антон Герасимов
      Антон Герасимов 5 лет назад
      Олег Царёв вопрос был в том, как определить что данные в базе и данные в дата-провайдере консистентны?
    • Антон Герасимов
      Антон Герасимов 5 лет назад
      Олег Царёв : Внимательно: как ты проверяешь что не потерял часть данных?Я знаком со спецификой и знаю что по ряду инструментов котировки идут не потоком и есть окна без изменений рынка.
    • Антон Герасимов
      Антон Герасимов 5 лет назад
      Олег Царёв тогда в чем смысл их хранить, если при каждом использовании нужно сверять данные с провайдером, чтоб убедится в их полноте?
    • Антон Герасимов
      Антон Герасимов 5 лет назад
      Олег Царёв другими словами - ты хранишь избыточность и проверяешь наличие точек во всем временном ряду?Тогда это будет работать и твой клиент гарантирует консистентность основываясь на знании бизнес-логики. Это ровно то, что я писал выше - забота о консистентность реплик лежит на клиенте.
    • Антон Герасимов
      Антон Герасимов 5 лет назад
      Олег: >>>>Ну не знаю, мы просто в ордерах выставляем "покупай по рынку", а дальше это забота биржи купить по рынку.
  4. Vitaly Levchenko
    Vitaly Levchenko 5 лет назад
    Возьмите Vertica и не страдайте фигнёй: там отличная документация, удобное обслуживание, честный SQL и всё что вам надо — быстро.
    • Павел Клеменков
      Павел Клеменков 5 лет назад
      А для всего остального есть мастеркард?
    • Павел Вейник
      Павел Вейник 5 лет назад
      Виталий, спасибо. Посмотрю что это такое
    • Павел Клеменков
      Павел Клеменков 5 лет назад
      Лучше сразу на ценник смотреть)
    • Павел Вейник
      Павел Вейник 5 лет назад
      Павел Клеменков ога, уже запросил их sales
    • Vitaly Levchenko
      Vitaly Levchenko 5 лет назад
      1Tb и 3 ноды полностью бесплатно. Таких кластеров можно делать много.
    • Павел Вейник
      Павел Вейник 5 лет назад
      Vitaly Levchenko у них же нельзя использовать для коммерческих целей даже бесплатную версию
    • Vitaly Levchenko
      Vitaly Levchenko 5 лет назад
      Павел, впервые слышу об этом ограничении, у них на сайте его не нашёл.
    • Павел Вейник
      Павел Вейник 5 лет назад
      "You may not use software to provide services to third parties." при скачивании community edition. Это выглядит очень общо, как ограничение на коммерческое использование.
    • Vitaly Levchenko
      Vitaly Levchenko 5 лет назад
      Я бы не парился на вашем месте.
    • Павел Вейник
      Павел Вейник 5 лет назад
      Vitaly Levchenko а вы пробовали выгружать данные из Вертики? Это сложно-долго или нормально по скорости?
    • Vitaly Levchenko
      Vitaly Levchenko 5 лет назад
      Павел, Vertica в диск обычно упирается.
    • Александр Быков
      Александр Быков 5 лет назад
      Vitaly Levchenko много кластеров это нарушение лицензии, там явно любой шардинг запрещается самопальный
    • Vitaly Levchenko
      Vitaly Levchenko 5 лет назад
      who cares?
    • Павел Вейник
      Павел Вейник 5 лет назад
      так нинада делать
  5. Михаил Петров
    Михаил Петров 5 лет назад
    JOIN не работают для больших таблиц, потому что реализованы в виде подзапросов. Если результат первого подзапроса большой - работать не будет вообще.
  6. Андрей Григорьев
    Андрей Григорьев 5 лет назад
    ClickHouse это отличный инструмент для работы с данными. В частности - для построения отчетов. Но если данных много, то про realtime можно говорить только при наличии сопоставимого количества железа (CH считает всё максимально эффективно, но честно, без кеширования и каких-либо автоматических предагрегаций). Join-ы нужно избегать - денормализация во все поля.
    • Павел Вейник
      Павел Вейник 5 лет назад
      Спасибо за ответ. Мы можем склеить все ивенты в одну большую строку и сохранить в CH. Но проблема в том, что мы это можем сделать только через 48 часов после первого события из цепочки событий - когда уже есть уверенность что не появится новых событий. А отчеты нужно строить и по свежим данным, которые еще нельзя склеить в одну большую строку, потому что 48 часов еще не прошли и могут придти новые события цепочки. 48 часов - это примерно 120Г сейчас, порядка 100М записей, и их придется джойнить, ну или как-то извращаться для реалтайм отчетов.
    • Андрей Григорьев
      Андрей Григорьев 5 лет назад
      Э... я не предлагал эвенты в одну строку склеивать . Как вы пришли к такой мысли?
    • Павел Вейник
      Павел Вейник 5 лет назад
      Андрей Григорьев а они просто просятся, ивенты идут связанными небольшими сериями штук по 5, вот эти серии естественно ложатся как одна строка в CH и убирают все джойны.
    • Андрей Григорьев
      Андрей Григорьев 5 лет назад
      Павел Вейник А покажи плиз пример такой связки евентов?
    • Павел Вейник
      Павел Вейник 5 лет назад
      Андрей Григорьев эм, ну типа ивент1 начало обслуживания - ивент2 событие обслуживания - ивент3 завершения обслуживания, в таком духе. не более 5 ивентов может быть.
    • Павел Вейник
      Павел Вейник 5 лет назад
      каждый со своим набором полей, но все укладываются в эту схему.
    • Андрей Григорьев
      Андрей Григорьев 5 лет назад
      Тогда стоит не в строку склеивать, а нормально наборы полей разделить и писать в одну запись. Ещё в ClickHouse есть такая штука - https://clickhouse.yandex/reference_ru.html... , но я пока не пользовался.
    • Vitaly Levchenko
      Vitaly Levchenko 5 лет назад
      Elastic — это, конечно, надёжное, интерпрайзное решение!
    • Павел Вейник
      Павел Вейник 5 лет назад
      Андрей Григорьев да, разумеется, я имею в виду строку таблицы Не думаю что вложенные структуры тут принципиально что-то решат, вопрос в нахождении соответствия для цепочки ивентов - джойны тут лучше всего, но они в CH тяжелые. Видимо, отчеты за последние 48 часов будем делать ручками, а то что старше - сливать в CH для нормальной обработки в одной большой таблице.
    • Андрей Григорьев
      Андрей Григорьев 5 лет назад
      Vitaly Levchenko да, штука хрупкая, чуть не туда ткнешь - БДЫЩ OOM КИШКИ РЕБАЛАНСИНГ КЛАСТЕР РАСПИДОРАСИЛО
    • Андрей Григорьев
      Андрей Григорьев 5 лет назад
      На самом деле надо просто отдельные client-ноды жирные по оперативке делать и тогда его довольно сложно положить.
    • Андрей Григорьев
      Андрей Григорьев 5 лет назад
      Павел Вейник звучит как лямбда-архитектура) имхо такую склейку и правда лучше где-то вне основного хранилища разруливать, может быть даже кастомным сервисом в оперативке...
    • Андрей Григорьев
      Андрей Григорьев 5 лет назад
      вариант с php + mysql тоже имеет право на жизнь)
    • Андрей Григорьев
      Андрей Григорьев 5 лет назад
      Хотя clickhouse'ом собирать - тоже вполне себе вариант.
    • Павел Вейник
      Павел Вейник 5 лет назад
      Андрей Григорьев вариант с php+mysql уже выпил немало крови. Отчеты не кастомные получаются, а только такие, для которых уже сделана преагрегация. Добавление нового отчета дорогое.
    • Павел Вейник
      Павел Вейник 5 лет назад
      спасибо большое за комментарии