А подскажите, если есть на одном железном сервере 2 отдельных

проца (Debian10) и на этом сервере единнолично установлен демон ClickHouse (все только для него). То есть ли возможность допустим сказать ClickHouse использовать лишь один процессор из 2х.
Или допустим как-то отключить гипертрейдинг (может кто-то эксперементировал с производительностью)?

вы не в ту сторону думаете, надо наоборот. Clickhouse создан для MPP (Massively Parallel Processing), и прежде всего в кластерной конфигурации. Но можно и односерверные. Однако там внутри все сделано для паралелизации - паралельное чтение, паралельные вычисления с мерджем данных ближе к концу пайплайна. Поэтому 1 процессор - это издевательство. Поставьте лучше mysql. сервер для clickhouse лучше начинать строить с 4-х процессоров. Пусть даже с гипертредингом. Но лучше больше. По мере необходимости добавлять ещё сервера.

вы процессоры с ядрами не путаете?

можете конечно попробовать: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_for_real_time/7/html/tuning_guide/isolating_cpus_using_tuned-profiles-realtime

но все же, clickhouse может подходить для накапливания относительно небольшого кол-ва данных за у.е. времени и последующего анализа в рамках одной машины с небольшим кол-ом ядер? Преимущественно для личного использования. Мне кажется, что и для подобных кейсов он может подойти, хоть и рассчитан на работу в кластерах.

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

У меня вот такая история: есть небольшой сервис. Каких-то прям больших нагрузок нет, накапливаю около 10-20gb логов пользовательских событий в месяц. Я их переодически выгружаю, архивирую и дамплю в S3 и на свои HDD. Соотвествтенно, если мне надо их проаналазировать - это превращается в ад с текстовым поискам по кучи архивам. Какое-то серьезное облачное решение для хостинга CH я себе позволить на данном этапе не могу, но предполагаю, что могу связать свой сервис и писать из него логи в локально развернутый CH на одной машине. Какого-то большого кол-ва запросов на чтение быть не может, но вот иметь под рукой полноценный SQL для более удобного анализа данных хочется. Подойдет ли мне для таких целей CH?

В целом можно, Некоторые идеи можно почерпнуть отсюда, https://eng.uber.com/logging/ И даже выгрузку на с3 можно настроить

Большое спасибо за информацию!)

можно взять самую дешёвую виртуалку в хецнере (3.5 евро). поднять там кликхаус. примаунтить диск по цене 4 цента за гигабайт.

по-моему тебе это нужно https://clickhouse.com/docs/ru/operations/utilities/clickhouse-local/

Может ES + кибана лучше? Логи в КХ без сложностей с материализацией превращаются в match(log_column, “regex”). 10-20ГБ не так много на самом деле.

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

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

Буду иметь ввиду, спасибо

hdd у хетцнера нет на виртуалках

SSD для моих задач довольно дорогими выходят( Да и смысла нет в них в данном случае

делить один hdd с десятком других пользователей хостинга - так себе идея. я 10 лет назад с таким имел дело :))

И это тоже

уж лучше s3 движок, он локально хранит индексы, чтобы не приходилось перелопачивать все файлы на каждый чих https://clickhouse.com/docs/ru/engines/table-engines/integrations/s3/

про тот диск, который я писал - он сетевой, там иопсы режутся. разделение между пользователями такое же как у амазона и вроде там никто не жаловался :)

там только ssd с соотв. ценами

Зависит от контекстов ваших поисковых запросов, т.е. какие ожидаются, сколько необходимо rps/qps/etc. Если просто хранить без полнотекстового поиска и постоянных аналитических целей, - хватит даже PostgreSQL, прастити

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

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