Заготовка/Драфт под мантикору в качестве поиска

[trin4ik]

Продолжу работу к следующим выходным, чтобы не забыть, закину в драфт что уже есть и что надо сделать.

Зачем вастрик.клубу мантикора?

По сути 2 больших плюса. Первый -- это современный поисковой движок, который имеет морфологию из коробки, стоп-слова, словоформы, а так же богатый язык синтаксиса запроса. Можно проедоставить пользователю с одной стороны качественный поиск as-is, с другой стороны, продвинутые пользователи могут иметь крутой синтаксис. Типа @title hello !world будет искать только те посты, где в титле есть "hello" и точно нет "world".
Второй большой плюс -- более быстрая индексация и меньший размер индексов. Залил в локальную сборку 4106 постов. Старый ребилд индекс занимает 1 минуту 17 секунд:

$ time python3 manage.py rebuild_search_index
...
Done 🥙 Comments: 0 Posts: 4106 Users: 1623

real	1m17.925s
user	0m11.768s
sys	0m1.091s

при этом индекс весит 177Мб

SELECT
   relname  as table_name,
   pg_size_pretty(pg_total_relation_size(relid)) As "Total Size",
   pg_size_pretty(pg_indexes_size(relid)) as "Index Size",
   pg_size_pretty(pg_relation_size(relid)) as "Actual Size"
   FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC;

search_index,177 MB,39 MB,3248 kB
posts,38 MB,2312 kB,4192 kB
posts_history,20 MB,1536 kB,3616 kB
...

Тогда как индексация мантикоры занимает 10 секунд

time python3 manage.py rebuild_manticore_index

real	0m10.362s
user	0m4.978s
sys	0m1.157s

и индекс после рестарта занимает 56Мб

mysql> SHOW TABLE posts STATUS;
+-----------------------------+--------------------------------------------------------------------------+
| Variable_name               | Value                                                                    |
+-----------------------------+--------------------------------------------------------------------------+
| index_type                  | rt                                                                       |
| indexed_documents           | 4107                                                                     |
| indexed_bytes               | 56571994                                                                 |
| ram_bytes                   | 60915314                                                                 |
| disk_bytes                  | 58904427                                                                 |
...

т.е. имея эти данные на руках, получается, что мантикора даст на индексирование в 8 раз быстрее, будет занимать в 3 раза меньше места на диске + даст нам адекватный поиск с морфологией, крутым синтаксисом и прочими плюшками современных fulltext движков.

Дальнейшие шаги

• Убрать лишнее из индекса мантикоры. В частности, ссылки на картинки, урлы для ссылок итп, т.к. они тоже залетают в индекс. Возможно стоит убрать ещё что-то специфичное.
• Надо определиться, что мы хотим видеть в индексе мантикоры, все "важные" параметры постов/комментов/пользотвателей, или только основное, т.е. fulltext поля.

Если мы размещаем в мантикоре только fulltext поля, типа title/text, то с одной стороны мы сокращаем индекс мантикоры, но с другой стороны, на выходе мы будем получать массив id и надо будет лезть в основную базу, чтобы построить отображение найденных постов/комментов. учитывая пагинацию и точечные запросы, это не большая проблема. Другая большая проблема -- мы теряем возоможность сложных запросов, типа "все посты с поминанием laravel, но чтобы рейтинг от 100 и комментов было минимум 20". Так же большим плюсом размещение доп. данных и параметров постов/комментов в мантикоре будет возможность индексирования всех данных, необходимых для рендера поиска, т.е. не надо будет обращаться к основной базе. Но в таком случае нужно будет обновлять индекс мантикоры после каждого лайка/коммента к посту. Что не сильно напряжно, но неприятно.

Я бы оставил полную индексацию всех параметров на вторую итерацию, начать можно просто с того, что сделаем морфологию и адекватный поиск. А там уже, если зайдёт, можно и остальные фишки подтянуть

• Доделать методы мантикоры, а именно поиск и replace единый метод, который по post_id филду будет либо инсертить новые данные, либо обновлять старые. Прокинуть в save методы комментов, постов и пользователей ручки для создания/редактирования мантикор-индекса.
• Возможно имеет смысл сразу обсудить "веса", однако эффективными их получится только после того, как в индекс будет залетать upvotes постов/комментов.
• Накидать /search2 для тестов, вылить в прод, понаблюдать в shadow режиме

Навеяно ишьями:
#1213
#1206
#1191
#1052

не все явно про качество поиска, но как-будто проблема в поиске есть, а мы же типа айтишники, негоже

[vas3k]

Я не понимаю смысла этого переусложнения

[trin4ik]

Я не понимаю смысла этого переусложнения

всё переусложнение заключается в ещё одном сервисе для compose и внедрение в save методы для перестройки индекса. на выходе более качественный поиск, который "не глотает слеши" и "умеет в морфологию" + занимает в 3 раза меньше места на диске, чем нынешний постгревский SearchVector. Но тебе виднее. Здорово, что я не стал до конца в это упарываться, а то там на этапе проектирования дейсвтительно не так всё просто )