Запросы на уровне термина в Elasticsearch

Вы можете использовать запросы на уровне терминов для поиска документов на основе точных значений в структурированных данных. Примеры структурированных данных включают диапазоны дат, IP-адреса, цены или идентификаторы продуктов.

В отличие от полнотекстовых запросов, запросы на уровне терминов не анализируют условия поиска. Вместо этого запросы на уровне терминов соответствуют точным терминам, хранящимся в поле.

Запросы на уровне терминов по-прежнему нормализуют условия поиска для полей ключевых слов с помощью свойства normalizer.

Типы запросов на уровне терминов

exists запрос

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

fuzzy запрос

Возвращает документы, содержащие термины, похожие на поисковый запрос. Elasticsearch измеряет сходство или нечеткость, используя расстояние редактирования Левенштейна.

ids запрос

Возвращает документы на основе их идентификаторов документов.

prefix запрос

Возвращает документы, содержащие определенный префикс в указанном поле.

range запрос

Возвращает документы, содержащие термины в указанном диапазоне.

regexp запрос

Возвращает документы, содержащие термины, соответствующие регулярному выражению.

term запрос

Возвращает документы, содержащие точный термин в указанном поле.

terms запрос

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

terms_set запрос

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

type запрос

Возвращает документы указанного типа.

wildcard запрос

Возвращает документы, содержащие термины, соответствующие шаблону подстановки.

Читайте также:

Alex tools в Телеграм

Комментарии

Отправить комментарий

Популярные сообщения из этого блога

Язык поисковых запросов в Graylog

Изображение
Синтаксис языка поисковых запросов в Graylog Синтаксис поиска очень близок к синтаксису Lucene. По умолчанию все поля сообщения включены в поиск, если вы не указали поле сообщения, в котором проводить поиск. Сообщения, содержащие термин ssh : ssh Сообщения, содержащие термин ssh или login : ssh login Сообщения, содержащие точную фразу ssh login : "ssh login" Сообщения, в которых поле type содержит ssh : type:ssh Сообщения, в которых поле type включает в себя ssh или login : type:(ssh login) Сообщения, в которых поле type содержит точную фразу ssh login : type:"ssh login" Сообщения с полем type : _exists_:type Сообщения, которые не имеют поля type : NOT _exists_:type Сообщения, которые соответствуют регулярному выражению ethernet[0-9]+ в поле type type:/ethernet[0-9]+/ По умолчанию все термины или фразы в поисковом запросе связаны между собой по логическому типу OR (ИЛИ), поэтому возвращаются все
Далее...

Нормальные формы, пример нормализации в базе данных

Изображение
Кодд представил концепцию нормализации и то, что сейчас известно как первая нормальная форма (1NF) в 1970 году. Кодд продолжал определять вторую нормальную форму (2NF) и третью нормальную форму (3NF) в 1971 году, также Кодд и Рэймонд Ф. Бойс определили нормальную форму Бойса-Кодда (BCNF) в 1974 году. Неформально отношение реляционной базы данных часто описывается как "нормализованное", если оно соответствует третьей нормальной форме. Большинство отношений 3NF не содержат аномалий вставки, обновления и удаления. Нормальные формы (от наименее нормализованных до наиболее нормализованных): UNF: ненормализованная форма 1NF: первая нормальная форма 2NF: вторая нормальная форма 3NF: третья нормальная форма EKNF: Элементарный ключ, нормальная форма BCNF: нормальная форма Бойса-Кодда 4NF: четвертая нормальная форма ETNF: нормальная форма основного кортежа 5NF: пятая нормальная форма DKNF: нормальная форма ключа домена 6NF: шестая нормальная форма UNF (1970) 1NF (1
Далее...

Хэш-таблица: разрешение коллизий

Изображение
Хэш-коллизии практически неизбежны при хэшировании случайного подмножества большого набора возможных ключей. Например, если 2450 ключей хэшируются в миллион корзин (buckets), даже при совершенно равномерном случайном распределении, в соответствии с проблемой дня рождения, существует приблизительно 95% вероятность того, что по крайней мере два ключа будут хэшированы в один и тот же слот. Поэтому почти все реализации хэш-таблиц имеют некоторую стратегию разрешения коллизий для обработки таких событий. Некоторые общие стратегии описаны ниже. Все эти методы требуют, чтобы ключи (или указатели на них) были сохранены в таблице вместе со связанными значениями. Отдельная цепочка В методе, известном как отдельная цепочка , каждая корзина (bucket) независима и имеет своего рода список записей с одинаковым индексом. Время для операций с хэш-таблицами - это время нахождения корзины (bucket) (которое является постоянным) плюс время для операции со списком. В хорошей хэш-таблице каждая корзина (
Далее...