Comments 14
Отличная статья.
Но у Elastic или Sphinx есть дополнительное преимущество: в случае сбоя не получим неконсистентные данные между «словарем» и «индексом».
Расскажите, пожалуйста, с какими проблемами столкнулись, при работе с СУБД?
Но у Elastic или Sphinx есть дополнительное преимущество: в случае сбоя не получим неконсистентные данные между «словарем» и «индексом».
Расскажите, пожалуйста, с какими проблемами столкнулись, при работе с СУБД?
Я пока что не сталкивался ни с какими проблемами с ClickHouse, но эту систему мы еще даже не внедрили в эксплуатацию и про подводные камни не могу пока что ничего сказать.
Проблемы при сбоях в случае с индексом для еррор-логов не играют никакой роли, потому что даже полное переиндексирование (заполнение словаря и вставка инвертированного индекса) занимает всего пару минут. Более того, тот же словарь предпочтительно ротировать раз в некоторое время, ибо в еррор-логах часто встречается мусор. Индекс тоже можно ротировать, поскольку обычно для логов поиск слишком глубоко в историю будет требовать неприлично много места, вычислительных ресурсов, или и того и другого.
Проблемы при сбоях в случае с индексом для еррор-логов не играют никакой роли, потому что даже полное переиндексирование (заполнение словаря и вставка инвертированного индекса) занимает всего пару минут. Более того, тот же словарь предпочтительно ротировать раз в некоторое время, ибо в еррор-логах часто встречается мусор. Индекс тоже можно ротировать, поскольку обычно для логов поиск слишком глубоко в историю будет требовать неприлично много места, вычислительных ресурсов, или и того и другого.
Спасибо за статью.
А можете пример конфигов сфинкса привести?
Например, параметр expand_keywords=1 включает выборку по словоформам, но при этом скорость поиска, естественно, падает.
А можете пример конфигов сфинкса привести?
Например, параметр expand_keywords=1 включает выборку по словоформам, но при этом скорость поиска, естественно, падает.
Да, конечно. Кстати говоря, возможно создалось ложное ощущение, что производительность поиска в сфинксе меня не устраивает, это не так. Мне не хочется делать сложную систему с реалтайм-индексом и их периодическим мержем.
Конфиг следующий:
docinfo=extern
mlock=0
expand_keywords=1
min_word_len=2 #в статье для ClickHouse тоже 2
charset_type=utf-8
min_prefix_len=2
enable_star=1
preopen=1
Конфиг действительно позволяет находить сфинксом больше, чем описанная система, однако для поиска для еррор-логам нам это не нужно.
Конфиг следующий:
docinfo=extern
mlock=0
expand_keywords=1
min_word_len=2 #в статье для ClickHouse тоже 2
charset_type=utf-8
min_prefix_len=2
enable_star=1
preopen=1
Конфиг действительно позволяет находить сфинксом больше, чем описанная система, однако для поиска для еррор-логам нам это не нужно.
Спасибо за хорошую статью.
Замечание по сравнению скорости работы sphinx и ClickHouse:
1) время выборки word_id для ClickHouse надо включать во время отработки запроса.
2) enable_star=1 вот это делает индекс сфинкса в порядок выше, и скорость отработки запросов меньше. Уберите этот параметр и сравните еще раз.
Замечание по сравнению скорости работы sphinx и ClickHouse:
1) время выборки word_id для ClickHouse надо включать во время отработки запроса.
2) enable_star=1 вот это делает индекс сфинкса в порядок выше, и скорость отработки запросов меньше. Уберите этот параметр и сравните еще раз.
После пересборки индекса без enable_star и expand_keywords, цифры стали такие:
1) Sphinx: 470 мс
2) ClickHouse: 670 мс
Собственно, я не отрицал, что шаманством с конфигом скорее всего можно достичь более высокой производительности при поиске в сфинксе :). Другой вопрос, что в Sphinx используется обычный индекс, а построенная в статье система позволяет получать обновления в режиме реального времени (у сфинкса перестроение занимает около минуты, реалтайм индексы мы не используем). Я готов поверить, что можно сделать систему на основе сфинкса и реалтайм-поиска, которая будет давать сравнимое время ответа и индексации, и, более того, если бы не желание пощупать ClickHouse, мы бы наверное так и сделали бы в конечном итоге.
1) Sphinx: 470 мс
2) ClickHouse: 670 мс
Собственно, я не отрицал, что шаманством с конфигом скорее всего можно достичь более высокой производительности при поиске в сфинксе :). Другой вопрос, что в Sphinx используется обычный индекс, а построенная в статье система позволяет получать обновления в режиме реального времени (у сфинкса перестроение занимает около минуты, реалтайм индексы мы не используем). Я готов поверить, что можно сделать систему на основе сфинкса и реалтайм-поиска, которая будет давать сравнимое время ответа и индексации, и, более того, если бы не желание пощупать ClickHouse, мы бы наверное так и сделали бы в конечном итоге.
что шаманством с конфигом скорее всего можно достичь более высокой производительности при поиске в сфинксе :)
Это еще не шаманство, это просто правильные настройки. А шаманством можно еще ускорить всё в десятки процентов.
P.S. с enable_star=0 скорость индексации должна существенно возрасти.
P.P.S. hitless_words = all еще ускорит индексацию и поиск
И, на самом деле, интерес представляет сделать наиболее простую в поддержке и в последующем улучшении систему. Я специально подобрал запрос, который выполняется долго, причём на обеих системах, чтобы провести «стресс-тест» и понять, насколько хорошо ClickHouse и Sphinx отнесутся к обработке большого количества документов. Обе системы работают хорошо, и среднее время на поиск по нашей базе ошибок составляет порядка пары сотен миллисекунд. Разница по производительности поиска легко нивелируется увеличением числа шардов — лично для меня главное, чтобы времена не отличались на порядок. Они не отличаются, хотя Sphinx заточен чисто под поиск, а ClickHouse — нет. В этом основная суть статьи :).
Спасибо, очень интересно!
Не могу сказать, что ClickHouse предназначен для полнотекстового поиска.
Но я рад, что всё работает и даже работает нормально.
Если рассматривать сценарий обработки большого количества «точечных» запросов, где не нужно считывать и пересекать большое количество записей, а нужно выполнять большое количество мелких запросов, то всё будет хуже, например, из-за особенностей организации индекса.
Для хранения логов программ в ClickHouse ещё часто используется brute-force решение.
Суть его в том, что в таблицу просто сохраняются тексты сообщений (а также всевозможные их свойства — имя хоста, номер потока, уровень логгирования, время обработки запроса и т. п.). В качестве первичного ключа используется время события.
Для поиска сообщений используется ограничение на диапазон дат и времени и оператор
Также существуют функции
Получается, что осуществляется full scan в диапазоне по времени. Это не лучше. Главное в этом подходе — максимальная простота.
В частности, ClickHouse может сам так хранить свои логи запросов. Это можно включить настройкой
Не могу сказать, что ClickHouse предназначен для полнотекстового поиска.
Но я рад, что всё работает и даже работает нормально.
Если рассматривать сценарий обработки большого количества «точечных» запросов, где не нужно считывать и пересекать большое количество записей, а нужно выполнять большое количество мелких запросов, то всё будет хуже, например, из-за особенностей организации индекса.
Для хранения логов программ в ClickHouse ещё часто используется brute-force решение.
Суть его в том, что в таблицу просто сохраняются тексты сообщений (а также всевозможные их свойства — имя хоста, номер потока, уровень логгирования, время обработки запроса и т. п.). В качестве первичного ключа используется время события.
Для поиска сообщений используется ограничение на диапазон дат и времени и оператор
LIKE (или функция position) для поиска по тексту.Также существуют функции
positionCaseInsensitive, positionCaseInsensitiveUTF8 (их ещё нет в документации).Получается, что осуществляется full scan в диапазоне по времени. Это не лучше. Главное в этом подходе — максимальная простота.
В частности, ClickHouse может сам так хранить свои логи запросов. Это можно включить настройкой
log_queries = 1.
Может кто подскажет: у нас в логах, в одной строке, до 8000 символов. Сможет ли ClickHouse корректно с ними работать?
Будет работать.
Для больших строк имеет смысл сделать следующее:
— при создании таблицы, указать index_granularity (то, что идёт последним параметром) слегка меньше: например, не 8192, а 1024;
— уменьшить значение настройки max_block_size, например, до 8192 (по-умолчанию, 65 536); прописать можно в users.xml для профиля default.
Для больших строк имеет смысл сделать следующее:
— при создании таблицы, указать index_granularity (то, что идёт последним параметром) слегка меньше: например, не 8192, а 1024;
— уменьшить значение настройки max_block_size, например, до 8192 (по-умолчанию, 65 536); прописать можно в users.xml для профиля default.
Sign up to leave a comment.
Разрабатываем систему real-time fulltext-поиска по error-логам на основе ClickHouse от Яндекса