У меня продолжение вчерашнего вопроса: как при вставке в таблицу в default в середине таблицы - пропустить это значение, чтоб оно сработало из default как раз?

за 200 баксов в месяц можно кластер из трех i7 32гиговых собрать в хетзнере

@milovidov_an Алексей хотел бы услышать ваше мнение на счет clickhouse, почему он такой прожорливый или может мы делаем что-то не так

ну у вас в память оно явно не влезает, а хранилище у амазона по дефолту тормозное

сколько иовейт-то?

почти 0-1% всегда

ну тогда надо знать запрос:) сожрать 100м рядами одно ядро не сложно) мы же не знаем чего ты там считаешь.

Как раз статья на тему - сравнение ClickHouse на AWS с физическим сервером и с Redshift: https://www.altinity.com/blog/2017/6/20/clickhouse-vs-redshift

Читаю это. И видно что люди занимаются тем же самым - нормализуют строки. все пытаются нормализовать строки :)

@milovidov_an Алексей хотел бы услышать ваше мнение на счет clickhouse, почему он такой прожорливый или может мы делаем что-то не так

Да потому что это OLAP. В отличие от того же PG работает в множестве потоков и максимально мобилизует ресурсы сервера для выполнения запроса.

Может там что-то конкретное тормозит - типа asc? Или toString?

load average 1.5

оно таки влезает в память судя по объему

эти 3 запроса выполняются каждые 5 секунд по очереди

вот запустились еще парочку запросов для показа статистики. load average 3

3 ядра забито из 4

поле с датой используете в where?

если вам графики рисовать, то наверное можно не все вытаскивать, а только последние N минут/секунд

да конечно

а если я хочу посмотреть суммарное количество показателей за месяц

Спотнкулись со словарями. Переопределил dictionaries_config через отдельный файл <yandex> <dictionaries_config>dictionaries.d/*.xml</dictionaries_config> </yandex> По данному пути положил словарь, но он не подхватывается, хотя [root@xdray-3 clickhouse-server]# grep dictionaries_config config-preprocessed.xml <dictionaries_config>dictionaries.d/*.xml</dictionaries_config> Перезапуск сервера не помогает

если положить словарь в /etc/clickhouse-server то все подхватывает

т.е. работает дефолтный патерн <dictionaries_config>*_dictionary.xml</dictionaries_config>

в чем подвох?

а если /etc/clickhouse-server/dictionaries.d/*.xml ?

Максим, попробуй кэшировать эти запросы. У меня разработчики накосячили чуть чуть с демонами и тим вот всем

и не заметили, сервер две недели был в 100% утилизации

кто может подсказать, нормальный синтаксис с join пранировали на Q3?

накинул кэширование - сразу в 0 стало

а если /etc/clickhouse-server/dictionaries.d/*.xml ?

не понял вопрос

показать содержимое чтоль?

и еще попутно. Видел тут много про "DB::NetException: I/O error: Broken pipe:" Какая сейчас ситуация?

есть релиз с фиксом?

Максим, попробуй кэшировать эти запросы. У меня разработчики накосячили чуть чуть с демонами и тим вот всем

объясни плиз. они вроде как по дефолту должны кешироваться самим кх?

да вроде не кэшируется

я просто нгинксом в кэш кидаю, очень годно и удобно

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

мне кажется вы используете кликхаус как-то не так :)

это не замена mysql, это аналитическая базка

где малое количество юзеров делают какое-то количество запросов на огромных наборах данных

и кх в этом великолепен

мы только для статистики её используем

но на основе почти 1 млрд записей мы строит пользователю графики и отчеты

а админу свои отчеты более показательные

про nginx не понял. как ты его связал с кх запросы ведь летят на порт кх

мы используем веб интерфейс кх для запросов

smi2 ?

да

а мы шлем запросы напрямую на порт сервера через драйвер сми2

но та статистика, которая отрисовывается юзерам - предаггрегированная

нам оказалось проще на стороне загрузки раскидывать по разным базам статистику

и с нее делать запросы

если я захочу посмотреть график посекундно мне агрегация не подходит

аггрегируй по секундам :)

схлопнуть 1 млрд в 50 млн не проблема. но это будет по минутам или часам

а при достижении большей нагрузки 50 млн когда нибудь снова привратяться в 1 млрд

я думаю за пол года спокойно

мне кажется ты ожидаешь от кх чего-то невозможного в рамках инсталляции на c2.xlarge

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

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

я очень сомневаюсь, что у яндекса нету "кэша" который копит свежие данные и мгновенно выдает их в метрике

ну так писал миловидов их начальник по clickhouse

в веб интерфейсе я имею в виду

дорого на их объеме такой кэш содержать

я думаю выезжают за счет распределенных запросов

ну user_id это хорошо. решает много проблем

но если нужно построить отчет по всем пользователям суммарный

такой запрос просто повалит сервер на бочок

ну, агрегируйте такой отчет отдельно, в любом случае подобные вещи дико считать по сырой статистике

построить расчет по всем это задача мапредьюса и не реалтаймовая

построить расчет по всем это задача мапредьюса и не реалтаймовая

можно более подробно?

ну, агрегируйте такой отчет отдельно, в любом случае подобные вещи дико считать по сырой статистике

делать вставку дублирующая на таблицу типа agregateMergerTree ?

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

зачем для каждого если у вас проблема с отчетом по всем ?

а вдруг понадобится :)

надо все-все предусмотреть

посекундно

показать содержимое чтоль?

нет, прописать <dictionaries_config>/etc/clickhouse-server/dictionaries.d/*.xml</dictionaries_config>

есть релиз с фиксом?

А он уже в репах?

А он уже в репах?

Это я как бы спрашиваю

Это я как бы спрашиваю

А) ну на прошлой неделе тут в чате говорили что в течение нелели примерно будет. Так что надеемся на этой неделе )

зачем для каждого если у вас проблема с отчетом по всем ?

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

или как

храните сырую стату столько сколько она вам реально нужна, а для отчетов используйте уже схлопнутую по минутам или по 15 минут (не знаю какая вам точность нужна)

+1. Даже кдб такого не выдержит. Из-за этого много статсов. Без этого никуда.

я очень сомневаюсь, что у яндекса нету "кэша" который копит свежие данные и мгновенно выдает их в метрике

метрика выдает отчеты из кх. но у нас 400+ машин и при необходимости используется семплирование.

метрика выдает отчеты из кх. но у нас 400+ машин и при необходимости используется семплирование.

что представляет из себя это сэмплирование?

что представляет из себя это сэмплирование?

Грубо говоря по индексу читается только часть данных в надежде на то, что получится достаточно репрезентативная выборка

что представляет из себя это сэмплирование?

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

а если важно

тогда кликхаус не используют

а тащут ACID базу

а если важно

Тогда и модели данных другие используют

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

нет, прописать <dictionaries_config>/etc/clickhouse-server/dictionaries.d/*.xml</dictionaries_config>

Вроде помогло. Правда я еще одновременно откатился на чуть раньшую версию CH. Но думаю именно абсолютный путь тут помог. Спасибо!

там разная логика для путей начинающихся с / и просто name*.xml

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

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

может быть несколько summing merge tree подойдут.