yopp
да
yopp
историю изменения этого кейса, коммит мессаджи
yopp
там могут быть ссылки на жиру
Gor
не, что то тут не так
Gor
это на стадии индекса баг
Gor
тоесть "Stationclose" находится в индексе по "station"
yopp
может там какойниюбудь кодепоинт юникодный?
Gor
надо покопаться. и перепроверить. возможно из-за того что в разное время базу иницилизировал для ДО и ПОСЛЕ тестов
Gor
значения индентичные, но индекс разный и это я точно не трогал
Gor
стоп слово чтоли...
Gor
забавно вообщем.
Gor
Все догнал откуда ноги
Gor
Старый алгоритм группирует все ид документов по всем индексам, потом их дергает все вместе с базы и ищет уже фразы в каждом отдельно
Gor
Так что если есть фраза то в проверку попадут не пересечения а Или записи
Gor
И тут такой вот курьез что фраза находится по частичному от первого слова в фразе индексу. Я же делаю intersect на фразы и соответственно именно эта запись вылетает. Так что поиск точнее 887 а не 888
Gor
Надо поискать или есть репорт такой
Gor
При этом в оригинальном ещё грузятвсе записи с негативным поиском -some
Gor
Вместо эксклуда по stamm
Gor
До FETCH
Gor
вот интересное почитать https://jira.mongodb.org/browse/SERVER-30163?jql=text%20~%20%22phrase%20search%22
Gor
https://github.com/mongodb/docs/commit/111afca2f1fab9a7773182f2ff221be444efcf69
Gor
а вот по 887 vs 888 https://jira.mongodb.org/browse/SERVER-20307?jql=text%20~%20%22phrase%20search%22
yopp
Sep 07 2015 03:33:11 AM UTC )))
yopp
To fix, the phrase matching logic would have to take word boundaries into account
yopp
word boundary это уже страшно
yopp
но похоже ты откопал горящую свалку :)
yopp
поздравляю!
Gor
та пипец
Gor
там в ответах даже врут
Gor
https://jira.mongodb.org/browse/SERVER-24683?jql=text%20~%20%22phrase%20search%22
Gor
вот тут. слово cat в publications ничего общего не имеет с поведением поиска по фразе
Gor
ибо проверяют они по stamm и слово cat генерирует не пересекающийся с publications - ну только если я гоню и не верно понимаю генерацию stamm
yopp
наделай тикетов, сделай пару патчей и отправь резюмешочку хоровитцу)
Gor
я зарегал mongodb.codes - сделаю сборку, кину туда. заведу отдельный org под проект и открою issues.
Gor
потом пройдусь всем issues и все, которые пофиксены отпишу. ну и да надо оформить PR но на 4.x бранч а для этого еще портировать его туда
Gor
я пока 3.6 сделал
Gor
это освободит от legacy - не надо будет обратная совместимость с неээфективным старым поиском... и такое ошушение что тикеты по 4 года висят ибо никому не надо было
yopp
Лучше начать с PR со ломающимися тесткейсами
Gor
кстати dbtest прогнал - все чисто
Gor
кроме sock но это потому что не рутом на маке
Gor
Лучше начать с PR со ломающимися тесткейсами
да обязательно сделаю PR это точно. но гарантия что он будет висеть дооолго)
yopp
Главное чтоб кейсы приняли. Потом к ним патчи
yopp
Иначе кейсы могут не принять а время на патчи будет потрачено
Gor
там прикол в том, что я по сути переписал всю часть связанную не score запросами.
Gor
так что надо кейс открывать сумарный с полным перечнем всех связаных issues
yopp
Чем глобальнее изменения, тем сложнее протаскивать и тем больше мороки для всех участников
Gor
показать до и после stage plan explain?
yopp
Ну показывай, чо уж теперь!
Gor
до https://pastebin.com/AKEpRvTg
после https://pastebin.com/9MryZm3g
Gor
это на без фразы
Gor
с фразой еще веселее
до https://pastebin.com/cX9gZd4g
после https://pastebin.com/nw475n9Q
Gor
Ещё можно сравнить время без патча и с патчем
еще надо полный test case по новым модулям text_and text_nin написать и изменения для test модуля и fts_matcher
Gor
вообщем чтоб большой список не смотреть разница вот
"executionStats" : {
"executionSuccess" : true,
"nReturned" : 809,
"executionTimeMillis" : 49689,
"totalKeysExamined" : 535069,
"totalDocsExamined" : 453430,
и
"executionStats" : {
"executionSuccess" : true,
"nReturned" : 808,
"executionTimeMillis" : 8623,
"totalKeysExamined" : 644614,
"totalDocsExamined" : 86188,
yopp
вообщем чтоб большой список не смотреть разница вот
"executionStats" : {
"executionSuccess" : true,
"nReturned" : 809,
"executionTimeMillis" : 49689,
"totalKeysExamined" : 535069,
"totalDocsExamined" : 453430,
и
"executionStats" : {
"executionSuccess" : true,
"nReturned" : 808,
"executionTimeMillis" : 8623,
"totalKeysExamined" : 644614,
"totalDocsExamined" : 86188,
Во втором случае на один порядок меньше документов просмотрено, от сюда и выигрыш по времени
Gor
да. это первое что я обнаружил когда стал смотреть какого черта поиск фразы идет так долго и почему totalDocsExamined такой большой
Gor
а все потому, что берутся stemm на каждое слово из фразы и дергаются в память все документы без пересечения
yopp
Ценой более активного использования индекса, что вообщем-то неплохо
Gor
Ценой более активного использования индекса, что вообщем-то неплохо
индекс да выше, я для negative терминов еще сделал вычитание ДО fetch стадии
Gor
хоть бери делай mongodb-fts сборку)))
Gor
там работы еще очень много
yopp
Не надо форков, надо убедиться что цифры настоящие и что они не делают другие цифры хуже и продумать стратегию как протащить патчи в апстрим
Gor
сегодня ночью буду пробовать roll out на прод, где именна эта проблема и более 1м данных
yopp
В 4.2 уже не протащить
Gor
а так, я не против. помочь сможешь?
Gor
для себя я всеравно 3.6 буду вести
yopp
3.6 со скорым выходом 4.2 — светит eol в какомнибудь 2020 году
Gor
куча рутины. тесты погонять (я выложу x86 архив чтоб проще), собрать все issues надо. подготовить описание. портирование в 4. мастер чтоб в head в первую очередь ушло.
Gor
дохрена организационой рутины. надо как минимум сводны issue по всем пересекающимся с jira issues и тест кейсы по всем проблем ам
yopp
Я бы начал с четкого формулированиям проблемы и примера решения. Потряс бы контактами и нашёл бы выход на кого-нибудь, кто этой частью занимается. Это поможет оценить перспективы того, что оно не застрянет навечно в жире
Gor
вот вот. у меня реальный кейс - fts по полю текстовому. и из-за поиска по другим ключам - нельзя выносить в любой standalone да еще и поиск полный. тоесть надо ВСЕ совпадения а не первые 10
Gor
как говорится надо было вчера)
Gor
при этом я думаю ты согласишся, что сложилось мнение - mongo fts хреновая
yopp
Выходов из этой хреновости не так много
Gor
в итоге всем или советуют или сами шишки набивают и выносят в standalone или делают по сути те же tokens в array елемент документа
yopp
Там проблема не в реализации, а в монолитной архитектуре
Gor
не, реализация реально .... сделана не оптимально
yopp
Ну припихнули чтоб было. Для многих достаточно и такого
Gor
вот вот. релизнули абы что чтоб в 2.4 вроде? сказать а унас fts!