Индексирование данных
Данные в Биллинге хранятся в нескольких базах данных, в основном — в Microsoft SQL и Apache Cassandra. Есть индексирующий процесс, который просыпается по расписанию, вычитывает изменившиеся данные из базы, отправляет их в Elastic. Elastic хранит лишь копию данных, необходимых для поиска.
В чем плюсы такого подхода:
- В отличие от синхронной записи (записали в БД — сразу записали в Elastic) получаем дополнительную отказоустойчивость. Бывает так, что Elastic тупит и не может записать данные (долго собирает мусор, тупанула сеть). Что делать при синхронной записи неясно — данные уже есть в БД, а в Elastic нет, транзакционно записать в Elastic нельзя. Асинхронный процесс гарантирует eventual consistency — данные в конечном счете окажутся в Elastic. Если не получилось записать сразу, то процесс повторит попытку позже;
- Elastic не используется как первичное хранилище. Данные можно безболезненно потерять и пересобрать индекс заново. Пару раз это здорово выручало меня, когда делал изменение схемы данных — я забил на поддержку обратной совместимости, создал новый индекс, накачал его данными и переключил пользователей на чтение из нового индекса.
В чем минусы:
- Есть задержка на появление данных в поиске, поскольку индексирующий процесс работает по расписанию. Задержку можно уменьшать, настраивая время запуска процесса;
- Конкретно в нашей однопоточной схеме — индексация слишком медленная, если данных много. В Биллинге небольшой индекс на десятки гигабайт и несколько десятков миллионов документов. Его индексация занимает 10-12 часов. Не слишком быстро — но пока нас устраивает.
Есть прикольный альтернативный подход к индексации с помощью очереди сообщений — записываем все события по изменению сущностей в очередь Kafka, а потом несколько индексирующих процессов разгребают очередь сообщений и индексируют документы в Elastic. Подход с очередью лучше масштабируется. Пример индексации с помощью очереди можно посмотреть на Github.
Редактирование документа
Для обновления данных в документе нам необходимо сначала его извлечь. Для этого указываем , и документа в методе . Текущие данные можно найти в сегменте . Для обновления данных, просто обращаемся к полям и задаём новые значения. Для сохранения результатов следует вызвать метод update.
$params = array(); $params = 'pokemon'; $params = 'pokemon_trainer'; $params = '1A-001'; $result = $client->get($params); $result = 21; //задаём полю новое значение //добавляем новое поле $result = array( 'Onix' => array( 'type' => 'rock', 'moves' => array( 'Rock Slide' => array( 'power' => 100, 'pp' => 40 ), 'Earthquake' => array( 'power' => 200, 'pp' => 100 ) ) ) ); $params = $result; $result = $client->update($params);
Результат:
Array ( => pokemon => pokemon_trainer => 1A-001 => 2 )
Значение поля будет увеличиваться каждый раз при вызове метода (в том случае, если хоть одно поле было изменено).
Вы можете подумать, что Elasticsearch сохраняет предыдущие версии документа, но это не так. Данный счётчик просто показывает количество обновлений документа.
Кластеры и управление ими
Чтобы получать информацию из распределенной системы, масштаб которой со временем изменяется, нужно определять, когда и к каким сегментам следует обращаться. Поэтому узлы данных объединяются в кластеры, где существуют также координирующие узлы, которые выполняют именно эту функцию.
Кластер
Кластер — это группа узлов с одним и тем же значением атрибута . Если запущен один экземпляр Elasticsearch, то кластер состоит из единственного узла. Все первичные узлы находятся на нем, и он готов к использованию. Но создать на нем реплицированные сегменты невозможно, поэтому в случае сбоя могут быть потеряны данные.
Добавление узлов в кластер повышает его емкость и надежность. Когда в кластер добавляется узел, реплицированные сегменты выделяются автоматически, и его отказоустойчивость повышается.
По умолчанию добавляемый узел может быть как узлом данных, так и master-узлом, который управляет кластером. Рекомендуем помещать в кластер небольшое фиксированное количество узлов, которые могут быть выбраны основными (). Такие узлы отвечают, например, за создание или удаление индекса, отслеживание узлов, которые входят в кластер, и принятие решений о распределении сегментов между узлами. Добавлять же в кластер лучше те узлы данных, которые не могут быть выбраны основными.
Основные узлы обеспечивают управление кластером и позволяют избежать конфликтов между координирующими узлами, например, в случае перемещения сегментов с узла на узел. Поскольку у них есть вся информация о состоянии кластера, таким узлам требуется повышенный объем ресурсов и стабильное оборудование.
Индексирование Документов
ElasticSearch ориентирован на документы. Он хранит и индексирует документы. Индексирование создает или обновляет документы. После индексирования вы можете искать, сортировать и фильтровать полные документы, а не строки столбчатых данных. Это принципиально иной подход к данным, и это одна из причин, по которой ElasticSearch может выполнять сложный полнотекстовый поиск.
Документы представлены в виде объектов JSON. Сериализация JSON поддерживается большинством языков программирования и стала стандартным форматом, используемым движением NoSQL. Она проста, лаконична и легко читается.
Мы собираемся использовать следующие случайные записи для выполнения нашего полнотекстового поиска:
{ "title": "He went", "random_text": "He went such dare good fact. The small own seven saved man age." } { "title": "He oppose", "random_text": "He oppose at thrown desire of no. \ Announcing impression unaffected day his are unreserved indulgence." } { "title": "Repulsive questions", "random_text": "Repulsive questions contented him few extensive supported." } { "title": "Old education", "random_text": "Old education him departure any arranging one prevailed." }
Прежде чем мы сможем проиндексировать документ, нам нужно решить, где его хранить. Возможно иметь несколько индексов, которые, в свою очередь, содержат несколько типов. Эти типы содержат несколько документов, и каждый документ содержит несколько полей.
Мы будем хранить ваши документы по следующей схеме:
текст : Имя индекса. статья : Название типа. id : Идентификатор этого конкретного примера ввода текста.
Чтобы добавить документ, мы собираемся выполнить следующую команду:
curl -XPUT 'localhost:9200/text/article/1?pretty' -H 'Content-Type: application/json' -d ' { "title": "He went", "random_text": "He went such dare good fact. The small own seven saved man age." }'
Здесь мы используем id=1 , мы можем добавлять другие записи, используя ту же команду и увеличенный идентификатор.
Обновление маппинга
Теперь, когда мы еще поднабрались теории, самое время обновить маппинг для нашего индекса. Напомню, что мы работает с датасетом Jeopardy, в котором содержатся данные о вопросах и ответах с различных игр этой популярной американской телевикторины. Итак, мы индексируем следующие поля:
- Категория. Над этим полем мы уже изрядно поработали. Анализатор настроен на работу с автокомплитом и опечаточниками, так что ничего менять не будем.
- Вопрос. Сегодня мы направим свой взор в первую очередь именно на это поле. Наша задача обеспечить качественный полнотекстовый поиск по вопросам датасета. В Elasticsearch есть целый набор языковых анализаторов для текстовых полей. Так как набор данных у нас англоязычный, будем использовать english analyzer. Он дополняет стандартный анализатор стеммером Портера, исключением стоп-слов и пометкой определенных слов языка, не подвергающихся стеммингу.
- Ответ. Не будем ничего придумывать, установим тот же анализатор, что и на предыдущем поле.
- Дата игры. Поле типа date. К этому типу не применяются анализаторы. Установим конкретное представление индексируемых дат(format) и возможность игнорировать нераспарсенные значения (ignore_malformed).
- Цена вопроса. Как и в “Своей Игре” в Jeopardy разным заданиям присваиваются различные суммы денег. Это обычное числовое поле integer, не требующее никакого анализа.
- Раунд. Для этого поля возможно всего 3 значения: Jeopardy!, Double Jeopardy! и Final Jeopardy. Для него идеально подходит тип keywords. Этот текстовый тип не применяет никакие преобразования к содержимому и позволяет выполнять поиск по точному значению.
Так выглядит обновленный маппинг:
{“properties”{“category”{“type”“text”,“analyzer”“phrase”},“question”{“type”“text”,“analyzer”“english”},“answer”{“type”“text”,“analyzer”“english”},“air_date”{“type”“date”,“format”“yyyy-MM-dd”,“ignore_malformed”true},“value”{“type”“integer”},“round”{“type”“keyword”}}}
2 ответа
Лучший ответ
Во-первых, вы должны дважды проверить, что фильтр Ngram действительно то, что вы хотите. Я упоминаю об этом, потому что анализатор ngram обычно используется как при индексации, так и при запросах, так что он обеспечивает нечеткие совпадения. В этом вся суть этого анализатора.
Тебе действительно нужны совпадения, когда пользователь печатает ? Имеет ли это смысл? При реализации автозаполнения люди обычно предпочитают сопоставлять документы, содержащие слова, которые начинаются , с пользовательским вводом, поэтому будут совпадать, и тоже будут, но не . Если это то, что вам нужно, вы должны взглянуть на фильтр «edge_ngram». Это имеет тенденцию улучшать релевантность совпадений, а также не требует много места на диске.
Теперь даже с фильтром «edge_ngram» вам нужно будет отключить ngrams во время запроса. В Hibernate Search это делается путем «переопределения» анализатора.
- Сначала определите второй анализатор, идентичный тому, который вы используете при индексации, но без фильтра «ngram» или «edge_ngram». Назовите это «ngram_query».
-
Затем используйте это для создания вашего построителя запросов:
- Используйте конструктор запросов, чтобы создать свой запрос как обычно.
Обратите внимание, что если вы используете Hibernate Search для передачи схемы индекса и анализаторов в Elasticsearch, вам придется использовать хак для отправки анализатора только для запросов: по умолчанию используются только те анализаторы, которые фактически используются во время индексации. толкнул
См. https: // discourse .hibernate.org / т / не может — найти — в — переопределенное — анализатор — когда — используя — overridesforfield / 1043/4
1
yrodiere
10 Май 2019 в 07:57
Либо вам нужно использовать анализатор времени поиска и очень вероятно, что это будет анализатор ключевых слов во время поиска. Или нужно использовать запрос вместо запроса , который анализируется, что означает, что он использует тот же анализатор, который использовал время индекса.
Подробнее о запросе терминов и запрос соответствия для получения дополнительной информации.
Изменить : — https: //www.elastic.co/guide/en/elasticsearch/reference/current/search-analyzer.html четко говорил об использовании search_analyzer в случае токенайзера edgeNGram и автозаполнение поиска , что в точности соответствует вашему варианту использования.
Opster Elasticsearch Ninja
10 Май 2019 в 07:31
Установка и настройка
Для ОС Fedora есть свой репозиторий. Для того, чтобы установить себе Elastic Search версии 1.4, необходимо добавить в файл /etc/yum.repos.d/ следующие настройки:
name=Elasticsearch repository for 1.4.x packagesbaseurl=http://packages.elasticsearch.org/elasticsearch/1.4/centosgpgcheck=1gpgkey=http://packages.elasticsearch.org/GPG-KEY-elasticsearchenabled=1
После этого установить его можно командой:
yum install elasticsearch
С чего начать?
Elastic Search – база данных с открытым исходным кодом предназначенная для полнотекстового поиска. Она позволяет хранить, анализировать и получать большие объемы данных в режиме реального времени.
Для анализа и поиска Elastic Search использует библиотеку Apache Lucene. Его можно применять при реализации следующих задач:
- Полнотекстовый поиск
- Поиск по параметрам
- Агрегация данных для статистики и их последующая визуализация
- Генерация вариантов для автокомплита
Для работы с данными у Elastic Search есть специальное REST API.
Основные параметры REST API
Если в запросе передать ?pretty=true, то JSON в ответе будет отформатирован таким образом, что его можно будет прочитать.
Добавив параметр ?format=yaml, ответ получим в yaml.
Терминология
В Elastic Search используются такие понятия, как индекс (index), тип (type) и документ (document). Если проводить аналогию с MySQL, то это база данных (database), таблица (table) и рядок (row)
Создание нового индекса
Самый простой вариант создания индекса приведен ниже:
curl -XPUT
Если все прошло нормально, то в ответе мы получим сообщение:
Также при создании индекса можно описать все типы документов, которые будут в нем хранится:
curl -XPOST localhost:9200/test -d ‘{ “mappings” : { “type1” : { “properties” : { “field1” : { “type” : “string”} } } }}‘
5 последних уроков рубрики «PHP»
Когда речь идёт о безопасности веб-сайта, то фраза «фильтруйте всё, экранируйте всё» всегда будет актуальна. Сегодня поговорим о фильтрации данных.
Обеспечение безопасности веб-сайта — это не только защита от SQL инъекций, но и протекция от межсайтового скриптинга (XSS), межсайтовой подделки запросов (CSRF) и от других видов атак
В частности, вам нужно очень осторожно подходить к формированию HTML, CSS и JavaScript кода.
Expressive 2 поддерживает возможность подключения других ZF компонент по специальной схеме. Не всем нравится данное решение
В этой статье мы расскажем как улучшили процесс подключение нескольких модулей.
Предположим, что вам необходимо отправить какую-то информацию в Google Analytics из серверного скрипта. Как это сделать. Ответ в этой заметке.
Подборка PHP песочниц
Подборка из нескольких видов PHP песочниц. На некоторых вы в режиме online сможете потестить свой код, но есть так же решения, которые можно внедрить на свой сайт.
2 ответа
Лучший ответ
Нашел ответ сам и с предложением @jgr:
06 июнь 2018, в 10:43
Поделиться
1
В фильтре ngrams вы определяете min_gram, которая представляет собой минимальную длину созданных токенов. В вашем случае «2» имеет длину: 1, поэтому это игнорируется в фильтрах ngram.
Самый простой способ исправить это — изменить min_gram на 1. Более сложным способом может быть объединение некоторого стандартного анализатора в соответствии с целым ключевым словом (полезным для более коротких терминов) и ngram analzyer для частичного соответствия (для более длинных условий) — возможно, с некоторыми bool запросов.
Вы также можете изменить ngrams, чтобы начать с символов «1», но в поле поиска требуется, по крайней мере, 3 буквы перед отправкой запроса в Elasticsearch.
26 окт. 2017, в 12:20
Поделиться
Ещё вопросы
- Как получить данные используя php и angylarJS
- Chrome больше не отображает текст
- 2Как заставить пользовательский контроллер фабрики ASP.Net MVC
- 1JS Classes: избегать ручного назначения переменных класса
- 1Как изменить ширину / отступ компонента p-меню?
- Как создать шаблон сообщения с полями Drap и Drop HTML 5 JQuery
- 1Совместная функциональность между движками / аддонами Ember
- Специализировать шаблон для набора значений
- 1добавление шрифта Courier в проект
- 2Запрос связанных сущностей с Eager & явной загрузкой не работает в EF для ASP.NET MVC CORE
- Чтобы получить значение из определенного скрытого поля
- Как изменить dayClick на полный календарь, чтобы выделить только определенный день / время
- 1Невозможно очистить корзину после оплаты через PayPal Opencart 2.0.3.1
- 1Локализация устаревшего продукта?
- Настройка UploadSuccessParams в Fineuploader S3
- 1Оповещать в кнопке
- 1Почему некоторые AlertDialogs исчезают при вращении устройства?
- Как добавить лимит в запросе метеора?
- Передача параметров функции в обратный вызов fadeOut
- 2.net делегат без цели медленнее, чем с целью
- Javascript — изменение содержимого div слайд-шоу по таймеру, приводит к наложению всех элементов
- 1Обменять URL с .htaccess
- Bootbox ASP.NET MVC Подтверждения
- Получение NaN вместо числа / значения
- 1Приложение Android работает на эмуляторе и через USB-отладку на устройстве, но не на автономном устройстве
- 1Проблема со слабым сайтом на IE11
- загрузчик mockjax — остановить запуск для определенной функции
- 2Какой хороший консервативный сериализатор памяти заменит BinaryFormatter?
- Как объединить 3 массива
- 2форма доступа из usercontrol
- 1Android-клавиатура искажает вид при закрытии
- Как написать метод, чтобы сложить число и сохранить его в C ++
- Как создать функцию воспроизведения звука
- 2C # — при наведении курсора на панель задач создается предварительный просмотр. Как я могу достичь этого с помощью C # кодирования
- 1Каков наилучший способ использовать mixins в JS?
- 1Получаете куки из веб-просмотра определенного домена?
- Удаление граничной кавычки из JSON
- 2Обрабатывать исключение при использовании Task.Run () в конструкторе пользовательского интерфейса
- 1Matplotlib: вращение фигуры (патча) и применение цветов в python
- 2Как разрешить манипуляции в элементах управления ListView / GridView Item, в то же время разрешая манипуляции с прокруткой и перекрестным скольжением в ListView / GridView?
- Разница между CROSS JOIN и INNER JOIN, LEFT JOIN, RIGHT JOIN, OUTER JOIN
- 1Как использовать regExp, чтобы найти значение в ячейке и поместить в следующую строку в таблице?
- 1показать прогресс загрузки для JSON
- Как найти, где утечка памяти?
- 1Исполнители Java: Как уведомить один ожидающий поток внутри исполнителя?
- 1Почему index = -1, когда элементы существуют в массиве?
- 1Масштабирование встроенного виджета matplotlib в приложении qt, написанном на python
- 1Как изменить цвет текста всплывающей буквы при использовании ListView с включенной быстрой прокруткой?
- У меня проблемы с созданием и выполнением функций-прототипов в программировании на C ++
- 1Создание объектов со случайными входами
Индексирование
Задача сервиса — непрерывно извлекать новые объекты из очереди и индексировать соответствующие документы. В этом процессе мы используем не объектную модель NEST, а низкоуровневую библиотеку ElasticsearchNet. Она предоставляет интерфейс взаимодействия с базой данных через JSON. Объекты формируем динамически обходом в глубину иерархической структуры документа. Для этого используется всем известная библиотека NewtonsoftJson.
Индексирование реализовано многопоточно с параллельной обработкой каждого документа. Процесс формирования JSON занимает на порядок больше времени, чем его индексирование. Поэтому используется API для индексирования отдельных документов, а не Bulk API, при котором за один вызов в ES загружается массив документов. В таком случае индексирование бы происходило со скоростью формирования JSON для самого большого документа.
Индексирование файлов
Файлы индексируются вместе с остальными данными как часть JSON-объекта. Всё, что для это нужно — преобразовать поток байтов в Base64 строку. Это делается средствами стандартной библиотеки. Кроме того, необходимо, чтобы файлы попали под определение процессора. Иначе магии не произойдет, и они так и останутся обычной Base64 строкой. Чтобы при индексировании использовать конвейер, изменим вызов метода.
Нечеткий Поиск
Нечеткое сопоставление рассматривает два слова, которые “нечетко” похожи, как если бы они были одним и тем же словом. Во-первых, нам нужно определить, что мы подразумеваем под нечеткостью.
Elasticsearch поддерживает максимальное расстояние редактирования, указанное с помощью параметра размытость, равное 2. Параметр размытости может быть установлен в значение АВТО, что приводит к следующим максимальным расстояниям редактирования:
- для строк из одного или двух символов
- 1 для строк из трех, четырех или пяти символов
- 2 для строк длиной более пяти символов
вы можете обнаружить, что расстояние редактирования 2 возвращает результаты, которые, по-видимому, не связаны.
Вы можете получить лучшие результаты и лучшую производительность при максимальной нечеткости 1. Расстояние относится к расстоянию Левенштейна, которое является строковой метрикой для измерения разницы между двумя последовательностями. Неофициально расстояние Левенштейна между двумя словами-это минимальное количество односимвольных правок.
Хорошо, давайте проведем наш поиск с нечеткостью:
curl -XGET 'localhost:9200/text/article/_search?pretty' -H 'Content-Type: application/json' -d' { "query": { "match": { "random_text": { "query": "him departure", "fuzziness": "2" } } } }'
И вот результат:
{ "took": 88, "timed_out": false, "_shards": { "total": 5, "successful": 5, "failed": 0 }, "hits": { "total": 4, "max_score": 1.5834423, "hits": } }'
Как мы видим, нечеткость дает нам больше результатов.
Нам нужно осторожно использовать нечеткость, потому что она имеет тенденцию извлекать результаты, которые выглядят несвязанными
Представляем Elasticsearch
Ранее я упомянул, что Elasticsearch похож на базу данных для поиска. Было бы полезно, если бы вы были знакомы с некоторой терминологией вокруг него.
- Field: Поле похоже на пару «ключ-значение». Значение может быть простым значением (string, integer, date) или вложенной структурой, например массивом или объектом. Поле похоже на столбец таблицы в реляционной базе данных.
- Document: документ представляет собой список полей. Это документ JSON, который хранится в Elasticsearch. Это похоже на строку в таблице в реляционной базе данных. Каждый документ хранится в индексе и имеет тип и уникальный идентификатор.
- Type: Тип подобен таблице в реляционной базе данных. Каждый тип имеет список полей, которые могут быть указаны для документов этого типа.
- Index: индекс является эквивалентом реляционной базы данных. Он содержит определение для нескольких типов и хранит несколько документов.
Здесь следует отметить, что в Elasticsearch, когда вы пишете документ в индекс, поля документа анализируются по слову, чтобы сделать поиск простым и быстрым. Elasticsearch также поддерживает геолокацию, поэтому вы можете искать документы, расположенные на определенном расстоянии от определенного места. Именно так Foursquare реализует поиск.
Я хотел бы упомянуть, что Elasticsearch был построен с высокой масштабируемостью, поэтому очень легко создать кластер с несколькими серверами и иметь высокую доступность, даже если некоторые серверы отключаются. Я не собираюсь описывать особенности планирования и развертывания различных типов кластеров в этой статье.
Настраиваем релевантность
В выдаче поиска есть документы разных типов — все они выводятся в одном списке. Некоторые типы документов важнее других, их нужно поднимать в выдаче. Мы чуть-чуть подкрутили поиск, исходя из того, что пользователи ищут чаще:
- Клиенты важнее, чем все остальное (заказы, документы, контакты и прочее);
- Заказы не так важны, как клиенты, но важнее чем все остальное;
- Точное вхождение намного лучше, чем совпадение подстрок.
Мы настроили приоритеты документов с помощью тюнинга запросов. В формуле расчета релевантности для каждого найденного слова настраивается boost — множитель, который увеличивает вес документа, если слово встретилось в нем.
Все запросы мы завернули в с , равным 0. Ни один из этих запросов не влияет на то, подойдет ли документ под критерии поиска, но каждый влияет на релевантность документа. Последний ищет запрос пользователя в поле — специальное поле, которое подвергается минимуму анализа, например, не разбивается на ngram’ы. Если запрос пользователя находится в почти не тронутом анализатором тексте — скорей всего, это именно то, что нужно пользователю.
С настройкой по типу документа есть проблема. Релевантность в Elastic зависит от редкости слова и длины документа. Например, в Биллинге на порядок больше клиентов, чем заявок на работу с клиентами — поэтому Elastic сам поднимает вес заявок, несмотря на множитель . Плюс короткие документы более релевантны. Все это приводит к тому, что некоторых клиентов почти невозможно найти, пока не введешь в поиск точное совпадение.
Можно решить проблему, дальше подтюнивая . Можно переделать UI, чтобы разделить найденные документы по типу. Мы решили пойти третьим путем — заигнорили формулу расчета релевантности при поиске по типу документа с помощью запроса constant_score. Этот запрос дает фиксированный вес в формуле подсчета релевантности, если документ удовлетворяет запросу. В итоге, поиск работает намного предсказуемее, упорядочивает документы детерминировано.
Последний ингридиент — запрос по тексту с вычислением релевантности “по-честному”. Он нужен, чтобы ранжировать документы одинакового типа (Elastic справляется с этим прекрасно). Веса подобраны так, что запросы имеют на порядок больше вес, чтобы не нарушать порядок документов по их типу.
Автодополнение
Автодополнение (autocomplete) подсказывает возможное продолжение строки по мере ее ввода пользователем.
В нашем случае автокомплит должен работать по тем текстовым полям, которые были отмечены соответствующим флагом в утилите администратора. На этапе загрузки маппингов создаётся отдельный индекс для всех дополняющих строк. Это связано с тем, что поиск должен работать на нескольких индексах. Маппинг формируется с полем особого типа completion.
При индексировании документов текст, который нужен для автодополнения, разбивается на наборы термов и загружается в индекс
Термы должны удовлетворять регулярному выражению — для нас важно выделять не слишком короткие и состоящие только из букв слова. Наборы последовательно сдвигаются на один терм, поэтому для каждого слова будет строка в индексе, которая начинается с него
Длина набора ограничена сверху, мы используем completeSize, равный четырем.
Во время поиска для получения автодополнения работает отдельный запрос. При каждом введенном символе происходит обращение к базе данных с соответствующей подстрокой. Запросы к Elasticsearch представляют собой json-объекты. Чтобы получить автокомплит, нам нужен только блок suggest. В него входит Completion Suggester, который позволяет быстро искать по префиксу. Он работает только для completion полей. С другими саджестерами мы ещё встретимся, когда будем обсуждать опечатки.
Вывод
Всего лишь несколькими простыми шагами мы создали мощную поисковую систему на нашем сайте. Чем точнее результат поиска, тем лучше для наших посетителей. Если ваш сайт имеет интенсивный трафик, а одна установка ElasticSearch не может обрабатывать поиск, вы можете добавить в ElasticSearch дополнительные узлы для выполнения распределенного поиска.
Обратите внимание, что по умолчанию ElasticSearch не имеет аутентификации, но вы, вероятно, должны использовать брандмауэр, чтобы ограничить доступ к ElasticSearch с общедоступных IP-адресов. Или, возможно, лучший способ — связать ElasticSearch с внутренним IP-адресом и сделать его доступным только через локальную сеть
Пожалуйста, оставьте комментарий и сообщите нам, как работает ваш сайт после установки этого плагина.