Django - Урок 063. Полнотекстовый поиск на сайте для нескольких моделей с поддержкой мультиязычности

Django, python, Django 3, modeltranslation, full-text search, Django 4

Наконец-то мне удалось сделать достаточно быстрый полнотекстовый поиск по нескольким моделям с учётом оптимизации запросов на сайте, который бы меня устраивал и отвечал моим требованиям к качеству проекта.

Если вы сейчас воспользуетесь поиском по сайту, то обнаружите, что поиск сработает достаточно быстро, а также выдаст несколько групп поиска: Статьи, Комментари, Темы форума, Ответы на форуме, Тесты.
Из всех групп поиска будут выбраны по три результата, а также будет у каждой группы есть счётчик общего количества найденных резульлатов и предложено посмотреть остальные результаты в отдельных вкладках.

В итоге я сделал такое разделение по той причине, что создавать единый список со всеми результатми довольно накладно по ресурсам и недостаточо эффективно.

Поэтому итоговый результат выгляди следующим образом:

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

А теперь я расскажу, как именно я это сделал.

Полнотекстовый поиск в PostgreSQL

База данных PostgreSQL поддерживает полнотекстовый поиск, а Django позволяет средствами ORM его реализовать.

Самый простой способ, как запустить полнотекстовый поиск, это воспользоваться методом search по полю модели, что и описано в документации к Django.

Например так

Entry.objects.filter(text__search='Cheese')

В данном случае модель Entry имеет поле text, по которому вызывается полнотекстовый поиск с помощью встроенного функционала search.

Более развитым способом выполнения полнотекстового поиска является использовния поисковых векторов SearchVector по нескольким полям. То есть так

from django.contrib.postgres.search import SearchVector

Entry.objects.annotate(search=SearchVector('text', 'tagline')).filter(search='Cheese')

К сожалению, использования метода annotate является малоэффективным, поскольку этот метод порой требует достаточно много времени.
Для улучшения производительности средства Django предлагают использовать специальное поле SearchVectorField , которое индексируется базой данных PostgreSQL. Это позволяет значительно ускорить поиск на сайте.

Добавление SearchVectorField и индекса в модель

Я покажу добавление SearchVectorField и индексирования на примере модели Article.

from django.contrib.postgres.indexes import GinIndex
from django.contrib.postgres.search import SearchVectorField

class Article(models.Model):
    title = models.CharField('Title', max_length=200)
    content = models.TextField(verbose_name='Content', blank=True)

    # SearchVectorField for full-text search
    search_vector = SearchVectorField(null=True)

    class Meta:
        indexes = [GinIndex(fields=["search_vector",]),]

Как видите, в представленном коде присутствует поле search_vector, которое индексируется с помощью указания GinIndex в Meta классе модели Article.

После того, как вы добавили SearchVectorField и индексирование данного поля, создайте новые миграции

python manage.py makemigrations

В общем виде новая миграция будет похожу на эту

# Generated by Django 3.2 on 2023-03-27 21:03

import django.contrib.postgres.indexes
import django.contrib.postgres.search
from django.db import migrations


class Migration(migrations.Migration):

    dependencies = [
        # depends on 
    ]

    operations = [
        migrations.AddField(
            model_name='article',
            name='search_vector',
            field=django.contrib.postgres.search.SearchVectorField(null=True),
        ),
        migrations.AddIndex(
            model_name='article',
            index=django.contrib.postgres.indexes.GinIndex(fields=['search_vector'], name='knowledge_a_search__682520_gin'),
        ),
    ]

Но этого будет недостаточно, поскольку нужно ещё заполнить поле SearchVectorField, что также можно сделать во время миграции. Поэтому модифичируем миграцию следующим образом

# Generated by Django 3.2 on 2023-03-27 21:03

import django.contrib.postgres.indexes
import django.contrib.postgres.search
from django.db import migrations


def compute_search_vector(apps, schema_editor):
    Article = apps.get_model("knowledge", "Article")
    Article.objects.update(search_vector=django.contrib.postgres.search.SearchVector("title", "content"))


class Migration(migrations.Migration):

    dependencies = [
        # depends on 
    ]

    operations = [
        migrations.AddField(
            model_name='article',
            name='search_vector',
            field=django.contrib.postgres.search.SearchVectorField(null=True),
        ),
        migrations.AddIndex(
            model_name='article',
            index=django.contrib.postgres.indexes.GinIndex(fields=['search_vector'], name='knowledge_a_search__682520_gin'),
        ),
        migrations.RunPython(
            compute_search_vector, reverse_code=migrations.RunPython.noop
        ),
    ]

В данном коде добавлен дополнительный шаг, который добавляет выполнение python кода, чтобы сразу заполнить SearchVectorField , а именно последний шаг migrations.RunPython , который запускает функцию compute_search_vector .
SearchVectorField имеет важную особенность, в него нельзя напрямую добавить SearchVector , но его можно заполнить используя метод update у менеджера модели. Поэтому-то данный код и выглядит таким образом

Article.objects.update(search_vector=django.contrib.postgres.search.SearchVector("title", "content"))

После чего выполните миграцию

python manage.py migrate

Теперь все статьи имеют проиндексированное поисковое поле. Но на самом деле этого недостаточно для полноценной работы поисковой системы, поскольку поисковое поле нужно заполнять как в случае создания нового объекта, так и в случае редактирования старого. Для этого документация Django предлагает обратиться в документации PostgreSQL и создать триггеры. Это хорошо и правильно, но что если вы не хотите по какой-то причине лишний раз лезать в PostgreSQL и вручную создавать все необходимые триггеры. Как тогда быть? В этом случае нас спасёт сигнал/слотовая система Django.

Для этого добавим в модель Article следующий код

    def update_search_vector(self):
        qs = Article.objects.filter(pk=self.pk)
        qs.update(search_vector=SearchVector("title", "content"))

А потом подключимся к сигналу post_save

from django.db.models.signals import post_save
from django.dispatch import receiver

@receiver(post_save, sender=Article)
def post_save_artcile(sender, instance, created, update_fields, **kwargs):
    instance.update_search_vector()

Таким образом при каждом сохранении объекта статьи будет происходить обновление поискового поля.

Класс SearchView для поиска по всем видам контента

А теперь напишем SearchView , который бы позволил выполнить поиск по нескольким видам контента и выдал бы необходимый результат. В нашем случае скажем, что у нас на сайте есть статьи ("Article") и комментарии ("Comment")

class SearchView(View):
    template_name = 'search/index.html'

    def get(self, request, *args, **kwargs):
        query = request.GET.get('search', None)
            article_results = Article.objects.filter(search_vector=query)
            comment_results = Comment.objects.filter(search_vector=query)

        return render(
            request=request,
            template_name=self.template_name,
            context={
                'search': query or '',
                'article_results': article_results[:3],
                'article_results_count': article_results.count(),
                'comment_results': comment_results[:3],
                'comment_results_count': comment_results.count(),
            }
        )

Обратите внимание, что в строке сайта передаётся get параметер search , который отвечает за поисковую фразу. Также имеет пара ухищрений для оптимизации запросов к базе данных.

Поскольку Django использует ленивые запросы к базе данных, то и реквесты выполняются ровно тогда, когда это требуется. Таким образом строка

article_results = Article.objects.filter(search_vector=query)

лишь задаёт общий запрос к базе данных, но не выполняет его, поскольку для первоначальной страницы поиска нам нужно общее количество найденных материалов и только три первых объекта из всех найденных материалов.
Поэтому в качестве контекста для рендеринга передаются только два QuerySet.

    'article_results': article_results[:3],
    'article_results_count': article_results.count(),

article_results[:3] выполняет операцию limit к найденным записям и возвращает только три объекта
article_results.count() выполняет подсчёт всех найденных записей. На самом деле подобный дополнительный код позволяет значительно сократить время выполнения запросов, что значительно ускоряет поиск на сайте.

Рендеринг страницы

Далее выполняется рендеринг страницы. Я не буду приводить полный код своей страницы, а покажу лишь в общих чертах, как это может выглядеть

У нас имеется главная поисковая страница, которая наследована от общего шаблона base.html (Данный шаблон не имеет смысла рассматривать).
А вот что касается кастомных тего, то здесь мы остановимся подольше. Их здесь имеется несколько:

• append_query_to_url - тег для добавления query параметра в url страницы поиска по определённому контенту.
• search_field - тег для рендеринга поля поиска
• found_objects - тег для рендеринга вывода результатов по контенту

{% extends 'base.html' %}
{% block page %}
  {% load search %}
  {% url 'search:articles' as articles_search_url %}
  {% url 'search:comments' as comments_search_url %}

  {% append_query_to_url articles_search_url as articles_search_url_with_query %}
  {% append_query_to_url comments_search_url as comments_search_url_with_query %}

  {% search_field search %}

  {% block search_result %}
    {% found_objects article_results article_results_count 'Articles' 'Show all articles' articles_search_url_with_query  %}
    {% found_objects comment_results comment_results_count 'Comments' 'Show all comments' comments_search_url_with_query  %}
  {% endblock %}
{% endblock %}

Каталог "templatetags"

В некоторых статьях, например в Как написать блочный шаблонный тег tabbar наподобие тега blocktranslate , я уже описывал структуру этого каталога и что там должно содержаться для регистрации шаблонных тегов, поэтому не буду останавливаться на этом лишний раз.

Итак, посмотрим на содержимое файла templatetags/search.py

# -*- coding: utf-8 -*-

from django import template
from django.template.defaultfilters import urlencode

register = template.Library()

@register.inclusion_tag('search/search_field.html', takes_context=True)
def search_field(context, value, **kwargs):
    context.update({'query_value': value})
    return context


@register.simple_tag(takes_context=True)
def append_query_to_url(context, url):
    return '{}?search={}'.format(url, urlencode(context.get('search', '')))

@register.inclusion_tag('search/found_objects.html', takes_context=True)
def found_objects(context, results, results_count, objects_title, all_search_message, search_url):
    context.update({
        'results': results,
        'results_count': results_count,
        'objects_title': objects_title,
        'all_search_message': all_search_message,
        'search_url': search_url
    })
    return context

Каталог "шаблоны/поиск"

Далее рассмотрим Что из себя представляют шаблоны inclusion тегов

Файл "search/found_objects.html"

В общих чертах рендеринг шаблона для нескольких ваших объектов из поиска будет выглядеть так, как показано ниже.
Как видите, здесь используется разметка из bootstrap, а также нет примера рендеринга самого объекта. Я уверен, что если вы читаете эту статью, то вполне можете самостоятельно написать то, что требуется вам, поскольку эта статья является описание моего опыта, а не прямым руководством к бездумному копированию.

{% load i18n %}
<div class="card box-shadow m-2">
  <div class="card-header">{{ objects_title }} <span class="badge badge-primary">{{ results_count }}</span>
  </div>
    {% if results|length > 0 %}
      {% for object in results %}
        {# You custom render of object #}
      {% endfor %}
      <div class="card-footer border-0"><a href="{{ search_url }}" class="btn btn-sm btn-outline-secondary">{{ all_search_message }}</a></div>
    {% else %}
      <div class="card-body">
        {% trans 'Nothing found' %}
      </div>
    {% endif %}
</div>

Файл "search/search_field.html"

<form method="get" class="my-3 px-3">
  <div class="input-group bmd-form-group pt-0">
  {% load i18n %}
    <input class="form-control" name="search" placeholder="{% trans 'Search' %}" value="{{ query_value }}" title="" type="text">
    <div class="input-group-append">
      <button type="submit" class="btn btn-outline-secondary mdi mdi-magnify mdi-0"></button>
    </div>
  </div>
</form>

Файл "urls.py"

Далее добавим SearchView в маршрутизатор Django .

# -*- coding: utf-8 -*-

from django.urls import path

from search import views

app_name = 'search'
urlpatterns = [
    path('', views.SearchView.as_view(), name='index'),
]

Вот так и будет выглядеть настройка для страницы полнотекстового поиска на Django, во всяком случае так будет выглядеть главная страница поиска. Но я также добавил страницы поиска по отдельным частям контента, что также важно. На главной странице поиска пользователь может посмотреть, можно ли найти хоть что-то на сайте по его запросу, а на детальных страницах пользователь сможет посмореть все найденные на сайте записи.

Класс "SearchViewByContent"

А теперь напишем более обощённый класс для поиска по разным видам контента. Для этого можно воспользоваться Generic классом ListView . Поиск будет осуществляться по полю поискового вектора. Также для правильной пагинации нам понадобится pagination url. Это всё присутствует в данном коде.

class SearchViewByContent(ListView):
    template_name = 'search/search_objects.html'
    paginate_by = 10

    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        context.update({
            'search': self.request.GET.get('search', None) or '',
            'last_question': self.get_pagination_url()
        })
        return context

    def get_pagination_url(self):
        return self.request.get_full_path().replace(self.request.path, '')

    def get_queryset(self):
        qs = super().get_queryset()
        query = self.request.GET.get('search', None)
        return qs.filter(search_vector=query)

Рендеринг страницы

Воспользуемся кодом уже существующего шаблона и расширим его поведение. Как видите, здесь используется шаблонный тег из батарейки django bootstrap 4 . В одной из предыдущих статей я уже описывал, как подключить эту батарейку более старой версии. С тех времён ничего не изменилось и статья также актульна и для последней версии django bootstrap 5.

{% extends 'search/index.html' %}
{% block search_result %}
  <div id="object-list">
  {% load bootstrap_pagination from bootstrap4 %}
  {% for object in object_list %}
    {# Render your object here #}
  {% empty %}
    <div class="card card-body mb-3">{{ not_found_message|default:_("Nothing found") }}</div>
  {% endfor %}
  {% if object_list %}
    <div class="mt-3">{% bootstrap_pagination object_list pages_to_show="3" url=last_question justify_content='center' %}</div>
  {% endif %}
  </div>
{% endblock %}

Добавим маршруты в файл "urls.py"

# -*- coding: utf-8 -*-

from django.urls import path

from search import views
from articles.models import Article, Comment

app_name = 'earch'
urlpatterns = [
    path('', views.IndexView.as_view(), name='index'),
    path('articles/', views.SearchView.as_view(queryset=Article.objects.all()), name='articles'),
    path('comments/', views.SearchView.as_view(queryset=Comment.objects.all()), name='comments'),
]

Таким образом поиск будет реализован уже по отдельным видам контента на сайте.

Поддержка мельтиязычности с использованием батарейки modeltranslation

Django modeltranslation является замечательным пакетом, который добавляет мультиязычность в ваши модели, но к сожалению он не совместим с полем SearchVectorField . Для этого нужно вручную добавлять новые поля SearchVectorField для каждого языка, который поддерживается на сайте. Но на самом деле это не так много работы. А выглядеть это может так

Модель

class Article(models.Model):

    # Another code

    # Search vectors
    search_vector = SearchVectorField(null=True)
    search_vector_ru = SearchVectorField(null=True)
    search_vector_en = SearchVectorField(null=True)

    objects = ArticleManager()

    class Meta:
        ordering = ['-pub_date']
        verbose_name = _('Article')
        verbose_name_plural = _('Articles')
        indexes = [
            GinIndex(fields=[
                "search_vector", "search_vector_ru", "search_vector_en",
            ]),
        ]

Соответственно новую миграцию нужно будет исправлять для каждого нового поля SearchVectorField

Просмотр поиска

А поисковый SearchView можно исправить следующим образом

class IndexView(View):
    template_name = 'evileg_search/index.html'

    def get(self, request, *args, **kwargs):
        query = request.GET.get('search', None)
        current_language = get_language()
        article_results = Article.objects.filter(
            Q(**{'search_vector_{}'.format(current_language): query}) |
            Q(search_vector=query)
        )
        comment_results = Comment.objects.filter(search_vector=query)

        return render(
            request=request,
            template_name=self.template_name,
            context={
                'search': query or '',
                'article_results': article_results[:3],
                'article_results_count': article_results.count(),
                'comment_results': comment_results[:3],
                'comment_results_count': comment_results.count(),
            }
        )

Тоже самое касается и отдельного "View" для статей. Попробуйте сами написать его отдельно и модифицировать запрос подобным образом, как и в этом View.

Также здесь есть важный момент. Я делаю поиск как по вектору с указанием языка, так и без указания языка. Это связано с тем, что я могу не иметь всех переводов для всех языков у какой-то конкретной статьи, а выдача результатов поиска, по моему мнению, всегда должна производиться.ю даже если перевод отсутствует.

Заключение

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