Продолжая разговор в https://mokum.place/squadette/165211, про пропорции. Допустим, у нас 1000 активных юзеров и 10000 всего. Нам надо понять, какие юзера (любые) упоминаются в посте. Я хочу объяснить (самому себе), почему мне казалось, что зависимость плохая. 1) Если мы забываем про FTS и делаем через хэш-таблицу, то у нас получается элементарная крошечная структура данных на 10к элементов. Мы можем регексом извлечь из полного текстового представления поста (с комментариями) все, что выглядит как юзернеймы (@name и мокумные урлы). Потом мы проходим по этому списку и каждый элемент лукапим в хэше. Зависимость линейная от длины текста (то есть да, от активности активных юзеров). #mokum-dev
2) то, как я сначала хотел: предположим, мы используем FTS. у нас есть пост, мы кладем его в эластик. теперь нам надо внутри этого поста найти одно из 10к слов. мы можем делать запросы вида "where post_id = 12345 and text_representation contains (alice|bob|carol|david|...)". длина этого запроса (видимо, запросов таких надо сделать несколько, потому что я думаю что 10 тысяч термов никто выдержит рано или поздно) зависит от общего кол-ва юзеров, и вот тут-то мне чудится то, чего мне (может быть) хотелось бы избежать. но вообще да, внезапно резко понятно, что FTS на самом деле ничего не дает нам тут. ‎- псы в рапиде
насколько я понимаю, именно этот кейс ("мониторинг ключевых слов") относительно плохо обрабатывается FTS'ами. Они идеально решают задачу "найти один запрос в огромном массиве текста" и, кажется, условно плохо решают задачу "в потоке небольших текстов найти, какому из тысяч _запросов_ соответствует каждый текст". В Андеве мы это решили, написав кастомную обертку к Lucene/Bobo/Zoie, в которой фактически полнотекстовый поиск был "развернут" и набор запросов рассматривался как целевой текст, в котором мы искали слова из фрагментов :) Но там фрагменты были совсем короткие, порядка 15-20 слов в каждом. ‎- псы в рапиде
(^ эту обёртку даже, по словам степашки, хотели причесать и выложить в гитхабы) ‎- адский хардлайн в засаде
3) возвращаясь к вопросу FTS: все опять меняется, если мы все же вводим идею "сохраненных поисков" и мониторинга полнотекстовых упоминаний любых слов, а не только юзернеймов. Тут точно возникает стандартная проблема "юзер набил десяток запросов и забил на сервис" — в какой момент надо переставать прочесывать каждый пост по этим 10 запросам и уведомлять его? в принципе это решается понятными правилами, типа "заходите хотя бы раз в неделю", а если человек забыл/забил, то запросы деактивируются, а при следующем заходе ему скажут "у вас N сохраненных запросов, реактивировать?" ‎- псы в рапиде
Короче, похоже, надо делать пункт один, пункт два был ошибкой, пункт три надо реализовывать отдельно за бабло^W^W. @elephantum прав, и FTS тут ваще не при делах. ‎- псы в рапиде
ммм, а ты на percolator не смторел в эластике? ‎- BSOD bluez
@denisshipilov: ахуеть! Attn @spariev. ‎- псы в рапиде
перколатор к сожалению трагически небыстр в инсерте, хотя и мысль в правильном направлении. я думал про вариант 2, но в котором это выполняется per user (ну или если очень хочется чуток сэкономить - пишем скрипт на стороне es, который откуда-то этот список берет и дробит на индивидуальные запросы). дешево в эластике/люцене бывает ровно в одном случае - когда определен близкий к токену индексирования поисковый запрос и его выгребается конечное кол-во записей. ‎- aint so saint
ну да, percolator фигово масштабируется по кол-ву "хранимых запросов". но с задачей user mentions-то как раз можно попробовать - если вместе с постом индексировать username отдельным люсиновским полем и делать по нему term filter, чтобы был быстрый exact match вместо VSM similarity score. ‎- BSOD bluez

2015-2016 Mokum.place