Здравствуйте! Скажите пожалуйста, среди тех, кто хранит логи в ClickHouse, никто не пробовал реализовать аналог grep -C для отображения строчек? То есть, я хочу получить в выводе запроса вида

SELECT datetime, text FROM logs WHERE text LIKE '%something%' ORDER BY datetime DESC

строчки, которые шли до и после каждого найденного совпадения. Как я понял, функция neighbor делает не совсем то, что мне нужно — она возвращает соседние строки из _результата_, а не из исходной таблице. Звучит так, как будто функция для получения соседних результатов из исходной таблицы (пусть тоже в пределах одного блока) тоже должна быть, но я не могу её найти, к сожалению :(

(я также пользуюсь тем фактом, что в ClickHouse есть оптимизация, когда мне результаты такого запроса поступают потоково, если первичный ключ совпадает, поэтому решения с GROUP BY мне тоже не подойдут, скорее всего)

Нейбор работает в пределах блока, т.е. должен сработать

А, неправильно прочнел

Сорри

Добрый вечер. Что будет, если в конфигах двух серверов перепрописать адрес ЗК? Не потеряются ли данные? Хочу развернуть новый ЗК на новой машине, и переключить на нее реплицирование

LIKE '%something%' можно передвинуть в секцию select , размножить neighbor-м на соседние строки , и во внешнем запросе отсечь

потеряются конечно, все развалится нафиг если потеряется база которая в ЗК кластере живет


1. Запустить новые зукиперы указав у них старые ноды ЗК в конфиге. (старые ноды ЗК не надо переконфигурять и перезапускать)
2. дождаться что новые ЗК синхронны и стали фолловерами.
3. Заменить старые ЗК на новые в конфиге КХ
4. перезапустить все КХ (в КХ нельзя заменить ЗК без ребута, наша цель сократитить кол-во ребутов КХ).
5. удалить старые зукиперы из конфигов новых ЗК
7. остановить заливку в КХ
8. остановить старые зукиперы, в этот момент новые ЗК упадут, потеряв кворум.
9. перезапустить новые зукиперы
10. КХ переподключится и уберет read only с таблиц, запустить заливку

Спасибо за идею! Попробую :)

И еще вопроc, как можно в ЗК скинуть аутентификацию на директорию?
криво выполнил на тестовом команду, не хочется переставлять все(
сделал такие команды в ЗК клиенте:
addauth digest default:c0Ndp
setAcl /clickhouse auth:default:c0Ndp
Получил такое:
Unknown perm type: 0
Unknown perm type: N
Unknown perm type: d
Unknown perm type: p

Проверяю и получаю:

[zk: localhost:2181(CONNECTED) 4] get /clickhouse
org.apache.zookeeper.KeeperException$NoAuthException: KeeperErrorCode = NoAuth for /clickhouse

Using superDigest to become a Zookeeper superuser
https://community.cloudera.com/t5/Community-Articles/Zookeeper-Super-User-Authentication-and-Authorization/ta-p/246020
https://community.cloudera.com/t5/Support-Questions/How-to-delete-an-acl-in-zookeeper/td-p/292421

благодарю)
попробую

странно, что он принял ему какую-то аутентификацию, там должно быть так: auth:user:pass:mode

добрый день! подскажите, почему в 20.4.4.18 может отломаться TTL на MergeTree таблице? Раньше вроде бы все было хорошо, а сейчас строки сильно старше (на месяц почти) остаются

Добрый вечер.

Имеется таблица:

CREATE TABLE log (
    `username` String,
    `created_at` Date,
    `action` String,
    `region` String,
    `device` String,
    `url` String
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(created_at)
ORDER BY (created_at, username);

На данный момент в этой таблице содержится 10 миллиардов записей.
Проблема заключается в том, что запросы вида:

SELECT * FROM log WHERE username = 'Ivan';

выполняются больше 10 секунд. Хотелось бы свести время выполнения таких запросов до 1 - 2х секунд.
Может ли кто - то подсказать лучшие практики для решения подобной задачи?
Или использование кликхауза для подобной задачи - не самая лучшая идея?

так это же fullscan

CREATE TABLE log (
    `username` String,
    `created_at` Date,
    `action` String,
    `region` String,
    `device` String,
    `url` String
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(created_at)
ORDER BY (created_at, username);

SELECT * FROM log WHERE username = 'Ivan';

Order by местами поменяйте

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

Блин, на поверхности, спасибо)
А есть еще какие - нибудь "верные" способы оптимизации подобного поиска? Или все сводится к сортировке и верному подбору движка?

добавить в фильтр дату.