@aintsaint, я прошу прощения, что долго тянул с ответом на комментарий про ES и упоминания: https://mokum.place/adworse/120808 вообще у меня в голове есть некий ступор на эту тему. Сейчас Мокум спроектирован так, что нагрузка на сервер примерно пропорциональна кол-ву активных пользователей. Когда пользователь перестает пользоваться сайтом, его риверы быстро экспайрятся, а те посты и комментарии, что он успел написать, в общем-то лежат более-менее пассивным грузом, это меня не беспокоит. В случае с mentions меня беспокоит то, что это первая фича, которая требует активных ресурсов сервера, пропорциональных общему количеству пользователей. #mokum-dev
я думал об этом все три недели, бгг, и мне кажется, что можно тоже разделить два юскейса на "активных" и "пассивных". Если человек сидит на сайте (что мы знаем, потому что у нас есть информация об активном рилтайме) или ненадолго ушел (меньше чем время expiration риверов), то мы хотим рилтаймовых (браузерных или push-мобильных) уведомлений, быстрого обновления счетчика Mentions (a-la directs) и т. п. Тратить такие ресурсы на активных пользователей я готов. ‎- псы в рапиде
для пассивных пользователей ситуация другая. в принципе, упоминания — это способ вернуть людей на мокум, чтобы посмотреть, что там им пишут (ну и директы тоже туда идут на самом деле). но сообщать об этом можно все реже и реже. в пределе можно просто ночью делать одноразовый скан новых постов и рассылать пачку емейлов про упоминания. ‎- псы в рапиде
а можно для пассивных пользователей делать каким-то ленивым джобом и мееедленно уведомлять? Ну если пользователь долгно пассивен то он уползет не только из риверов, но и из упоминаний. Разве что станет мемом но мемов много быть не может. // Упс не надо было играть в капитана очевидность, сори ‎- Все собаки попадают в рай
в любом случае, не до конца понятно, что такое "уведомление". хотелось бы, во-первых, некоторого окна длиной скажем минут 15, чтобы если ты флеймишь три треда, то тебе не приходило двадцать писем, как это было во френдфиде, пока там работал емейл. Также хочется обрабатывать случай, если тебя упомянули а потом сразу удалили, чтобы тебе не приходил инвайт. иначе это будет раздражать. ‎- псы в рапиде
А чем вообще отличаются директы от упоминаний в этом смысле? Мне кажется, они оба O(TotalUsers), просто упоминания чаще случаются. ‎- pgms
Вообще очень хорошо вся эта история с mentions сделана в слаке! Также хочется заметить, что наверное интересно было бы сделать что-то типа "@thread", для рассылки уведомлений всем в треде. ‎- псы в рапиде
@thread Дааааааа. :-) ‎- pgms
@piggymouse1: обнаружение директа тривиально. обнаружение упоминания — нетривиально. ‎- псы в рапиде
Что такое в данном случае "тривиально"? Упоминание очевидно дороже, но порядок сложности у них с директами общий кмк. ‎- pgms
Теперь технически. Я думаю, что может быть нам и не требуется для этого никакой эластик. вообще говоря, у нас есть набор фиксированных строк без синтаксиса. можно тупо разбивать тексты постов/комментариев по пробелам а потом искать там пересечением хэшей или мега-регексами. Но! мы явно хотим еще pingback, то есть ссылки на твои посты. в принципе это не сильно усложняет задачу, но слегка усложняет. ‎- псы в рапиде
@piggymouse1: ну, директ — это четкое намерение отправителя и обращение к реципиенту. упоминание может не быть прямым обращением ("как сказал @vasya, ..."). ‎- псы в рапиде
Все меняется, если мы добавляем в уравнение saved searches, на которые мы тоже хотим подписываться, а также получать уведомления! Здесь начинается мякотка с полнотекстовым поиском, проблема "неактивного пользователя, подписанного на поиски" и т. п. то есть человеку может быть интересно возвращаться на сайт, если там обсуждают интересную ему тему. в то же время, я хочу как-то обеспечить, чтобы неактивные (уже навсегда) пользователи не отъедали ресурсов сервера. у меня есть вообще идея посылки емейлов раз в два месяца "are you still interested?" ‎- псы в рапиде
А есть же какой-то механизм который сейчас выделяет @name - попросить его еще эти упоминания складывать в очередь. А из очереди как-то не травматично писать в типа "риверы напоминаний" как они будут устроены я не знаю, не видя правил, но наверное можно сделать так чтобы было одним DML. Ну и если у пользователя есть галка - уведомлять по email то еще слать письмо не чаще чем ННН. Сори за дилетантское предложение, наверняка тут есть проблемы - но мне действительно интересно услышать мнение опытного человека - где в такой схеме не хорошо ‎- Все собаки попадают в рай
а нельзя повесить обновление упоминаний каким-нибудь post-{create,modify} хуком к постам и комментариям, e-mail при этом похерив вообще (потому что эта лошадь сдохла)? получится такой директ в виде побочного эффекта ‎- сосиски супремасиски
@denistsyplakov: механизм который выделяет @name это тупая функция форматирования HTML на стадии показа поста. Вопрос-то в том, как определять это на стадии создания/редактирования поста и комментариев. и мы не хотим делать это тупо при сохранении — потому что например ты написал пост с упоминанием кого-то, а потом исправил его добавив еще два упоминания — первое упоминание должно прийти только один раз. а если ты убрал одно из упоминаний, но уведомление еще не ушло (см. "окно длиной в 15 минут") — то оно и не должно уйти. ‎- псы в рапиде
@mlivshin: ну понятно, что это "post-что-то хук к постам". понятно, что "емейл" — это просто некое слово для "какого-то уведомления", неважно какого. вопрос в том, как совместить неотменимые эффекты ("отправка письма") и то, что пост может отредактироваться (в том числе создав новые упоминания). При этом есть более простая проблема — "лента упоминаний" — туда просто кладется пост, если есть упоминание, и убирается, если упоминание исчезло. вопрос в отправке "емейлов". ‎- псы в рапиде
@squadette вот мне кажется если решать так чтобы было консистентно относительно редактирования то мы упираемся в ACID и всякое такое. Кажется что с точки зрения функционала пожертвовать консистентностью т.е. иногда приходит упомнание на пост, а тебя там нет вполне можно. Т.к. тут мы выходим за пределы БД в email и все равно консистентности не будет. Я бы на делал как на хабре - какое-то временное окно в рамках которого упоминания можно безболезненно менять. потом движок подхватывает и уносит. А если потом поменялось то уже извините. То что сейчас форматирует утащить в Руби и сделать пост обработку. В очередь класть сразу. А при выборке из очереди если пока рано генерить уведомления к посту - перекладывать item в "холодильную" очередь, а потом из нее опять в основную. ‎- Все собаки попадают в рай
@squadette: тут надо правильно отделить правильную квантиль! в смысле, неотменимые эффекты по-моему не нужны вовсе. в этом случае остаётся проблема обработки удаления уведомлений при правке текста, но эта проблема не такая уж сложная. ‎- сосиски супремасиски
@denistsyplakov: это понятно. вопрос в том, что мы не можем при каждом изменении каждого поста прогонять по нему поиск по нескольким тысячам юзернеймов. поэтому там будет отдельная очередь для регулярной перепроверки измененных с последнего раза постов, и отдельная очередь буферизованной отправки уведомлений. ‎- псы в рапиде
а неотменимые эффекты можно производить отдельно, синхронно и сразу обо всём. с exponential backoff по мере угасания активности пользователя и т.д. ‎- сосиски супремасиски
@mlivshin: мне кажется, что это будет плохо работать, если будет поддерживать только активных юзеров. люди привыкнут к идее "упоминания приходят", и будет очень неприятно когда-нибудь узнать, что пока ты был в отпуске, тебя где-то упоминали, а так как ты семь дней не логинился — то тебя посчитали несущественным для сервиса. ‎- псы в рапиде
@squadette: А почему перепроверка тысяч пользователей долго - по идее это же поиск @name в хэше. Хэш на 100.000 пользователей это ну максимум 2-4Мб. Можно просто держать в памяти уже готовый. ‎- Все собаки попадают в рай
то есть у меня в голове скорее находится идея "обслуживать всех вообще, но активную часть обслуживать другим транспортом". ‎- псы в рапиде
@squadette: ну (тут голос всё более очевидным образом начинает исходить из афедрона) можно же на крайняк гонять Редкую Тяжёлую Оффлайновую Задачу по всей базе, раз в день скажем? ‎- сосиски супремасиски
@denistsyplakov: это не "долго", просто это надо делать при каждом изменении поста, а так как посты обычно неоднократно меняются в течение считанных минут/десятков секунд, то не надо проверять каждое изменение. но вот вопрос в том когда же все же уже окончательно пора проверять — он не тривиальный, имхо. возможно, я не прав. ‎- псы в рапиде
@mlivshin: так я так и написал же — но это работает только для неактивных. для активных нужно это делать б/м в рилтайме. ‎- псы в рапиде
@squadette: [проступает звериная менеджерская сущность] а если сделать сначала дешево и более или менее безопасно для текущео числа пользователей как бета фичу, собрать 1) статистику 2) отзывы, а потом уже по уму? ‎- Все собаки попадают в рай
@squadette: у активного пользователя строчка "mentions" в сайдбаре жирнее станет и он заметит, зачем ему б/м в риалтайме неотменимые эффекты? ‎- сосиски супремасиски
@mlivshin: потому что люди хотят desktop notifications и mobile push ) ‎- псы в рапиде
@squadette: есть мнение что до этого моста ещё дойти надо :) ‎- сосиски супремасиски
Начал читать, а большую часть аргументов против не-fts уже до меня сказали. Я понимаю принципиальное соображение, что на неактивных пользователей не хочется тратить ни чиха процессорного времени и если эту мысль держать в голове достаточно настойчиво, можно избавиться от кучи ненужных решений. ‎- aint so saint
Прочитав тредик не понимаю, почему mentions - "обслуживает неактивных пользователей", ведь источник mentions - это пост, который пишет активный пользователь. Я бы аттрибутировал всю связанную с постом работу к деятельности активного пользователя. Ну и загруженность системы уведомлений не будет пропорциональна всей пользовательской базе (если нет бродкастов), а как раз множеству активных пользователей +1 хоп по соц графу, то есть таки O(кол-ва активных). ‎- Monkey Ping
@elephantum: Я внезапно понял что ты похоже прав. И если мы доя упоминаний пользуемся хэшами, а не FTS, то все получается действительно линейно от активных. ‎- псы в рапиде
Но есть такие два соображения (я не до конца понимаю как работают риверы в мокуме и смогу вдумчиво об этом прочитать через пару часов): (1) приготовленный правильно fts на данных постов и комментариев (т.е. для строк не больше скажем 2-3к символов каждая) - cheap as shit, я сильно подозреваю, что дешевле многих библиотечных функций руби со строками, хех (2) mentions можно рассматривать как события или как состояния постов. События - дешевле подсосаться к входящим данным, сделать очередь нотификаций и не городить огород с fts вообще. Но если оно нам интересно как состояния - его нужно узнавать на момент открытия интерфейса, и вот тут собственно от es может быть много толку. Этот толк в том, что узнать последние N объектов с заданным терм-вектором (где терм-вектор - мой юзернейм) - это просто подряд пройти по индексу N шагов, он специально для этого организован. Соответственно цена вопроса - (1) хранение последнего момента, который пользователь видел (и определиться, что именно значит видел) (2) немного дополнительного винта на расширенные индексы (3) помудохаться с запросами, чтобы elastic своим очень умным поведением не мешал это сделать ‎- aint so saint
мой поинт в том, что взять одно слово из текста для elastic - это не совсем привычный fts, а намного легче. ‎- aint so saint
@aintsaint: я видимо не до конца понимаю, что это означает в терминах эластика. я знаю только его самый простой simple_query, и знаю, что там какая-то неизмеримая сложность и гибкость и дюжина разных вариантов запросов. можно ссылку на доку про "терм-векторы" или как оно там? звучит как будто там можно создавать запросы, которые живут внутри него как объекты первого класса — но ведь это не так? я думал, что эластик умеет только функцию(корпус текста, запрос) => список документов, причем запрос надо каждый раз запихивать в него снаружи. нет? ‎- псы в рапиде
(ссылки следующим комментом) не совсем так: в ваших понятиях корпус текста в случае fts-индексов это скорее набор ссылок, в которых нашлись токены (термы) из запроса с определенными допусками. токены - результат нарезки текста выбранным способом. все интересное в эластике начинается с определения, что и как индексировать и что и как нарезать. в результате работы нарезатора (tokenizer) образуются единицы индексирования, они же term vectors. грубо говоря, индексировать по словам, би-граммам, н-граммам. правильная стратегия поиска сводится к тому, чтобы разбить контент на такие токены (термы), которые удобно собирать запросами match, exact match (самый дешевый), или быть готовым собирать query string (по сути строка запроса lucene, хардкор режим). терм вектор - это термы, входящие в документ, плюс их частота в документе, отиндексированные от терма, а не от документа. сортировки и все остальное сейчас оставим сбоку, их можно делать круто и очень некруто (filter круто, facet до filter круто, все остальное дорого, пишут в официальном мануале на второй странице). все остальное дорого и глупо. ‎- aint so saint
(смотрит в документацию) тьфу, последние два шота были контрпродуктивны, все смешалось в дороге. term vectors - это способ определения видимости индекса термов (токенов) в mapping (метаданных индекса). при включенном маппинге term vectors (https://www.elastic.co/guide/en/elasticsearch/reference/2.1/t...) запрос query->match стремительно дешевеет в скорости и дорожает немного по памяти. но это блажь, даже без него, match / exact match (разница в случае совпадения запроса с длинной токена пренебрежима) - самый дешевый запрос в понятиях люцены, который правильно настроенный эластик отдает по сути за стоимость открытия трех коннектов и одного обращения в память. ‎- aint so saint
однако прочитав следующий пост я уже понял, что я проблему воспринял немного иначе. в моем представлении о прекрасном, даже в очень условном realtime не нужно иметь всегда готовые денормализованные данные о списке событий, в которых упомянут юзернейм. если их хочется иметь - fts действительно проблему решает плохо, поскольку он хорош про "дай мне сейчас на сейчас N актуальных запросов", у которых fine tuning удешевляет риалтаймовый ответ до какой-то границы, которая все равно computationally expensive и упирается во время по сравнению с вычиткой плоской таблицы событий. ‎- aint so saint