« Rev
@mongodb_ru   519
Fwd »


yopp
оптимальнсть существует только когда есть критерии оценки
Gor
оптимальнсть существует только когда есть критерии оценки
Вот и пытаюсь понять. Данные в индексе лежат по score high->low
Gor
Но! Если поиск идёт больше чем по одному слову, то данные выбираются по очереди для каждого слова, выченяется score и прикидывается выше
Gor
Но есть момент что на recordid будут пересечения и.. ну там понятно да что оно все это должно с lock делать?
Gor
Собственно и делает
Gor
Ну и memory intense
Gor
Prefix, term, score, suffix
Gor
Term это stem
yopp
а prefix / suffix?
Gor
Это для compound
yopp
т.е. сам индекс это пары? term / score => recordId
Gor
Да
yopp
или term / score / recordId => const?
Gor
С сортировкой по score h->low
Gor
или term / score / recordId => const?
Вот я предполагаю этот вариант но подтвердить его не смог.
yopp
wt dump же
yopp
-x
Gor
wt dump же
В нем я не смог понять. Пару терм и score (weight) вижу. Value постоянное значение
Gor
А вот ссылка на документ после скоре или после suffix не понятно
yopp
она будет самой последней
yopp
там varint
yopp
помоему типа sqlite3 varint
Gor
Тоесть поидее последний hex в индексе, это что то даёт?
yopp
даёт recordId
Gor
Я имел ввиду с точки зрения оптимизации
yopp
в смысле?
Gor
Черт всеравно двояко сказал
Gor
а какой там вообще формат индекса?
Вот это спрашивал просто для инфо или была мысль какая?
Gor
Я вчера додумался до мысли что если индекс сортировать не по score а по document то выборки 'мне надо все что попало под запрос' можно ускорить на порядок ещё.
Gor
В этом варианте score суммироваться будет быстрее, быстрее можно advanced на record_id при параллельном чтении по 2 и более терминам делать
yopp
что значит «по document»?
yopp
я не разделяю твой подход, если честно
yopp
рассуждения «сделать быстрее» в вакууме это путь вникуда. если ты хочешь что-то изменить, то эффективнее подходить к этому используя научный метод. сформулировать проблему, оценить существующие решения, предложить своё решение, сравнить его с существующими
yopp
индексы это _всегда_ компромис
yopp
второй момент: поиск подтверждений это тоже не очень эффктивный способ поиска решения
yopp
критерий поппера о фалсифицируемости не просто так является научным стандартом
Gor
Пока что идёт фаза формирования зоны вопроса.
yopp
эффективнее искать не подтверждение, а опровержение
yopp
Пока что идёт фаза формирования зоны вопроса.
очевидно что есть какие-то случаи в которых существующий индекс по каким-то критерям работает менее эффективно
Gor
По сути изначальную свою проблему я решил, поиск 'дай мне все кто подпадает под запрос' решил. Оно работает.
Gor
Добавление: быстро и без учёта score
Gor
очевидно что есть какие-то случаи в которых существующий индекс по каким-то критерям работает менее эффективно
Я почему разделил в опросе на два варианта: score и без - они диаметрально противоположны по реализации индекса
yopp
score в каком типе хранится?
Gor
Скорее даже по подходу к формированию индекса для быстрого использования
yopp
пичалька
yopp
в мантиссе будет много шума и вероятно больше разрешение тут скорее имеет отрицательный эффект, уменьшая селективность
yopp
а score как считается?
Gor
per record - что то типа bm25 но не уверен. число от 0 до 1 на term в содержимомо на момент индексации. Но возможно значение weight на момент индексации помноженное на количество term в содержимом summary при поиске - сумма на текуший момент по всем stem(term) без оглядки на обязательность("") и исключение (-)
Gor
оно реально сделано .... э странно
Gor
если коротко - то чем сложнее запрос поиска тем более score это not reliable параметр
Gor
как итог, вполне понятно почему выбирают отдельные решения для score rated поиска
Kirill
Почаны, помогите советом, какой индекс навесить в монге, что бы поиск под подстроке быстрее был? Вставок нет
Саша
Всем привет, подскажите плиз как открыть оболочку
Саша
запускаю эту шнягу и оно само закрывается
Nick
запускаю эту шнягу и оно само закрывается
Через командную строку открывайте
Anonymous
Доброе утро, у кого есть возможность поделиться советом, какую базу данных лучше всего выбрать для сервиса: торговый центр, который содержит в себе магазины. есть модели: - Пользователь - Магазин: Текстовые данные магазина Кошелек магазина Товары магазины Статистика магазина Сделка В общем типичная модель биржи магазинов. Подскажите пожалуйста какие приемущества перед Postgres может дать Mongo в данном случае? Какие могут быть недостатки? Сервис часть микросервисной архитектуры, которая будет также общаться с некоторыми сервисами Буду крайне признателен любому совету)
Sardor
!report
Sardor
да ну, не подключили бота
Ansar
поддержу. но sqlite то чем плох?
для каждой задачи наверное свой (с)тул, для dev вообще отличный )
yopp
У постгреса исторически как-то не очень складыватеся с инструментами для распредленного хранения данных и это проявляется в достаточно высокой операционной сложности. В монге транзакционные гарантии только появились, есть ряд ограничений. Не такие богатые возможности для полнотекствого поиска. Некоторые фичи и инструменты только за деньги.
yopp
помему даже репликацию из коробки как-то не очень давно завезли
yopp
ну короч постгресс мне лего немного напоминает
Nick
а устанавливать его пробовали7
Max
Привет, у меня тут вопрос на стыке монги и кода. В мире монги вообще используют миграции? Когда изменяется структура коллекций. Если да, то где про это можно глянуть? У кого-то был вообще опыт на каком либо ЯП?
Gor
но не с монгой
Gor
как бы немного в теме что тебе надо, но как такое делать с монгой- хзхз ибо там нет принудительной схемы (хотя в последних версиях уже что то типа того есть)
Gor
я так понимаю тебе надо делать что то типа "вызвать такой то код и применить его на структуру данных если у меня новая версия схемы" да?
Max
Под 50 коллекций, вьюшки - уже есть достаточно жирные, и я местами теряюсь когда применяю руками скрипты миграций - хочу быть уверенным что на проде будет так же как на стейджинге
« Rev
@mongodb_ru   519
Fwd »