Комментарии 24
Это просто праздник какой-то! Даешь неделю горизонтальных архитектур!
Огромное спасибо за материал, было очень интересно!
Я не очень понял вот такой момент:
— В конце токенизации письма мы получаем некий список (который далее станет словарем) первых форм слова.
— Поисковый запрос так же токенизируется и ищутся совпадения первых форм слов запроса по словарям писем.
— А как быть с поисковыми запросами для которых важно окончание и их нельзя приводить к первой форме, как в таком случае искать совпадения со словарем?
Возможно, я что-то упустил или неправильно понял.
Я не очень понял вот такой момент:
— В конце токенизации письма мы получаем некий список (который далее станет словарем) первых форм слова.
— Поисковый запрос так же токенизируется и ищутся совпадения первых форм слов запроса по словарям писем.
— А как быть с поисковыми запросами для которых важно окончание и их нельзя приводить к первой форме, как в таком случае искать совпадения со словарем?
Возможно, я что-то упустил или неправильно понял.
Почему в индексе хранятся CRC32 слов, а не сами слова?
Важно, чтобы все записи в словаре имели одинаковую длину. Благодаря этому достаточно легко организовать бинарный поиск по нему.
Кроме того, существуют определенные требования к размеру индекса. Во-первых, таким образом экономится пространство на жестких дисках. Во-вторых, меньший по размеру словарь быстрее читается в память. А CRC32 меньше, чем средней длины слово.
Кроме того, существуют определенные требования к размеру индекса. Во-первых, таким образом экономится пространство на жестких дисках. Во-вторых, меньший по размеру словарь быстрее читается в память. А CRC32 меньше, чем средней длины слово.
А как эта система шардится, если шардится? Или индекс размазывается по серверам?
Обожаю, когда раскрученные сервисы приподнимают юбку и показывают то, что обычно скрыто.
Рассматривали ли Вы готовые решения(sphinx, solr, elastic) для реализации этого функционала?
Если да, то почему не устроило(неужели не уложились в рамки по мощностям?)?
Очень интересно было бы узнать объемы данных и инфу по машинам для таких рамок.
Если нет, то почему?
Если да, то почему не устроило(неужели не уложились в рамки по мощностям?)?
Очень интересно было бы узнать объемы данных и инфу по машинам для таких рамок.
Если нет, то почему?
У всех этих решений есть как минимум один общий недостаток — они сильно потребляют память. Это все из-за того, что вся верхушка индекса у них кэшируется. И это правильное решение для случая, когда у вас один большой индекс. А когда у вас много маленьких индексов (по одному на пользователя), то это решение не работает, ибо памяти столько не напасешься. В то же время, делать один большой индекс на всех пользователей, без жесткого экранирования пользователей друг от друга — это суперопасно для почты, ибо в случае бага в фильтрации результатов можно легко получить данные из чужого ящика.
А чем всех не устраивает полнотекстовый поиск MySQL?
Годная статья.
Однако, хотелось бы немного замеров производительности. Какой-нибудь график время_поиска/размер_ящика (и еще как-нибудь туда приплести длину запроса).
Однако, хотелось бы немного замеров производительности. Какой-нибудь график время_поиска/размер_ящика (и еще как-нибудь туда приплести длину запроса).
Время поиска по snapshot практически не зависит от размера ящика, а от количество слов в запросе зависит линейно.
Время поиска по xlog линейно зависит от его размера (а его максимально допустимый размер — от конкретных настроек демона).
Математическое ожидание времени исполнения поискового запроса — 200мс (посчитано на живом сервере).
Подробные графики покажем в ближайшее время (возможно, это тема для отдельного поста).
Время поиска по xlog линейно зависит от его размера (а его максимально допустимый размер — от конкретных настроек демона).
Математическое ожидание времени исполнения поискового запроса — 200мс (посчитано на живом сервере).
Подробные графики покажем в ближайшее время (возможно, это тема для отдельного поста).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Полнотекстовый поиск: как это делают в Почте Mail.Ru