Печально... неужели всегда на hdfs сидеть... надеюсь apache ozon победит )

Добрый день. Есть ли планы по расширению диапазона дат в КХ ?
Диапазон 135 лет с 1970 по 2105-й год маловат.
Даже день рождения у многих вне этого диапазона.
Если, к примеру, в КХ сохранять данные кадрового учета,
то даты придется в строках хранить и накручивать
дополнительную логику для работы с ними.

Вы вовремя пришли :)
https://github.com/ClickHouse/ClickHouse/pull/9404

эээ... вообще вы по моему все в кучу намешали

s3  как object storage не сильно годится для hot данных
ozone работает в экосистеме hadoop и он поможет не clickhouse а скорее таким штукам как Spark \ Hive
потому что это фактически они там пытаются переопределить distributed block storage (доступ на уровне блоков, вместо доступа на уровне файлов) и даже если его смонтировать как блочное устройство в которое пытаться писать с помощью clickhouse. IMHO тоже особо ничего быстрого не будет слишком много оверхеда
хотя если HDDS будет лучше чем amazon EBS , то возможно что-то дельное и получится, но я в этом сильно сомневаюсь

https://clickhouse.tech/docs/ru/sql-reference/data-types/datetime64/
В документации написано, что в DateTime64 хранятся "с момента начала эпохи (1970-01-01 00:00:00 UTC)".
Где правда ?

PR вмержили только вчера, дока скорее всего еще не обновлена

Ch  может использовать как hdfs, s3, kafka, merge3. Получается универсальный комбайн

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

Есть комбинатор -resample

Подскажите пожалуйста возможно ли в кх импортировать/вставить массив данных с 1 запросом по http?

Например есть примерно такой массив json данных:

[
    {"moscow":"russia"},
    {"berlin":"germany"}
]

что такое Merge3 ? MergeTree имеется ввиду?
не получится у вас никакого универсального комбайна

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

[
    {"moscow":"russia"},
    {"berlin":"germany"}
]

Это одна строка или две?

2 строка в массиве. Просто я хотел добавить больше 1 строк в 1 запросе по HTTP

И как вы сейчас json загружаете?

Я пока таким образом вставляю 1 строку в таблицу:

$ echo '{"moscow":"russia"}' | curl 'http://localhost:8123/?query=INSERT%20INTO%20test%20FORMAT%20JSONEachRow' --data-binary @-

А больше 1 строк данных через цикл.

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

привет
подскажите, пожалуйста, как работает эта магия?

делаем запрос вида

SELECT
    foo,
    (1234 * bar) as bar,
    toDate(bar) as _date
FROM lolkek
GROUP BY foo, bar

Когда мы делаем

toDate(bar)

, то здесь уже берется

bar

не из оригинальной таблицы, а вычисленное значение

1234 * bar

В обычном SQL, насколько я знаю, такого нет, т.е. нет зависимых столбцов в запросах. Почему здесь это так работает?

SELECT
    foo,
    (1234 * bar) as bar,
    toDate(bar) as _date
FROM lolkek
GROUP BY foo, bar

toDate(bar)

bar

1234 * bar

Потому что в кх автору захотелось что бы работало

Select 5*b as x
Group by x
Order by x

Это класно. Теперь у нас несовместимый классный sql.

спасибо

Всем привет)
Не подымается кх, подскажите пожалуйста куда капать?

2021.03.18 11:33:27.734584 [ 283 ] {} <Fatal> BaseDaemon: ########################################
2021.03.18 11:33:27.734750 [ 283 ] {} <Fatal> BaseDaemon: (version 20.8.11.17 (official build), build id: 043CBA0C5D760D9A) (from thread 88) (no query) Received signal Segmentation fault (11)
2021.03.18 11:33:27.734839 [ 283 ] {} <Fatal> BaseDaemon: Address: NULL pointer. Access: read. Address not mapped to object.
2021.03.18 11:33:27.734915 [ 283 ] {} <Fatal> BaseDaemon: Stack trace: 0x164ca9b0 0x1646cb0d 0x163e821b 0x16038e7d 0x16039fe4 0x155611cd 0x1558415e 0x160140e7 0x16014b79 0x15717c29 0x157180b2 0x157181e2 0xe65fba7 0xe65e093 0x7f4a8cb32609 0x7f4a8ca48293
2021.03.18 11:33:27.735055 [ 283 ] {} <Fatal> BaseDaemon: 3. DB::JSONEachRowRowInputFormat::readPrefix() @ 0x164ca9b0 in /usr/bin/clickhouse
2021.03.18 11:33:27.735161 [ 283 ] {} <Fatal> BaseDaemon: 4. DB::IRowInputFormat::generate() @ 0x1646cb0d in /usr/bin/clickhouse
2021.03.18 11:33:27.735247 [ 283 ] {} <Fatal> BaseDaemon: 5. DB::ISource::work() @ 0x163e821b in /usr/bin/clickhouse
2021.03.18 11:33:27.735326 [ 283 ] {} <Fatal> BaseDaemon: 6. ? @ 0x16038e7d in /usr/bin/clickhouse
2021.03.18 11:33:27.735432 [ 283 ] {} <Fatal> BaseDaemon: 7. DB::KafkaBlockInputStream::readImpl() @ 0x16039fe4 in /usr/bin/clickhouse
2021.03.18 11:33:27.735566 [ 283 ] {} <Fatal> BaseDaemon: 8. DB::IBlockInputStream::read() @ 0x155611cd in /usr/bin/clickhouse
2021.03.18 11:33:27.735660 [ 283 ] {} <Fatal> BaseDaemon: 9. DB::copyData(DB::IBlockInputStream&, DB::IBlockOutputStream&, std::__1::atomic<bool>*) @ 0x1558415e in /usr/bin/clickhouse
2021.03.18 11:33:27.735758 [ 283 ] {} <Fatal> BaseDaemon: 10. DB::StorageKafka::streamToViews() @ 0x160140e7 in /usr/bin/clickhouse
2021.03.18 11:33:27.735843 [ 283 ] {} <Fatal> BaseDaemon: 11. DB::StorageKafka::threadFunc() @ 0x16014b79 in /usr/bin/clickhouse
2021.03.18 11:33:27.735927 [ 283 ] {} <Fatal> BaseDaemon: 12. DB::BackgroundSchedulePoolTaskInfo::execute() @ 0x15717c29 in /usr/bin/clickhouse
2021.03.18 11:33:27.736011 [ 283 ] {} <Fatal> BaseDaemon: 13. DB::BackgroundSchedulePool::threadFunction() @ 0x157180b2 in /usr/bin/clickhouse
2021.03.18 11:33:27.736093 [ 283 ] {} <Fatal> BaseDaemon: 14. ? @ 0x157181e2 in /usr/bin/clickhouse
2021.03.18 11:33:27.736181 [ 283 ] {} <Fatal> BaseDaemon: 15. ThreadPoolImpl<std::__1::thread>::worker(std::__1::__list_iterator<std::__1::thread, void*>) @ 0xe65fba7 in /usr/bin/clickhouse
2021.03.18 11:33:27.736264 [ 283 ] {} <Fatal> BaseDaemon: 16. ? @ 0xe65e093 in /usr/bin/clickhouse
2021.03.18 11:33:27.736427 [ 283 ] {} <Fatal> BaseDaemon: 17. start_thread @ 0x9609 in /usr/lib/x86_64-linux-gnu/libpthread-2.31.so
2021.03.18 11:33:27.736522 [ 283 ] {} <Fatal> BaseDaemon: 18. clone @ 0x122293 in /usr/lib/x86_64-linux-gnu/libc-2.31.so