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

Ну там есть загрузка данных из файла в доке есть это

пытается боец собраться на CentOS 6

[ 63%] Building CXX object utils/config-processor/CMakeFiles/config-processor.dir/config-processor.cpp.o /root/ClickHouse/libs/libdaemon/src/BaseDaemon.cpp: In member function 'void SignalListener::onFault(int, siginfo_t&, ucontext_t&, ThreadNumber) const': /root/ClickHouse/libs/libdaemon/src/BaseDaemon.cpp:375:26: error: 'BUS_MCEERR_AR' was not declared in this scope case BUS_MCEERR_AR: ^~~~~~~~~~~~~ /root/ClickHouse/libs/libdaemon/src/BaseDaemon.cpp:375:26: note: suggested alternative: 'BUS_OBJERR'

Процитирую ридми который писал для наших ОПсов. Configuration of ClickHouse is stored in XML files. With distribution 2 files came: config.xml (main server settings), and users.xml (users, profiles, quotes). Generally best practice is to leave the default configs unchanged, and make all the config changes in separate files. With that new default settings coming in newer versions will be properly set up. All files from conf.d folder will be attached to config.xml All files from users.d folder will be attached to users.xml For each XML node you can set up following attributes: 1) remove="remove" : remove the node from config 2) replace="replace" : replace the node with new variant 3) incl="node_name" : get the node from substitutions file 4) from_zk = "/path/to/node". The element value is replaced with the contents of the node at /path/to/node in ZooKeeper

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

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

в настройках можно указать профиль для системных задач с помощью ключа <system_profile>

Это немного о другом. Для репликации (ReplicatedMergeTree) и так соединяется с лидером без пароля и с пользователем default.

Извините, давно не следил - аналитические/оконные функции ещё не появились?

Понял, а пока не в планах?

Нет, теперь для этого отдельная тулза https://clickhouse.yandex/docs/ru/single/#utils-clickhouse-copier

Коллеги, можете подсказать в чем может быть проблема: при попытке сделать ALTER TABLE ON CLUSTER ADD COLUMN для DistributedMergeTree таблицы получаю такое сообщение: DB::Exception: Table BLA-BLA isn\'t replicated, but shard #2 is replicated according to its cluster definition, e.what() = DB::Exception 11 0

1.1.54370, перевели табличку в распределенный режим, стал ругаться "Too many parts (301). Merges are processing significantly slower than inserts." куда смотреть?

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

Кто подскажет куда копать? Временами CH рестартится сам по себе в логах только <Information> Application: Received termination signal (Terminated) и других намеков на причину нету

вопрос про то, произойдет ли это на server-side или client-side сам умеет увидеть что таблица distributed и получить адреса шардов откуда-нибудь?

У меня в одном из стобцов храняться пути к файлам, я хочу поискать по ним и не могу правильно двоеточие экранировать. Вот такие строчки в КХ c:\ex\abonentsservice\13.91.0.1065_deployments-181833\abonents.exe c:\ex\abonentsservice\13.91.0.1065_deployments-181833\abonents.exe Вот так я пробую select Image from wssg.sysmon_logs where Date=today() and EventId=3 and Image like 'с:\ex%' limit 100 Не работает.

Добрый день! Подскажите, есть ли способ более активно кэшировать данные? Есть таблица из которой постоянно селектят разными однотипными запросами мы знаем, что этот набор, в 99,5% случаев - последние сутки. Но чтение диска происходит "до дыр", практически постоянно данные перечитываются. Отчасти, это проблема со стороны приложения, которое может ждать не более 30сек, потом запрос повторяется.. Но что можно сделать на стороне clickhouse ?

Добрый день! Подскажите, есть ли способ более активно кэшировать данные? Есть таблица из которой постоянно селектят разными однотипными запросами мы знаем, что этот набор, в 99,5% случаев - последние сутки. Но чтение диска происходит "до дыр", практически постоянно данные перечитываются. Отчасти, это проблема со стороны приложения, которое может ждать не более 30сек, потом запрос повторяется.. Но что можно сделать на стороне clickhouse ?

SELECT 'c:\\example' AS path, match(path, '^c:\\\\ex') AS match ┌─path────────┬─match─┐ │ c:\\example │ 1 │ └─────────────┴───────┘ 1 rows in set. Elapsed: 0.001 sec.

use_uncompressed_cache не поможет ли?

а более простым способом никак?

use_uncompressed_cache не поможет ли?

<uncompressed_cache_size>68719476736</uncompressed_cache_size> вот так сейчас, этого должно хватать на неделю данных

а включить не забыли? ? он выключен по дефолту

Для запросов, читающих хоть немного приличный объём данных (миллион строк и больше), кэш разжатых блоков автоматически выключается, чтобы оставить место для действительно мелких запросов. Поэтому, можно держать настройку use_uncompressed_cache всегда выставленной в 1. Можно комментарий? про миллион строк - это про набор данных в запросе или про количество прочитанных строк в исходных данных ?

значит у меня кеш не работает?