Кто нибудь настраивал словари через ODBC?

Как я делал с постгресным драйвером: sudo apt-get install -y unixodbc sudo apt-get install -y odbcinst sudo apt-get install -y odbc-postgresql В /etc/odbc.ini: [DEFAULT] Driver = myconnection [myconnection] Description = PostgreSQL connection to norma Driver = PostgreSQL Unicode Database = norma Servername = 10.... (твой хост) UserName = uname Password = pwd Port = 5432 Protocol = 9.3 ReadOnly = No RowVersioning = No ShowSystemTables = No ConnSettings = <dictionary> <name>table_name</name> <source> <odbc> <table>postgresql_table</table> <connection_string>DSN=myconnection</connection_string> <!— может потребоваться UID=norma;PWD=norma;, но по идее не должно —-> </odbc> </source> <lifetime> <min>300</min> <max>360</max> </lifetime> <layout> <flat/> </layout> <structure> <id> <name>id</name> </id> <attribute> <name>some_column</name> <type>Int32</type> <null_value>-1</null_value> </attribute> ... </structure> </dictionary>

Я чет еще немного подумал, а почему не countIf ?

Это будет то же самое. Хотя сейчас sum(cond) всё-таки работает оптимальнее, но в дальнейшем сделаем, чтобы вообще не было разницы.

Как я делал с постгресным драйвером: sudo apt-get install -y unixodbc sudo apt-get install -y odbcinst sudo apt-get install -y odbc-postgresql В /etc/odbc.ini: [DEFAULT] Driver = myconnection [myconnection] Description = PostgreSQL connection to norma Driver = PostgreSQL Unicode Database = norma Servername = 10.... (твой хост) UserName = uname Password = pwd Port = 5432 Protocol = 9.3 ReadOnly = No RowVersioning = No ShowSystemTables = No ConnSettings = <dictionary> <name>table_name</name> <source> <odbc> <table>postgresql_table</table> <connection_string>DSN=myconnection</connection_string> <!— может потребоваться UID=norma;PWD=norma;, но по идее не должно —-> </odbc> </source> <lifetime> <min>300</min> <max>360</max> </lifetime> <layout> <flat/> </layout> <structure> <id> <name>id</name> </id> <attribute> <name>some_column</name> <type>Int32</type> <null_value>-1</null_value> </attribute> ... </structure> </dictionary>

Спасибо

Это будет то же самое. Хотя сейчас sum(cond) всё-таки работает оптимальнее, но в дальнейшем сделаем, чтобы вообще не было разницы.

спасибо, ценная инфа.

если кому интересно как я делал бэкап curl 'http://localhost:8123/?database=statistics&compress=1' -d 'SELECT * FROM banner_history_segments FORMAT Native' > data.bin

Можно еще бинарник из пакета clickhouse-compressor поставить для таких целей

Можно еще бинарник из пакета clickhouse-compressor поставить для таких целей

а зачем? в чем плюс?

/var/www/html/build# cat data.bin | POST 'http://localhost:8123/?query=INSERT INTO statistics.test FORMAT Native' Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = Exception: Too large string size., e.what() = Exception каким еще способом можно импортнуть дамп ?

А опцию decompress не забыли?

А опцию decompress не забыли?

забылся, работае)) жалко прогресс не показывает. прошлый раз показывало

Ребят, а если используется функция работы с датой над полем date, clickhouse перестает использовать индекс и идет фуллсканить? например так: where toYear(clickhouse_date) = 2016 and toMonth(clickhouse_date) in (2,9)

Может кто скажет как схему выгрузить таблицы?

Может кто скажет как схему выгрузить таблицы?

там файлики есть у кликхауса со схемой

Может кто скажет как схему выгрузить таблицы?

desc table table_name show create table table_name

https://clickhouse.yandex/reference_ru.html#SHOW CREATE TABLE

https://clickhouse.yandex/reference_ru.html#SHOW CREATE TABLE

SHOW TABLES FROM statistics LIKE 'banner_history_segments' INTO OUTFILE test.txt Code: 62, e.displayText() = DB::Exception: Syntax error: failed at position 73 (line 1, col 73): test.txt /*TABIX_QUERY_ID_vKOdebem13K6Ub8_()*/, expected opening single quote, e.what() = DB::Exception\n

как в файл выгрузить схему чтобы потом её заново восстановить ?

А скопировать из консоли религия не позволяет?)

show create table table_name вот это самое то

и тупо скинуть в файлик )

desc table table_name show create table table_name

спасибо

Ребят, а если используется функция работы с датой над полем date, clickhouse перестает использовать индекс и идет фуллсканить? например так: where toYear(clickhouse_date) = 2016 and toMonth(clickhouse_date) in (2,9)

Индекс всё-равно будет использоваться.

Индекс всё-равно будет использоваться.

В чем тогда может быть ошика? Processed rows разный. И для первого запроса processed = количеству :) select count(*) from some_table where toYear(clickhouse_date) = 2016 and toMonth(clickhouse_date) in (10,9) ┌──count()─┐ │ 43349387 │ └──────────┘ → Progress: 252.86 million rows, 505.71 MB (1.28 billion rows/s., 2.57 GB/s.) 1 rows in set. Elapsed: 0.197 sec. Processed 252.86 million rows, 505.71 MB (1.28 billion rows/s., 2.57 GB/s.) :) select count(*) from some_table where clickhouse_date between '2016-09-01' and '2016-10-30' ┌──count()─┐ │ 42621496 │ └──────────┘ 1 rows in set. Elapsed: 0.023 sec. Processed 43.35 million rows, 86.70 MB (1.88 billion rows/s., 3.76 GB/s.)

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

в КХ индексы работают не так, как в мускуле

они отвечают за сегментирование данных на чанки, чтобы кх при запросе просто откидывал ненужные чанки, ускоряя сканирование. т.е. если у нас MergeTree с индексом date - будут эффективно выполняться запросы на ограниченный набор дат, за счёт того что чанки с датами в другом диапазоне просто не будут читаться. по идее, он должен грамотно учитывать функции, по крайней мере у меня во всех запросах используется фильтр toDate(eventDate) BETWEEN 'someDataStr' AND '.....' и это не вызывает проблем

они отвечают за сегментирование данных на чанки, чтобы кх при запросе просто откидывал ненужные чанки, ускоряя сканирование. т.е. если у нас MergeTree с индексом date - будут эффективно выполняться запросы на ограниченный набор дат, за счёт того что чанки с датами в другом диапазоне просто не будут читаться. по идее, он должен грамотно учитывать функции, по крайней мере у меня во всех запросах используется фильтр toDate(eventDate) BETWEEN 'someDataStr' AND '.....' и это не вызывает проблем

Это ясно и понятно. Неясно почему на первый взгляд при одинаковом запросе возвращается разный результат

Либо преобразование даты не отрабатывает. Либо одно из двух (с)

Он в первом варианте, скорее всего сначала выполнил сканирование по первому условию, а потом отфильтровал по второму.

Во втором случае, запрос был более однозначным

Такое не должно быть.

Vladimir В октябре 31 день, может поэтому?

Возможно, из за in(9,10)

Оптимизатор мог решить, что выборку IN не стоит делать в PREWHERE

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

А где оно?

https://clickhouse.yandex/reference_ru.html#Секция PREWHERE

Не думаю что из за этого

Ребят, запросы же разные. Один день выпадает там где between

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

Кстати Андрей попробуй явно указать.

Аа точно

Все гениальное просто.

Не, ребят , проблема не в одном дне

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

а clickhouse-client же показывает, как он оптимизировал запрос?

Я подозреваю что для select count(*) from some_table where toYear(clickhouse_date) = 2016 будет: Processed 252.86 million rows

"Если настройка optimize_move_to_prewhere выставлена в 1, то при отсутствии PREWHERE, система будет автоматически переносить части выражений из WHERE в PREWHERE согласно некоторой эвристике."

проблема в IN

:) select count(*) from osa_posdata where (toMonth(clickhouse_date) = 9 or toMonth(clickhouse_date) =10) and toYear(clickhouse_date) = 2016 ┌──count()─┐ │ 43349387 │ └──────────┘ 1 rows in set. Elapsed: 0.045 sec. Processed 43.35 million rows, 86.70 MB (971.86 million rows/s., 1.94 GB/s.) :) select count(*) from osa_posdata where toMonth(clickhouse_date) in(10,9) and toYear(clickhouse_date) = 2016 ┌──count()─┐ │ 43349387 │ └──────────┘ 1 rows in set. Elapsed: 0.159 sec. Processed 252.86 million rows, 505.71 MB (1.59 billion rows/s., 3.18 GB/s.)

И эта "некоторая эвристика" в данном случае могла посчитать, что нужно сначала выполнить запрос по "toYear(clickhouse_date) = 2016" и уже в полученных данных провести фильтрацию по "toMonth(clickhouse_date) in (10,9)"

Оптимизаторы не любят IN, это да

Но если не предполагается делать IN(7,11) например, то почему бы не взять BETWEEN ? Оптимизатор его понимает значительно лучше

Не проблема. Чуть больше кода на стороне бекенда. Я просто натолкнулся на странность. Вот и написал.

Кстати вопрос, как оптимальнее сравнивать периоды. Через sum и join или через sumif и group by?

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

Но это уже на вкус и цвет)

Мы в Метрике сравниваем вторым способом: - в WHERE указывается OR для обеих периодов, а затем все агрегатные функции считаются с условиями для одного и для второго периода.

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

Как это? Если сравнение периодов, то условия то одинаковые должны быть. Только периоды различаются.

Блин. Я не приведу пример, сам сейчас представить не могу кейс) Думаю, основная причина в том, что я бэкендщик, а не дба, мне проще выдернуть данные и уже в коде с ними работать)

Блин. Я не приведу пример, сам сейчас представить не могу кейс) Думаю, основная причина в том, что я бэкендщик, а не дба, мне проще выдернуть данные и уже в коде с ними работать)

Но ведь это olap, внутри быстрее посчитать ))

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

оно конечно еще сильно зависит от количества данных. Если там 5 строк, то не важно где считать. А у нас просто выхлоп большой(относительно).

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

ну тогда да, тут просто как удобнее.

А я правильно понимаю что вот тут агрегация заняла 8 сек? 2017.04.06 22:27:01.924306 [ 967 ] <Trace> Aggregator: Merging aggregated data 2017.04.06 22:27:02.190420 [ 967 ] <Trace> Aggregator: Aggregation method: keys256 2017.04.06 22:27:10.879413 [ 967 ] <Trace> Aggregator: Aggregated. 36840327 to 921756 rows (from 1018.877 MiB) in 13.021 sec. (2829352.510 rows/sec., 78.250 MiB/sec.) 2017.04.06 22:27:10.879509 [ 967 ] <Trace> Aggregator: Merging aggregated data

Как это? Если сравнение периодов, то условия то одинаковые должны быть. Только периоды различаются.

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

Сначала в PREWHERE выбрать нужные данные в колонки с разными именами, а потом в WHERE доагрегировать их, смерджив периоды

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

я правильно понимаю что мы говорим о запросах вроде такого? select some_field, sumIf(tot_sum,toMonth(clickhouse_date) = 9) as sum1, sumIf(tot_sum,toMonth(clickhouse_date) = 10) as sum2 from some_table where toYear(clickhouse_date) = 2016 and (toMonth(clickhouse_date) = 9 or toMonth(clickhouse_date) =10) group by toMonth(clickhouse_date)

а, если toMonth(), то у вас во-первых some_field не в агрегате, а во вторых какая-то матрица шахматная получится,

ПОдзапросом по идее можно

Сначала в PREWHERE выбрать нужные данные в колонки с разными именами, а потом в WHERE доагрегировать их, смерджив периоды

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

ПОдзапросом по идее можно

да вот меж двух огней и мечусь) JOIN или sumIf)

Я сейчас теоретизирую)

с PREWHERE не экспериментировал пока, а с подзапросом делал подобные выборки

а, если toMonth(), то у вас во-первых some_field не в агрегате, а во вторых какая-то матрица шахматная получится,

ну, для примера сходного с метрикой. У меня есть сайт, и я хочу сравнить количество посещений в 9 месяце с количеством в 10

отчет в метрике делает запрос похожий на ваш, только в нем group by some_field

отчет в метрике делает запрос похожий на ваш, только в нем group by some_field

аааа, все, дошло. Да, агрегация по some_field. Верно.

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

Вначале одним запросом мы получаем что-то типа row1(day=1, sum1=0, sum2=100), row2(day=1, sum1=66, sum2=0), ... и так по каждому дню, а потом группируем по day

если some_field это не время, то получится примерно то , что надо. если время, то будут нули в непересекающихся местах.

если some_field это не время, то получится примерно то , что надо. если время, то будут нули в непересекающихся местах.

нене, это именно аналог сайта/старницы сайта в метрике

у нас аналитика чеков. И сравниваем продажи товара по периодам. Т.е. получается товар | количество в первом периоде | количество во втором

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

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

>подтянул некую оценку кардинальности колонок вот сейчас сложно было)

у нас аналитика чеков. И сравниваем продажи товара по периодам. Т.е. получается товар | количество в первом периоде | количество во втором

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

>подтянул некую оценку кардинальности колонок вот сейчас сложно было)

для каждой колонки есть распределение количества ее значений, в дне, в нескольких днях по различным например клиентам. из этого во-первых можно оценивать "среднюю в вакууме" тяжесть запроса - количество ключей в group by, доля данных которая останется после фильтра column=value, итд. такие метаданные, которые оптимизатор бд обычно собирает в индексы или еще куда чтобы использовать при оптимизации.

но мы верим в prewhere в частности и в clickhouse в целом.

Хм. Вот кстати. Как в запросе для каждого запрашиваемого числового значения получить его процентное отношение к прошлому периоду? т.е., на сколько процентов упали\поднялись посещения\клики\продажи за этот день относительно вчерашнего\на прошлой неделе\в прошлом месяце?

Хм. Вот кстати. Как в запросе для каждого запрашиваемого числового значения получить его процентное отношение к прошлому периоду? т.е., на сколько процентов упали\поднялись посещения\клики\продажи за этот день относительно вчерашнего\на прошлой неделе\в прошлом месяце?

так это вроде простая арифметика, у нас проценты не считаются. Считаются разницы и вектор разницы. Вот так: (Sum_sales_rub1-Sum_sales_rub2) as Growth_abs, (Sum_sales_rub1-Sum_sales_rub2)/greatest(Sum_sales_rub2,1) as Growth_rel

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

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

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

Доброго времени суток! Есть ли разница в порядке указания колонок в индексе? Т.е если создать таблицу с индексом (c1, c2). То при при фильтрации по полю c2 будет ли использоваться индекс? Или он будет использоваться только при фильтрации по c1, по (c1 и с2) ?

Сделал таблички типа ReplacingMergeTree с индексами (с1,с2) и (с2,с1) соответственно. залил в них одинаковые данные. Запрос с фильтром по с1 был значительно менее ресурсоемким к первой табличке (где с1 указано в индексе на первой позиции), а запрос по с2 соответственно ко второй таблице. Осознал, что не понимаю как работают индексы в CH, прокомментируйте пожалуйста.

а распределение у c1 c2 какое?

Добрый день! Подскажите, кто-то собирал ODBC-драйвер под RHEL/Centos 6 ?

Добрый день! Подскажите, кто-то собирал ODBC-драйвер под RHEL/Centos 6 ?

там ж вроде из пакета ставится с полпинка

не совсем, как минимум в rhel6 нет gcc5