Regexp начинается с не работающего Elasticsearch 6. *

Question

У меня возникли проблемы с пониманием механизма регулярных выражений в ElasticSearch.У меня есть документы, которые представляют единицы собственности:

{
    "Unit" :
    {
         "DailyAvailablity" : 
         "UIAOUUUUUUUIAAAAAAAAAAAAAAAAAOUUUUIAAAAOUUUIAOUUUUUUUUUUUUUUUUUUUUUUUUUUIAAAAAAAAAAAAAAAAAAAAAAOUUUUUUUUUUIAAAAAOUUUUUUUUUUUUUIAAAAOUUUUUUUUUUUUUIAAAAAAAAOUUUUUUIAAAAAAAAAOUUUUUUUUUUUUUUUUUUIUUUUUUUUIUUUUUUUUUUUUUUIAAAOUUUUUUUUUUUUUIUUUUIAOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUIAAAAAAAAAAAAOUUUUUUUUUUUUUUUUUUUUIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
    }
}

Поле DailyAvailability указывает на наличие имущества по дням в течение следующих двух лет с сегодняшнего дня.«A» означает «доступно», «U» недоступно, «I» может зарегистрироваться, «O» может проверить.Как я могу написать фильтр регулярных выражений, чтобы получить все единицы, которые доступны в определенные даты?

Я попытался найти подстроку 'A' с определенной длиной и смещением в поле DailyAvailability.Например, чтобы найти единицы, которые будут доступны в течение 7 дней за 7 дней с сегодняшнего дня:

{
 "query": {
   "bool": {
     "filter": [
        {
         "regexp": { "Unit.DailyAvailability": {"value": ".{7}a{7}.*" } }
        }
      ]
    }
  }
}

Этот запрос возвращает экземпляр единицы с DateAvailability, который начинается с «UUUUUUUUUUUUUUUUUUUUUIAAIA», но содержит подходящие последовательности где-то внутри поля,Как я могу закрепить регулярное выражение для всей исходной строки?ES документы говорят, что регулярное выражение lucene должно быть привязано по умолчанию.

PS Я пробовал '^.{7}a{7}.*$'.Возвращает пустой набор.

Answer 1

Просто помимо блестящего и полезного ответа Николая Васильева.В моем случае я был вынужден пойти дальше, чтобы он работал на NEST .net.Я добавил отображение атрибутов в DailyAvailability:

[Keyword(Name = "DailyAvailability")]
public string DailyAvailability { get; set; }

Фильтр все еще не работал, и я получил отображение:

 "DailyAvailability":"type":"text",
     "fields":{  
         "keyword":{  
             "type":"keyword",
             "ignore_above":256
         }
      }
 }

В моем поле содержалось около 732 символов, поэтомубыл проигнорирован индексом .Я попытался:

[Keyword(Name = "DailyAvailability", IgnoreAbove = 1024)]
public string DailyAvailability { get; set; }

Это не имело никакого значения при отображении.И только после добавления ручных сопоставлений он начал работать правильно:

var client = new ElasticClient(settings);
client.CreateIndex("vrp", c => c
    .Mappings(ms => ms.Map<Unit>(m => m
        .Properties(ps => ps
            .Keyword(k => k.Name(u => u.DailyAvailability).IgnoreAbove(1024))
        )
     )
  ));

Суть в том, что :

ignore_above - не индексировать ни одну строку длиннее этойзначение.По умолчанию 2147483647, поэтому все значения будут приняты.Однако обратите внимание, что правила динамического сопоставления по умолчанию создают поле вспомогательного ключевого слова, которое переопределяет это значение по умолчанию, устанавливая ignore_above: 256.

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

Answer 2

Похоже, вы используете text тип данных для хранения Unit.DailyAvailability (который также используется по умолчанию для строк, если вы используете динамическое отображение ).Вам следует рассмотреть возможность использования keyword типа данных.

Позвольте мне объяснить более подробно.

Почему мое регулярное выражение соответствует чему-то в середине text field?

Что происходит с типом данных text, так это то, что данные анализируются для полнотекстового поиска.Он выполняет некоторые преобразования, такие как нижний регистр и разбиение на токены.

Давайте попробуем использовать Analyze API против вашего ввода:

POST _analyze
{
  "text": "UIAOUUUUUUUIAAAAAAAAAAAAAAAAAOUUUUIAAAAOUUUIAOUUUUUUUUUUUUUUUUUUUUUUUUUUIAAAAAAAAAAAAAAAAAAAAAAOUUUUUUUUUUIAAAAAOUUUUUUUUUUUUUIAAAAOUUUUUUUUUUUUUIAAAAAAAAOUUUUUUIAAAAAAAAAOUUUUUUUUUUUUUUUUUUIUUUUUUUUIUUUUUUUUUUUUUUIAAAOUUUUUUUUUUUUUIUUUUIAOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUIAAAAAAAAAAAAOUUUUUUUUUUUUUUUUUUUUIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
}

Ответ:

{
  "tokens": [
    {
      "token": "uiaouuuuuuuiaaaaaaaaaaaaaaaaaouuuuiaaaaouuuiaouuuuuuuuuuuuuuuuuuuuuuuuuuiaaaaaaaaaaaaaaaaaaaaaaouuuuuuuuuuiaaaaaouuuuuuuuuuuuuiaaaaouuuuuuuuuuuuuiaaaaaaaaouuuuuuiaaaaaaaaaouuuuuuuuuuuuuuuuuuiuuuuuuuuiuuuuuuuuuuuuuuiaaaouuuuuuuuuuuuuiuuuuiaouuuuuuuuuuuuuuu",
      "start_offset": 0,
      "end_offset": 255,
      "type": "<ALPHANUM>",
      "position": 0
    },
    {
      "token": "uuuuuuuuuuuuuuiaaaaaaaaaaaaouuuuuuuuuuuuuuuuuuuuiaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
      "start_offset": 255,
      "end_offset": 510,
      "type": "<ALPHANUM>",
      "position": 1
    },
    {
      "token": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaouuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuiaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
      "start_offset": 510,
      "end_offset": 732,
      "type": "<ALPHANUM>",
      "position": 2
    }
  ]
}

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

Вот почему теперь regexp query ".{7}a{7}.*" будет соответствовать: есть токен, который на самом деле начинается с большого числа a, что является ожидаемым поведением из regexp запроса.

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

Как я могу сделать запрос regexp для всей строки?

Это очень просто: не применять анализаторы.Тип keyword хранит указанную вами строку как есть.

При таком сопоставлении:

PUT my_regexes
{
  "mappings": {
    "doc": {
      "properties": {
        "Unit": {
          "properties": {
            "DailyAvailablity": {
              "type": "keyword"
            }
          }
        }
      }
    }
  }
}

Вы сможете выполнить запрос, подобный этомуэто будет соответствовать документу из сообщения:

POST my_regexes/doc/_search
{
 "query": {
   "bool": {
     "filter": [
        {
         "regexp": { "Unit.DailyAvailablity": "UIAOUUUUUUUIA.*"  }
        }
      ]
    }
  }
}

Обратите внимание, что запрос стал чувствительным к регистру, потому что поле не анализируется.

Этот regexp больше не будет возвращать никаких результатов: ".{12}a{7}.*"

Это будет: ".{12}A{7}.*"

А как насчет привязки?

Регулярные выражения привязаны :

Узоры Люсена всегда привязаны.Предоставляемый шаблон должен соответствовать всей строке.

Причина, по которой было похоже, что привязка была неправильной, была наиболее вероятной, потому что токены были разбиты в анализируемом поле text.

Надеждаэто помогает!