Ответы пользователя по тегу ClickHouse
  • Как clickhouse использует ОЗУ при обработке запроса?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Кликхаус относится к классу column-oriented dbms. Это означает что data-row как таковой отсуствует.
    Строк нет. Но есть столбцы которые хранятся физически консолидировано. И когда ты указываешь
    SELECT * то это заставляет кликхаус сделать гораздо больше действий чем надо на самом деле. В
    силу этой колоночатой организации. Сами строки - виртуальны и чтобы их сформировать кликхаус
    должен вычитать физических данных гораздо больше чем реляционка. Столбец - больше чем ячейка.

    Чтоб такая система работала эффективно ты должен ее грузить аналитическими запросами типа

    select avg(amount) from my_table;
    Тогда кликхаус сработает быстрее чем Oracle или PG. В силу этой особенности формата.

    А то что ты делаешь - экспорт во внешние файлы лучше вообще не делать. Или делать редко
    или как-то по другому. Явно это не сильная сторона такой системы.
    Ответ написан
    2 комментария
  • Как максимально сжимать данных в clickhouse?

    mayton2019
    @mayton2019
    Bigdata Engineer
    В парадигме современной BigData, вы должны писать все что приходит на вход.
    Как это там обзывают.... ELT (Extract, Load, Transform)
    Никто не знает наперед какие данные понядоабятся - поэтому фиксируйте весь raw
    трафик. Потом - отфильтруете. Построете материализованные views. Но главное что данные
    будут.

    Учитывая что clickhouse - column oriented - безразлично 2 поля из 2 выбирать или
    2 поля из 2000.

    Если хранилище у вас все таки переполнится - (со скоростью 2.5 Гб в день) то тогда уже почистите те
    колонки которые стали объективно не нужны после например пары месяцев эксплуатации.
    Ответ написан
    Комментировать
  • Как ускорить запросы с group by в ClickHouse?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Да ничего тут нельзя особо сделать. 10 секунд - холодный запуск группировки по 88 млн строк - это вполне себе хорошая цифра. Сомнительно что железо выдавит из себя больше. Ведь так или иначе нужно эти 88 млн пересчитать и даже будь это все в памяти - все равно обойти каждую ячейку. А дальше дело будет только хуже. Ведь табличка растет.

    Есть техники микро-батчинга когда большая задача разбиватеся на порции. Например у тебя есть дневной партишен на 15 млн. Делишь его на часовые. Получается по 625 тыщ строк. Уже лучше.

    Делаешь некую кумулятивную табличку. Типа

    create table charge_cumulative(
      id long,
      cnt_cumulative long,
      delta_sum_cumulative long
    )

    Ну и на каждый микро-батч добавляешь к ней значения count, delta_sum. У тебя вроде удачно получается что можно только складывать.
    Ответ написан
    Комментировать