Ну так я так и делаю
yandex>
       <dictionary>
               <name>Источник</name>
               <source>
                       <odbc>
                               <connection_string>DSN=postgresConnection</connection_string>
                               <table>Источник</table>
                       </odbc>
               </source>
               <layout>
                       <complex_key_hashed />
               </layout>
               <structure>
                       <key>
                       <attribute>
                               <name>primarykey</name>
                               <type>UUID</type>

                       </attribute>
                       </key>
                       <attribute>
                               <name>createtime</name>
                               <type>DateTime</type>
                               <null_value>0000-00-00 00:00:00</null_value>
                       </attribute>
...

Или что-то не так?

В смысле через
CREATE Dictionary
?

Добрый день! Столкнулись с проблемой после обновления Clickhouse с версии 19.14.10 до 20.3.10

Перестали работать запросы оптимизации по партициям такого вида:
OPTIMIZE TABLE tableAAA PARTITION today()-1 FINAL;

SQL Error [62]: ClickHouse exception, code: 62, host: mn-hd0068, port: 8123; Code: 62, e.displayText() = DB::Exception:
Syntax error: failed at position 75: FINAL. Expected one of: AND, OR, token, NOT, BETWEEN, LIKE, IS, NOT LIKE, IN, NOT IN, GLOBAL IN, GLOBAL NOT IN, QuestionMark (version 20.3.10.75)


При этом если задавать партицию не функцией - все работает:
OPTIMIZE TABLE tableAAA PARTITION '2020-08-27' FINAL;

Как можно решить эту проблемку?
Спасибо!

Так и задумано, изменили парсинг ключа партицирования

можешь обернуть в tuple

есть столбец с timestamp событиями, надо сделать выборку по событиям за 5 дней, с группировкой по дням. Причем, если такого события нет, то ставится 0 в этот день, если события есть, они суммируются. Как сделать запрос, подскажите?

Спасибо! помогло👍

Добрый день коллеги.
Подскажите пожалуйста на что нужно ориентироваться при выборе колонок для PRIMARY KEY и ORDER BY при создании таблицы?
Хочу сделать таблицу для логирования событий, примерно так:

CREATE TABLE log (`domain_id` UInt32, `provider` String, `value_1` Decimal(9, 2), ... // ещё несколько колонок с данными
`ctime` DateTime DEFAULT toDateTime(NOW())) ENGINE = MergeTree() PARTITION BY ctime 
PRIMARY KEY (domain_id, provider) 
ORDER BY (domain_id, provider, ctime) 
SETTINGS index_granularity = 8192 

важен ли порядок полей в ORDER BY? Должен ли он совпадать с порядком полей в PRIMARY?

select toDate(timestamp) dt, count()
from...
where timestamp >= toStartOfDay(now()) - interval 5 days
group by dt
order by dt with fill

CREATE TABLE log (`domain_id` UInt32, `provider` String, `value_1` Decimal(9, 2), ... // ещё несколько колонок с данными
`ctime` DateTime DEFAULT toDateTime(NOW())) ENGINE = MergeTree() PARTITION BY ctime 
PRIMARY KEY (domain_id, provider) 
ORDER BY (domain_id, provider, ctime) 
SETTINGS index_granularity = 8192 

ориентироваться на будущие запросы. Надо знать какие where будут превалировать.

порядок в primary key важен
порядок в order by и primary key должен совпадать

всем привет! подскажите пожалуйста
нужно сделать запрос вида

select * from events e inner join ( COMPLEX QUERY HERE ) c on c.userId = e.userId and e.datetime between c.date1 and c.date2
умеет ли такое делать КХ ?

asof join пробовал

не умеет. В смысле вам надо перенести в where

select * from events e
    inner join ( COMPLEX QUERY HERE ) c on c.userId = e.userId
where e.datetime between c.date1 and c.date2

КХ делает join только по = , потому что используется hashjoin. И сравниваются (лукап) хеши в хештаблицах

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

COMPLEX QUERY HERE возвращает таблицу вида

contestID userID contestStartDate contestEndDate

1                1           2020-01-01         2020-01-02  
1                2           2020-01-01         2020-01-02
2                2           2020-01-02         2020-01-03
2                3           2020-01-02         2020-01-03

Подскажите плз, можно ли как-то сделать детач нескольким таблицам сразу за один запрос?

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

-n [ --multiquery ]                   multiquery

Это нормальное поведение сортировки после группировки?

SELECT 
    symbol,
    partition
FROM trades_gaps
GROUP BY 
    symbol,
    partition
ORDER BY 
    symbol ASC,
    partition ASC
LIMIT 644, 15

┌─symbol─┬─partition─┐
│ VIBBTC │    201904 │
│ VIBBTC │    202006 │
│ VIBBTC │    202003 │
│ VIBBTC │    202007 │
│ VIBBTC │    201710 │
│ VIBBTC │    202005 │
│ VIBBTC │    201910 │
│ VIBBTC │    201908 │
│ VIBBTC │    201907 │
│ VIBBTC │    201905 │
│ VIBBTC │    201911 │
│ VIBBTC │    201903 │
│ VIBBTC │    202008 │
│ VIBBTC │    201909 │
│ VIBBTC │    201912 │
└────────┴───────────┘

Но, если в скобках, то:

SELECT 
    symbol,
    partition
FROM trades_gaps
GROUP BY 
    symbol,
    partition
ORDER BY (symbol, partition) ASC
LIMIT 644, 15

┌─symbol─┬─partition─┐
│ VIBBTC │    201710 │
│ VIBBTC │    201903 │
│ VIBBTC │    201904 │
│ VIBBTC │    201905 │
│ VIBBTC │    201906 │
│ VIBBTC │    201907 │
│ VIBBTC │    201908 │
│ VIBBTC │    201909 │
│ VIBBTC │    201910 │
│ VIBBTC │    201911 │
│ VIBBTC │    201912 │
│ VIBBTC │    202001 │
│ VIBBTC │    202002 │
│ VIBBTC │    202003 │
│ VIBBTC │    202004 │
└────────┴───────────┘



Наблюдается на версиях: 20.6.4.44 и 20.6.3.28-stable

SELECT 
    symbol,
    partition
FROM trades_gaps
GROUP BY 
    symbol,
    partition
ORDER BY 
    symbol ASC,
    partition ASC
LIMIT 644, 15

┌─symbol─┬─partition─┐
│ VIBBTC │    201904 │
│ VIBBTC │    202006 │
│ VIBBTC │    202003 │
│ VIBBTC │    202007 │
│ VIBBTC │    201710 │
│ VIBBTC │    202005 │
│ VIBBTC │    201910 │
│ VIBBTC │    201908 │
│ VIBBTC │    201907 │
│ VIBBTC │    201905 │
│ VIBBTC │    201911 │
│ VIBBTC │    201903 │
│ VIBBTC │    202008 │
│ VIBBTC │    201909 │
│ VIBBTC │    201912 │
└────────┴───────────┘

SELECT 
    symbol,
    partition
FROM trades_gaps
GROUP BY 
    symbol,
    partition
ORDER BY (symbol, partition) ASC
LIMIT 644, 15

┌─symbol─┬─partition─┐
│ VIBBTC │    201710 │
│ VIBBTC │    201903 │
│ VIBBTC │    201904 │
│ VIBBTC │    201905 │
│ VIBBTC │    201906 │
│ VIBBTC │    201907 │
│ VIBBTC │    201908 │
│ VIBBTC │    201909 │
│ VIBBTC │    201910 │
│ VIBBTC │    201911 │
│ VIBBTC │    201912 │
│ VIBBTC │    202001 │
│ VIBBTC │    202002 │
│ VIBBTC │    202003 │
│ VIBBTC │    202004 │
└────────┴───────────┘

symbol lowCardinality ?