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

сто токенов, сто ключей?

сто токенов, сто ключей?

Вот это я ещё хочу проверить но по логике кода - да

понятно

Вчера спать ушёл с этой мыслей, щя вот проснулся думаю

да не очень много вариантов для текстовых индексов то

Надо заглянуть внутренность инде са проверить но по коду - он тупо обычная колекция

Индекс открывают как коллекцию в коде

ну это легко проверить

ну это легко проверить

Как кстати?

если есть .wt хранилище, то его можно через wt посмотреть

если есть .wt хранилище, то его можно через wt посмотреть

О прикольно, спс

wt -h /dbPath/ list

и там дальше wt -h /dbPath/ dump <entity_name>

и там усё видно будет

Ага, буду пробовать посмотреть

но скорее это прост индекс но с другим форматом кодирования ключей

но если это и правда коллекция, то это объясняет почему там пересечения нет и почему «много переписывать» ;)

Дам знать, но реально код странновато выглядет.

В 3.6 они там добавили хак забавный

Щя под рукой нет issue номера

Вообщем stage_text_or меняется на stage_or +fetch если не требуется score. И только потом в stage_text_match отдаётся

Это помогло ускорить выборки, score когда не нужен

Я вот сейчас на все это дело смотрю и задаю вопрос, почему не сделать обычный индекс по каждому токену, потом обычные and or операции поиска по индексу на основе семантики терминов и фраз в запросе, а после убирания дубликата документов или отсечение лишних на and, уже гнать и то, если надо, операции case sensitive сравнений

причины!

вообще текстовые индексы это задачи пересечения множества множеств

вообще текстовые индексы это задачи пересечения множества множеств

Ага, пока что я вижу что самый популярный алгоритм это inverted btree хотя это не совсем логичное название

Вообще в идеале надо связку токен-> список документов.

так обычно оно так и есть

Блин надо до компа добраться. Неужели потому они и используют коллекцию

в обычных не уникальных индексах storage id документа кодируется в префиксе

тьфу

постфиксе

в уникальных индексах складывается в значение

в обычных не уникальных индексах storage id документа кодируется в префиксе

И тогда при поиске поиске по индексу, остаётся выбрать документ по постфиксу при совпадении индекса

да. и сразу дедупликация есть

т.е. один документ с одним префиксом будет в индексе один раз

Что логично

но по этому уникальный индекс может быть на копеечки эффективнее на fetch запросах. так как не надо scan делать

Надо перекопать и может получится сделать свою реализацию с индексацией по токенам но без коллекции а обычным btree но по токенам с ссылкой на документ. Так же как для array делается индекс

да не надо даже ничего городить

Ведь по сути тогда задача сводится к - виртуальному в неком смысле создания массива токенов по которому стоит индекс и в котором уже идёт поиск $in

просто в массив складывать словоформы нормализированыне и по ним индекс ;)

но я не вижу смысла

но я не вижу смысла

Уточни

есть нормальные готовые решения, в которые можно скормить документы и айдишники

и искать там

есть нормальные готовые решения, в которые можно скормить документы и айдишники

Пересечения с другими индексами

ну

Условия по другим ну пусть будет атрибутам

мы получили из хранилища список айдишников и в $in их

вообще мы когда делали такое, мы просто весь документ целиком индексировали

вообще мы когда делали такое, мы просто весь документ целиком индексировали

Да не, понятно что это задача фасетного поиска

распилили весь документ, вместе с ключами, положили в массив и вот пожалуйста

И вопрос индексации и создания выборки фасетной

отлично работало. словоформы не делали, был только prefix search

отлично работало. словоформы не делали, был только prefix search

В elastic search?

нет, прямо в монге

распилили весь документ, вместе с ключами, положили в массив и вот пожалуйста

А вот щя догнал

возможно даже какимнибудь страшным мапредьюсом с мержем

есть у меня ощущение что мы это в отдельную коллекцию свалилвали

есть у меня ощущение что мы это в отдельную коллекцию свалилвали

Что логично

не особо

Ну зависит. Например размер всего документа мог быть лимитом и ещё копию по сути иметь в елемента документа это как то много

но тогда времена были совсем другие, трава ещё не была зелёной, был mmapv1, до какого-то момента даже пересечения индексов не было)

В итоге fetch если без прямого указания полей на выборку не слабый такой мог быть по трафику

у нас документы не очень большие были и там было всё примерно одниаковое

ну может где-то тыща элементов бы набиралась

Тогда да. Вообщем как бы интересный и логичный вариант, который я рассматривал раньше - распилить документ на keywords и сделать их отдельным массивом с индексом.

Но стало интересно и пошёл колупать монго... опять:)

да вобщем-то текстовый индекс тоже так умеет

там же есть ** индекс

оно весь документ и распиливает)

там же есть ** индекс

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

А тут можно будет $in and $nin

я сомневаюсь что это будет как-то быстрее

я сомневаюсь что это будет как-то быстрее

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

я сомневаюсь что это будет как-то быстрее

Кстати не помню, что то пересекалось вчера - в compounded индексе же можно добавлять массивы?

Или там что то типа не больше одного

Или там другое- один текстовый или 1 неар или 1 индекс on array