Проанализировано или не проанализировано, что выбрать

Question

Я использую только kibana для поиска ElasticSearch, и у меня есть несколько полей, которые могут принимать только несколько значений (наихудший случай, имя сервера, 30 различных значений).

Я понимаю, что анализ делает с большими, более сложными полями, как это, но с маленькими и простыми я не могу понять преимущества / недостатки анализируемых / не_анализируемых полей.

Итак, каковы преимущества использования analysed и not_analyzed для поля "ограниченный набор значений" (пример. Имя_сервера: server[0-9]*, без специальных символов для разбиения)? Какие типы поиска я потеряю в кибане? Получу ли я какую-либо скорость поиска или дисковое пространство?

Тестируя один из них, я увидел, что версия поля.raw теперь пуста, но kibana по-прежнему помечает поле как проанализированное, поэтому я считаю, что мои тесты неубедительны.

Answer 1

Я постараюсь сделать это проще, если вам нужно больше разъяснений, просто дайте мне знать, и я разработаю лучший ответ.

В поле "анализ" будет создан токен с использованием анализатора, который вы определили для этой конкретной таблицы в вашем отображении. если вы используете анализатор по умолчанию (поскольку вы ссылаетесь на что-то без специальных символов, скажем, сервер [1-9]), то использование анализатора по умолчанию (alnum-lowercase word-braker(это не имя, а то, что он делает в основном)) собираюсь токенизировать:

this -> HelloWorld123
into -> token1:helloworld123

OR

this -> Hello World 123
into -> token1:hello && token2:world && token3:123

в этом случае, если вы выполните поиск: HeL10, он станет -> "привет" и будет соответствовать этому документу, потому что токен "привет" есть.

в случае полей not_analized он вообще не применяет токенизатор, ваш токен - это ваше ключевое слово, так что, как говорится:

this -> Hello World 123
into -> token1:(Hello World 123)

если вы ищете в этом поле "привет мир 123"

не подходит, потому что "чувствителен к регистру" (хотя вы все равно можете использовать подстановочные знаки (Hello*), давайте рассмотрим это в другой раз).

в двух словах:

используйте "проанализированные" поля для полей, которые вы собираетесь искать, и вы хотите, чтобы эластичный поиск их оценил. Пример: заголовки, содержащие слово "работа". запрос:"название: работа".

doc1 : title:developer jobs in montreal
doc2 : title:java coder jobs in vancuver
doc3 : title:unix designer jobs in toronto
doc4 : title:database manager vacancies in montreal

это будет собирать title1 title2 title3.

в этих случаях "анализируемые" поля - это то, что вы хотите.

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

пример:

получить все журналы от server123.

запрос:"Сервер:server123".

doc1 :server:server123,log:randomstring,date:01-jan
doc2 :server:server986,log:randomstring,date:01-jan
doc3 :server:server777,log:randomstring,date:01-jan
doc4 :server:server666,log:randomstring,date:01-jan
doc5 :server:server123,log:randomstring,date:02-jan

результаты только от server1 и server5.

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

проанализировано -> больше места на диске (БОЛЬШЕ, если большие поля анализа). проанализировано -> больше времени для индексации. проанализировано -> лучше для сопоставления документов.

not_analyzed -> меньше места на диске. not_analyzed -> меньше времени для индексации. not_analyzed -> точное совпадение полей или использование подстановочных знаков.

С Уважением,

Даниил