Лучшая практика/опыт многоязычного поиска

Изучение того, что является лучшей практикой или опытом, используемым для многоязычного индексирования и поиска в elasticsearch. Я прочитал ряд ресурсов, и, насколько я могу его переусердствовать, доступны следующие варианты индексирования:

  • отдельный указатель на язык;

  • тип многополюсного поля для многоязычного поля;

  • отдельное поле для всех возможных языков.

Итак, интересно, каковы побочные эффекты для выбора одного или другого из этих вариантов (или некоторых других, которые я пропустил). Я полагаю, что больше индексов не замедляет работу кластера (если это не какое-то огромное количество языков), поэтому не уверен, что я получу от выбора 2 или 3, за исключением, возможно, более легкого обслуживания.

Любая помощь приветствуется!

ОТВЕТЫ

Ответ 1

Немного старый вопрос, но информация может быть полезной в любом случае. Структура индекса/отображения в основном зависит от вашего использования. Вам нужно использовать все языки одновременно или использовать только один язык?

  • Вариант 1: Например, многоязычный веб-сайт - пользователи просматривают и просматривают только на выбранном им языке. В этом случае мой опыт в том, что index-per-lang будет хорошим решением, особенно если вам нужно легко добавлять и удалять языки. Количество данных разделяется между индексами (преимущество по эффективности). Простая настройка анализаторов для каждого языка, особенно если их настройки различаются только по имени языка. Лично я использую этот вариант для одного из моих проектов.

Общие примечания для параметров 2 и 3. Использование одного из этих параметров дает вам возможность оценивать документы по-разному на основе языка, так как вы можете определить скоринг для каждого языкового поля. Вы можете добавлять новые поля к сопоставлению, если вам нужно добавить больше языков, но нет способа удалить или изменить существующие поля. Следовательно, вам нужно будет повторно проиндексировать весь свой контент и установить свойство для удаленного языка на пустой. Вам нужно будет добавить новые анализаторы для каждого нового языка. Но сначала необходимо закрыть индекс и открыть его после внесения изменений.

  • Вариант 2. Если вам требуется поиск на всех языках сразу, то многопользовательское поле предоставляет вам самый простой доступ, так как вы можете сразу обращаться ко всем своим подполям
    "book_title": {
        "type": "multi_field",
        "fields": {
            "english": {
                "type": "string"
            },
            "german": {
                "type": "string"
            },
            "italian": {
                "type": "string"
            },
        }
    }

Здесь вы можете искать на определенном языке (например, "book_title.english" ) или на всех языках (используя "book_title" ). Вы должны быть осторожны не, чтобы обновить поле, используя имя "book_title" , но используя "book_title. [Language]". Использование "book_title" приведет к обновлению всех подполей с идентичными данными (что, вероятно, не так, как вы хотите)

  • Вариант 3: Полностью отдельные поля - вам нужно будет поместить их все в поисковый запрос, если вам нужно искать, как в варианте 2, более безопасным с точки зрения индексирования, поскольку вы не можете перезаписывать все языки по ошибке

  • Идея для варианта 4 - использование типа на языке: может использоваться, если у вас есть только один тип документов. Вы можете иметь разные поля для каждого языка. Не полезно, если у вас несколько типов документов.

Ответ 3

Я бы выбрал вариант 1 (отдельный индекс для каждого языка), как это предлагается в документации Elasticsearch, поскольку он позволяет избежать проблем с частотой терминов.

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

Ответ 4

Я думаю, что все зависит от варианта использования. Я думаю, что вариант 1 не будет оптимальным, если у нас есть несколько полей со смешанными языками (локаль), так как было бы много избыточных данных для не локализуемых полей. Вариант 2 может быть лучше в этом случае.