Question

У меня проблемы с использованием текстового поиска и автозаполнения, потому что у меня есть кусок с документами + 87k, некоторые из них большие (~ 3,4 МБ текста).

Я уже:

Удалены все поля из текстового индекса, кроме title, searchBoost и seoDescription; это единственные поля, скопированные в highSearchText, а поле lowSearchText всегда установлено в пустую строку.
Изменен стандартный текстовый индекс, включая поля type, published и trash в начале этого. Я также изменил запросы, чтобы иметь условия равенства для этих полей. Результат, возвращаемый командой db.aposDocs.stats (), показывает: type_1_published_1_trash_1_highSearchText_text_lowSearchText_text_title_text_searchBoost_text: 12201984 (~11 MB, fits nicely in memory)
Проверено, что этот индекс используется, как в запросе toDistinc, так и в окончательном запросе toArray.

Что, на мой взгляд, является самой большой проблемой

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

Идея, которую я тестирую

В документации MongoDB говорится, что для повышения производительности вся коллекция должна помещаться в ОЗУ (https://docs.mongodb.com/manual/core/index-text/#storage - требования и производительность - затраты , последний пул ).

Итак, я создал отдельную коллекцию с именем «search», содержащую только поля highSearchText (строка, проиндексированная как текст) и highSearchWords (массив, также проиндексированный), в результате чего общий размер составил ~ 19 МБ.

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

Мне пришлось писать события для автоматического обновления Поиск в коллекции, когда фрагмент изменяется, но, кажется, он работает до сих пор.