Привет, меня зовут Таня и я backend-разработчик в ИдаПроджект.
Сегодня хочу рассказать о полнотекстовом поиске — как это все работает в django, а как в postgres, и откуда вообще взялось.
Современные компании ежедневно сталкиваются с разной текстовой информацией. Эффективный поиск не только ускоряет доступ к нужным данным, но и повышает продуктивность, снижает затраты и открывает новые возможности для анализа и принятия решений.
Новичкам важно понять, как полнотекстовый поиск облегчает обработку данных и извлечение информации. Для тех, кто уже знаком с Django и PostgreSQL, статья станет экскурсом в полнотекстовый поиск, а заодно поможет интегрировать его в проекты.
Ну что, погнали! Разберем, как эта технология развивалась, и какие ее ключевые элементы (триграммы и tsvector) делают возможным быстрый и точный доступ к информации.
Оглавление
→ Откуда взялся полнотекстовый поиск?
→ Что такое SearchVector и триграммы
→ Как оно работает в postgresql?
Откуда взялся полнотекстовый поиск?
Начнем с определения.
Полнотекстовый поиск — технология поиска текстовой информации в электронных документах, где поиск выполняется по содержимому текста, а не только по метаданным или заголовкам. Такой подход стал необходимым с увеличением объемов данных и потребности извлекать нужную информацию быстро и эффективно. Давайте рассмотрим подробнее историческую основу и развитие этой технологии.
В 50-60-е годы ученые начали исследовать способы хранения и поиска текстовой информации. В тот период появились базовые подходы к информационному поиску. Полнотекстовый поиск не использовался широко из-за ограничений вычислительных мощностей и недостатков в теории и методах обработки текстовой информации.
В 70-е годы с развитием баз данных и алгоритмов обработки появилась концепция индексирования, которая позволяла строить структуры данных, оптимизирующие доступ к текстовой информации. Ключевыми понятиями стали обратные индексы, которые связывали слова с документами, в которых они встречаются. Это ускорило процесс поиска текста, поскольку системы могли обращаться к уже построенным таблицам слов, а не проверять каждый документ заново.
В 80-90-е годы активное внимание уделялось разработке алгоритмов ранжирования и улучшения качества поиска. В этот период был представлен алгоритм TF-IDF (Term Frequency-Inverse Document Frequency), который значительно улучшил релевантность поиска. Алгоритм оценивает важность каждого термина в документе, основываясь на частоте его появления и общем количестве документов.
В это же время развивалась PostgreSQL, где уже существовали базовые возможности работы с текстом, однако они не были оптимизированы для полнотекстового поиска. Пользователи могли искать текст через простые операторы LIKE и POSIX, но такие методы оказались неэффективными для больших объемов данных.
С распространением Интернета в конце 90-х и начале 2000-х годов полнотекстовый поиск стал ключевой технологией для веб-серверов и поисковых систем. Google, например, устроил революцию в поисковых технологиях, используя PageRank и другие методы для улучшения результатов поиска.
С появлением больших данных и сложных систем хранения информации необходимость во встроенных возможностях полнотекстового поиска в системах управления базами данных (СУБД) выросла. В начале 2000-х годов был разработан модуль TSearch, который впервые представил продвинутые возможности полнотекстового поиска в PostgreSQL. Он позволил индексировать текст и выполнять поиск по нему более эффективно.
TSearch2 стал логическим продолжением первой версии модуля. Именно здесь появились tsvector и tsquery как отдельные типы данных. Tsvector — это нормализованное представление текста, которое содержит уникальные лексемы (основные формы слов) и позиции их вхождения. Tsquery используется для описания условий поиска по tsvector.
Одной из основных задач, которые решают tsvector и tsquery, является оптимизация полнотекстового поиска. Tsvector позволяет преобразовать текстовые данные в форму, удобную для поиска и индексации. Это снижает объем выполняемых операций и ускоряет процесс извлечения информации из больших объемов текстов.
Кстати, авторы функционала наши соотечественики.
Что такое SearchVector и триграммы
В двух словах — это инструменты для улучшения поиска по текстовым данным в базе данных. Когда дело доходит до поиска (особенно по большим объемам текстовой информации), приходится использовать более сложные и эффективные методы, чем простое соответствие поля, чтобы находить нужные данные в большом количестве таблиц в БД.
SearchVector — это компонент, использующий возможности полнотекстового поиска в базе данных. Полнотекстовый поиск позволяет находить документы, содержащие искомые слова или фразы, учитывая морфологию и контекст. В Django есть интеграция с механизмами полнотекстового поиска PostgreSQL. SearchVector создает индекс, в котором хранятся лексемы слов из выбранных полей базы данных, что значительно ускоряет и улучшает качество поиска по ним.
Триграммы — техника, разбивающая текст на группы из трех символов. Например, слово «поиск» можно разбить на триграммы: «пои», «оис», «иск». Этот метод позволяет находить совпадения даже в случае опечаток или незначительных расхождений. В Django триграммы используются для реализации нечёткого поиска, что особенно полезно, когда пользователи могут совершать ошибки при вводе запросов.
Комбинирование SearchVector и триграмм позволяет создавать хорошие поисковые решения в своих проектах — SearchVector обеспечивает точный и быстрый поиск по хорошо структурированному тексту, в то время как триграммы добавляют гибкость, позволяя учитывать человеческий фактор, как опечатки или вариации в написании. Если использовать оба подхода, можно сделать приложения более удобными и интуитивно понятными для пользователей.
Итак, использование SearchVector и триграмм в Django помогает создавать более точные и гибкие поисковые алгоритмы. Это значительно увеличивает эффективность работы с данными, улучшая пользовательский опыт.
Как оно работает в postgresql?
В PostgreSQL полнотекстовый поиск реализован через специальные типы данных и операторы, такие как tsvector и tsquery.
tsvector — это тип данных, который хранит лексемы текста в специальном формате, подходящем для быстрого поиска. Он состоит из лексем и их позиций.
Создание tsvector происходит с помощью функции to_tsvector(). Функция to_tsvector() автоматически анализирует и преобразовывает текстовые данные в tsvector. Она отбрасывает стоп-слова, которые не имеют большого смысла для поиска (например, the, is), и приводит остальные к корневой форме.
Пример:
SELECT to_tsvector('english', 'The quick brown fox jumps over the lazy dog.');В результате вы получите tsvector, содержащий что-то вроде: ‘brown’:3 ‘dog’:9 ‘fox’:4 ‘jump’:5 ‘lazi’:8 ‘quick’:2.
Каждое слово преобразуется в форму «лексемы»: «jumps» → «jump», «lazy» → «lazi»; сохраняется информация о позиции слов в тексте.
tsquery — это тип данных, который представляет поисковый запрос. Он работает с теми же лексемами и поддерживает логические операторы, чтобы можно было составлять сложные поисковые выражения.
Для создания tsquery используется функция to_tsquery(). Примеры возможных операторов:
AND (&): Оба слова должны присутствовать. Пример: quick & fox.
OR (|): Любое из слов может присутствовать. Пример: quick | fox.
NOT (!) или -: Исключить слово. Пример: quick & !lazy.
Пример:
SELECT to_tsquery('english', 'quick & fox');Этот запрос будет искать все документы, где встречаются оба слова «quick» и «fox».
Для выполнения полнотекстового поиска нужно сопоставить tsvector и tsquery с помощью оператора @@.
Пример простого полнотекстового поиска:
SELECT * FROM documents WHERE to_tsvector('english', content) @@ to_tsquery('english', 'quick & fox');Этот запрос вернет все строки из таблицы documents, где в столбце content встречаются слова «quick» и «fox».
А что с индексами?
Поскольку полнотекстовый поиск может быть ресурсозатратным, часто используется индекс GIN (Generalized Inverted Index) для ускорения поиска по tsvector.
Что такое GIN-индекс?
Это обобщенный обратный индекс. Он позволяет быстро осуществлять поиск по текстовым данным путем построения структуры, которая связывает лексемы (ключи) с позициями, где они встречаются.
Обработка полнотекстовых поисковых запросов может быть медленной из-за необходимости сканирования всех строк. GIN-индекс помогает обойтись без полного сканирования таблицы, ускоряя поиск за счет подготовки данных во время индексации.
Создание GIN-индекса в PostgreSQL для полнотекстового поиска можно выполнить с помощью SQL-запроса:
CREATE INDEX idx_documents_content ON documents USING GIN(to_tsvector(‘english’, content));
Это позволяет ускорить выполнение запросов, сопоставляющих tsvector и tsquery.
В Django интеграция с PostgreSQL и его функциями полнотекстового поиска может быть реализована с помощью специальных методов и подходов. Одна из сторонних библиотек, облегчающих работу с полнотекстовым поиском в Django, — это django.contrib.postgres.
Шаги для создания GIN-индекса в Django:
Подготовка модели:
Модель должна иметь текстовое поле, по которому будет выполняться поиск. Например:
from django.db import models class Document(models.Model): title = models.TextField() content = models.TextField()Настройка индексации:
Импортируем класс GinIndex из модуля django.contrib.postgres.indexes, он позволит создать индекс GIN для текстового поля.
И вот тут, если следовать документации в Django, нас ожидает ошибка, т.к. обычный GIN-индекс не оптимально работает с Triggram-поиском. Лучше использовать gin_trgm_ops. Это позволит функциям (например, similarity), работать в разы быстрее, чем при обычном gin-индексе.
from django.contrib.postgres.indexes import GinIndex class Document(models.Model): title = models.TextField() content = models.TextField() class Meta: indexes = [ GinIndex(fields=['content']), ] Выполнение полнотекстового поиска:
Используйте Django ORM для выполнения полнотекстового поиска, применяя SearchVector и SearchQuery.
from django.contrib.postgres.search import SearchVector, SearchQuery from .models import Document def search_documents(search_term): vector = SearchVector('content') query = SearchQuery(search_term) results = Document.objects.annotate(search=vector).filter(search=query) return results Как оно работает в django?
В Django для того, чтобы начать использовать SearchVector, нужно сначала настроить модель и базу данных. Пример настройки может выглядеть так:
from django.contrib.postgres.search import SearchVector from django.db.models import F from .models import Article # Создаем вектор поиска на основе поля 'title' и 'content' vector = SearchVector('title', 'content') # Выполняем поиск по вектору articles = Article.objects.annotate(search=vector).filter(search='поиск') В этом примере мы создаем SearchVector, который включает поля title и content из модели Article. Затем мы используем его для фильтрации записей, содержащих искомый текст.
Чтобы использовать триграммы в Django, необходимо установить расширение trgm в PostgreSQL.
Сделать это можно двумя способами. Первый — через миграции:
from django.contrib.postgres.operations import TrigramExtension class Migration(migrations.Migration): operations = [ TrigramExtension(), ] Второй — напрямую в БД:
CREATE EXTENSION pg_trgm;В обоих случаях после добавления расширения нужно включить ‘django.contrib.postgres’ в INSTALLED_APPS.
После этого можно использовать модули Django для работы с ними. Приведу пример использования триграмм:
from django.contrib.postgres.search import TrigramSimilarity from .models import Article # Рассчитываем сходство для каждой записи similar_articles = Article.objects.annotate( similarity=TrigramSimilarity('title', 'искомый текст') ).filter(similarity__gt=0.3).order_by('-similarity') В SQL в этот момент происходит вот что:
SELECT *, similarity(title, 'искомый текст') AS similarity FROM Article WHERE similarity(title, 'искомый текст') > 0.3 ORDER BY similarity DESC;Здесь TrigramSimilarity вычисляет степень схожести между строками. Мы фильтруем статьи, у которых схожесть больше 0.3 — это порог, который вы можете настроить в зависимости от нужд проекта.
Пример комбинированного использования может выглядеть так:
from django.contrib.postgres.search import SearchVector, TrigramSimilarity articles = Article.objects.annotate( search=SearchVector('title', 'content'), similarity=TrigramSimilarity('title', 'искомый текст') ).filter(search='искомый текст').order_by('-similarity') Здесь наш SQL-запрос будет выглядеть так:
SELECT *, to_tsvector(title ' ' content) AS search, similarity(title, 'искомый текст') AS similarity FROM Article WHERE to_tsvector(title ' ' content) @@ plainto_tsquery('искомый текст') ORDER BY similarity DESC;Предположим, у нас есть следующая таблица Article:
|
id |
title |
content |
|
1 |
Как приготовить борщ |
Рецепт: вода, свекла, капуста… |
|
2 |
Готовим идеальный стейк |
Жарим стейк до готовности… |
|
3 |
Советы по уходу за садом |
Полив, обрезка и удобрение растений |
|
4 |
Приготовление супа |
Ингредиенты для супа: вода, соль… |
|
5 |
Борщ: классический рецепт |
Борщ с говядиной и свеклой… |
Поиск по триграммному сходству:
similar_articles = Article.objects.annotate( similarity=TrigramSimilarity('title', 'борщ') ).filter(similarity__gt=0.3).order_by('-similarity')Этот запрос находит статьи с заголовком, похожим на «борщ».
Результаты:
|
id |
title |
similarity |
|
5 |
Борщ: классический рецепт |
0.55 |
|
1 |
Как приготовить борщ |
0.50 |
Запрос:
articles = Article.objects.annotate( search=SearchVector('title', 'content'), similarity=TrigramSimilarity('title', 'борщ') ).filter(search='борщ').order_by('-similarity')Этот запрос выполняет полнотекстовый поиск в полях title и content и сортирует по триграммному сходству заголовка с «борщ».
Результаты:
|
id |
title |
similarity |
search_matches |
|
5 |
Борщ: классический рецепт |
0.55 |
title, content |
|
1 |
Как приготовить борщ |
0.50 |
title, content |
Таким образом, SearchVector быстро находит статьи, содержащие указанные слова, а триграммы помогают ранжировать найденные результаты в зависимости от их схожести с поисковым запросом.
Примеры
Как все это использовать без предварительного сохранения в базе, я уже разобрала базово выше. В двух словах — вот так:
from django.contrib.postgres.search import SearchVector from django.db.models import F from .models import Article # Создаем вектор поиска на основе поля 'title' и 'content' vector = SearchVector('title', 'content') # Выполняем поиск по вектору articles = Article.objects.annotate(search=vector).filter(search='поиск')Но поиск будет работать быстрее, если какие-то данные мы все же предварительно подготовим. Пример:
Создаем модель, в которую будем записывать, например, все предложения с тегом h1 и h2:
from django.contrib.postgres.indexes import GinIndex from django.contrib.postgres.search import SearchVectorField, SearchVector from django.db import models from search_engine.queryset import SearchPageQuerySet class SearchPage(models.Model): """Страницы.""" objects = SearchPageQuerySet.as_manager() link = models.URLField("Ссылка на страницу", max_length=200) h1 = models.TextField("Предложения с тэгом <h1>", blank=True) h2 = models.TextField("Предложения с тэгом <h2>", blank=True) search_vector = SearchVectorField(null=True) page_html = models.TextField("HTML страницы", blank=True) update_date = models.DateTimeField("Обновлён", auto_now_add=True) class Meta: verbose_name = "Страница" verbose_name_plural = "Страницы" indexes = [ GinIndex(name='h1_trgm_gin_ops', fields=["h1"], opclasses=['gin_trgm_ops']), GinIndex(name='h2_trgm_gin_ops',fields=["h2"], opclasses=['gin_trgm_ops']), GinIndex(fields=["search_vector"]), ] def __str__(self): return self.link Отдавать ее будем таким представлением, допустим нам нужно получать только ссылки на соответствующие страницы на сайте:
class SearchPageViewSet(GenericViewSet): """Поиск.""" pagination_class = None def get_queryset(self): return SearchPage.objects.all() def get_serializer_class(self): return SearchPageSerializer @action(detail=False, methods=["GET"]) def search_links(self, request, args, *kwargs): """Эндпоинт для получения ссылок на разделы сайта.""" queryset = self.get_queryset() if search_request := request.query_params.get("search_request"): search_request = search_request.strip() queryset = ( queryset.annotate_headline(search_request) .annotate_similarity(search_request) .filter(search_vector=search_request) .order_by("-best_similarity") ) serializer = self.get_serializer(queryset[:RESPONSE_LIMIT], many=True) return Response(serializer.data, status=status.HTTP_200_OK) А вот так должен выглядеть наш SearchPageQuerySet:
from django.contrib.postgres.search import SearchHeadline, TrigramSimilarity from django.db.models import QuerySet, Case, When, Q, CharField, F, FloatField from django.db.models.functions import Greatest HEADLINE_OPEN_TAG: str = "<b>" # тэг для обозначения слова из поиска в предложении HEADLINE_CLOSE_TAG: str = "</b>" # тэг для обозначения слова из поиска в предложении class SearchPageQuerySet(QuerySet): """Менеджер поиска.""" def aliash1_headline(self, search_request: str) -> "SearchPageQuerySet": return self.alias( h1_headline=SearchHeadline( "h1", search_request, start_sel=HEADLINE_OPEN_TAG, stop_sel=HEADLINE_CLOSE_TAG, ), ) def aliash2_headline(self, search_request: str) -> "SearchPageQuerySet": return self.alias( h2_headline=SearchHeadline( "h2", search_request, start_sel=HEADLINE_OPEN_TAG, stop_sel=HEADLINE_CLOSE_TAG, ), ) def annotate_headline(self, search_request: str) -> "SearchPageQuerySet": return ( self._alias_h1_headline(search_request) ._alias_h2_headline(search_request) .annotate( headline=Case( When(Q(h1_headline__contains=HEADLINE_OPEN_TAG), then=F("h1_headline")), When(Q(h2_headline__contains=HEADLINE_OPEN_TAG), then=F("h2_headline")) default=None, output_field=CharField(), ), ) ) def annotate_similarity(self, search_request: str) -> "SearchPageQuerySet": return self.annotate( similarity_h1=Case( When( ~Q(h1=""), then=TrigramSimilarity( F("h1"), str(search_request), ) ), default=0, output_field=FloatField() ), similarity_h2=Case( When( ~Q(h2=""), then=TrigramSimilarity( F("h2"), str(search_request), ) ), default=0, output_field=FloatField() ) best_similarity=Greatest(F("similarity_h1"), F("similarity_h2")) ) Итоговый SQL-запрос у представления будет такой:
SELECT "search_engine_searchpage"."id", "search_engine_searchpage"."link", "search_engine_searchpage"."h1", "search_engine_searchpage"."h2", CASE WHEN ts_headline("search_engine_searchpage"."h1", plainto_tsquery('sell'), 'StartSel=''<b>'', StopSel=''</b>''')::text LIKE '%<b>%' THEN ts_headline( "search_engine_searchpage"."h1", plainto_tsquery('sell'), 'StartSel=''<b>'', StopSel=''</b>''') WHEN ts_headline("search_engine_searchpage"."h2", plainto_tsquery('sell'), 'StartSel=''<b>'', StopSel=''</b>''')::text LIKE '%<b>%' THEN ts_headline( "search_engine_searchpage"."h2", plainto_tsquery('sell'), 'StartSel=''<b>'', StopSel=''</b>''') ELSE NULL END AS "headline", CASE WHEN NOT ("search_engine_searchpage"."h1" = '') THEN SIMILARITY("search_engine_searchpage"."h1", 'sell') ELSE 0 END AS "similarity_h1", CASE WHEN NOT ("search_engine_searchpage"."h2" = '') THEN SIMILARITY("search_engine_searchpage"."h2", 'sell') ELSE 0 END AS "similarity_h2", GREATEST(CASE WHEN NOT ("search_engine_searchpage"."h1" = '') THEN SIMILARITY("search_engine_searchpage"."h1", 'sell') ELSE 0 END, CASE WHEN NOT ("search_engine_searchpage"."h2" = '') THEN SIMILARITY("search_engine_searchpage"."h2", 'sell') ELSE 0 END) AS "best_similarity" FROM "search_engine_searchpage" WHERE "search_engine_searchpage"."search_vector" @@ plainto_tsquery('sell') ORDER BY "best_similarity" DESC LIMIT 5А забирать данные при этом он будет примерно из такой таблицы:
|
id |
link |
h1 |
h2 |
headline |
similarity_h1 |
similarity_h2 |
best_similarity |
|
1 |
Пример данные |
Дополнительная информация |
<b>Пример</b> данные |
0.8 |
0.0 |
0.8 |
|
|
2 |
Еще пример |
Пример данных |
NULL |
0.6 |
0.9 |
0.9 |
Такой столбец headline будет содержать разметку <b> вокруг слов, соответствующих поисковому запросу. Столбцы similarity_h1 и similarity_h2 показывают степень схожести строк с запросом, а best_similarity выбирает наибольшее значение из них для сортировки.
Дальше начинается самое интересное — чтобы что-то отдать, нам нужно собрать данные по сайту.
Для этого нам понадобится «паук» — сервис, который будет ходить, например, по сайтмэпу, собирать страницы, искать в них заголовки h1 и h2 (и какие угодно еще теги). Подробнее про спайдеры, какие еще они бывают, и как их использовать, можно посмотреть здесь.
Для примера возьмем за основу SitemapSpider:
class SiteSpider(SitemapSpider): """Паук для сбора данных со всех страниц сайта через sitemap.""" name: str = "site_spider" sitemap_urls: list[str] = [settings.SITE_MAP] http_user = ( getenv("BASIC_AUTH").split(":")[0] if getenv("BASIC_AUTH") and getenv("HTPASSWD_NODE") != "off" else None ) http_pass = ( getenv("BASIC_AUTH").split(":")[1] if getenv("BASIC_AUTH") and getenv("HTPASSWD_NODE") != "off" else None ) parse_tags: list[str] = PARSE_TAGS replace_item_with_space: list[str] = REPLACE_ITEM_WITH_SPACE remove_items: list[str] = REMOVE_ITEMS specific_chars: str = REMOVE_SPECIFIC_CHARS search_model: Type[Model] = SearchPage # модель, куда сохраняем спарсенные данные def parse(self, response: Response, **kwargs: Any) -> None: """Основная функция, которая вызывается при запуске паука.""" data = self._collect_data_from_site(response) self._create_update_model(data) def collectdata_from_site(self, response: Response) -> dict[str, dict[str, str]]: """Парсинг данных по страницам.""" url = response.request.url data: dict[str, dict[str, str]] = {} sentence_dict: dict[str, str] = {} for tag in self.parse_tags: sentence_dict[tag] = self._get_tag_text_from_response(tag, response) data[f"{url}"] = sentence_dict return data def gettag_text_from_response(self, tag: str, response: Response) -> str: """Получения списка текстов тэга.""" sentences: list = [] for sentence in response.css(f"{tag}::text").getall(): sentence = sentence.strip() for item in self.replace_item_with_space: sentence = sentence.replace(item, " ") for item in self.remove_items: sentence = sentence.replace(item, "") if sentence and sentence not in sentences: sentences.append(sentence) return ";".join(sentences) def createupdate_model(self, data: dict[str, dict[str, str]]) -> None: """Обновление/создание моделей с данными для поиска.""" for link, tags in data.items(): try: search_model = self.search_model.objects.get(link=link) if tags: search_model.h1 = tags.get("h1") search_model.h2 = tags.get("h2") search_model.save(force_update=True) else: search_model.delete() # удаление объекта, если нет ключевых слов и предложений для поиска except self.search_model.DoesNotExist: if tags: search_model = self.search_model( link=link, h1=tags.get("h1"), h2=tags.get("h2"), ) search_model.save()Нужно понимать, что при использовании в виде нам будет необходимо пересчитывать поля SearchVectorField. Для этого можно написать сигнал, чтобы он запускал сбор данных при сохранении интересующих нас моделей или задачу, которая будет заниматься этим по расписанию — все, данные готовы, поиск работает, вы молодец!
И еще момент: мы используем подход предварительного расчет search_vector. Это реализовано с помощью django signals. То есть при сохранении страницы мы всегда пересчитываем итоговый поисковый вектор и сохраняем его. Это позволяет оптимизировать скорость выполнения SQL, поскольку не нужно переводить строки в ts_vector в момент выполнения запроса.
@receiver(post_save, sender=SearchPage) def calculate_search_vector(instance: SearchPage, **kwargs: dict) -> None: """Расчет поисковых векторов.""" search_vector = ( SearchVector("h1", weight="A") + SearchVector("h2", weight="B") ) SearchPage.objects.filter(id=instance.id).update(search_vector=search_vector)А что под нагрузкой, м?
Сейчас проверим. Для генерации нагрузки будем использовать Grafana K6.
Методология тестирования
Процесс генерации нагрузки будет происходить следующим способом: мы сначала найдем части слов, а потом из ответа выберем первые два варианта и по ним отыщем ссылки.
Более подробнее о том, как мы тестируем, можно почитать вот здесь.
Настройки сервера типичные: 16 ядер и 16 гигабайт оперативной памяти. Веб-сервер запустим на gunicorn со следующими настройками: gunicorn config.wsgi:application -w 16 —keep-alive 120 -b 0.0.0.0:8000 —max-requests 10000 —max-requests-jitter 1000
Вот наш базовый сценарий:
// Начало сценария const word_list = ['young', 'yet', 'yes', 'year', 'yeah', 'yard', 'wrong', 'writer', 'write', 'would'] // Проходимся по списку слов и запрашиваем похожие слова for (const word of word_list) { let cut_word = word.slice(0, 3); console.log(word, cut_word); let response = requestGetAPI(/api/search_page/search_words/?format=json&search_request=${cut_word}, {tags: {type: 'search_words'}}) sleep(1) let response_word_list = response.json() console.log(response_word_list) // Итерируемся по списку полученных слов for (const response_word of response_word_list) { // Получаем ссылки requestGetAPI(/api/search_page/search_links/?format=json&search_request=${response_word}, {tags: {type: 'search_link'}}) sleep(1) } }Для начала запустим Smoke-тестирование, чтобы понять, что все наши API работают и отдают нужные данные. Параметры следующие:
// SMOKE TEST smoke_test_api: { // Функция генерации нагрузки, их там много, почитайте документацию K6 executor: 'constant-vus', // Количество "виртуальных пользователей" vus: 5, // Время выполнения теста duration: '20s', // Какую функцию мы запускаем exec: 'scenario_api', }Результаты:
При тестировании будем опираться на метрики http_req_duration (за сколько секунд выполнился запрос), а именно: 95 персентиль (он равен 191 мс), а также на http_reqs (количество запросов в секунд; здесь он равен 4.4 запроса в секунду). Насколько хороший результат выйдет без кеширования, решать вам, но для нас с учетом синхронной Django это уже отлично.
Итак, давайте проведем BREAKPOINT TEST, в котором постепенно повысим RPS и будем ждать момента, когда API начнет деградировать.
Конфигурация теста:
// BREAKPOINT TEST breakpoint_test_api: { executor: 'ramping-arrival-rate', preAllocatedVUs: 100, maxVUs: 10000, stages: [ {duration: '1m', target: 10}, {duration: '5m', target: 1000}, ], exec: 'scenario_api', }По итогам мы получили такие показатели:
Почти 40% нагрузки ушло на бэкенд и 60% — на базу данных. Конечно, в текущем кейсе синхронная Django на gunicorn будет на порядки проигрывать по производительности асинхронным python фрейморкам. Но тут главное — получить приблизительные цифры, от которых можно отталкиваться при дальнейших тестах.
По графикам в grafana видно, что при 50-60 RPS начали появляться timeout соединений.
В отчете самой Grafana k6 можно увидеть чуть больше информации. Среднее время ожидания (http_req_duration) под нагрузкой составило 38 секунд, что, конечно, ужасно, но тут сильно повлияли упавшие запросы. А количество запросов в секунду вышло 52, но тут стоит отнять 10-15%, ведь предельный RPS сильно смазывается упавшими запросами.
В текущей конфигурации эти данные нам подходят.
Дальше в идеале нужно рассмотреть производительность самой БД — в отрыве от использования бекенда.
Но тут я стала проверять конфигурацию БД и поняла, что мы использовали стандартную конфигурацию и не выжали все возможные соки из БД в базовой связке. Поэтому давайте поставим нормальные настройки и проведем еще один нагрузочный тест 🙂
Конфигурация БД:
db: image: postgres:17-alpine volumes: - postgresdata17:/var/lib/postgresql/data restart: unless-stopped ports: - "5432:5432" environment: - POSTGRES_PASSWORD - POSTGRES_PORT - POSTGRES_NAME - POSTGRES_USER - POSTGRES_HOST_AUTH_METHOD=trust command: - "postgres" - "-c" - "max_connections=150" - "-c" - "shared_buffers=4GB" # 25% от текущей оперативной памяти - "-c" - "effective_cache_size=4GB" - "-c" - "work_mem=64MB" # shared_buffers поделить на max_connections. Если получается меньше 32МБ, то оставить 32МБ - "-c" - "maintenance_work_mem=1024MB" # 10% от оперативной памяти - "-c" - "temp_file_limit=10GB" - "-c" - "idle_in_transaction_session_timeout=10s" - "-c" - "lock_timeout=1s" - "-c" - "statement_timeout=60s" - "-c" - "shared_preload_libraries=pg_stat_statements" - "-c" - "pg_stat_statements.max=10000" - "-c" - "pg_stat_statements.track=all"Нагрузка распределилась почти так же, как и в прошлый раз.
RPS-показатели те же самые.
Здесь показатели примерно такие же, но http_reqs ниже, ведь как только тест начал выдавать ошибки, мы сразу его отключили. Это можно заметить по параметру checks — он выше, чем в прошлый раз. Так что этот тест более релевантный, чем прошлый.
Собственно, базовые настройки БД не оказали сильного влияния на работу сервиса в связке Django + БД.
Заключение
Мы с вами рассмотрели основные аспекты реализации полнотекстового поиска с использованием Django и PostgreSQL. Это сочетание позволяет создавать эффективные системы поиска без привлечения сторонних инструментов и представляет собой баланс между простотой реализации, производительностью и гибкостью конфигурации.
Встроенной функциональности PostgreSQL вполне может оказаться достаточно для большинства веб-приложений, что позволит существенно сэкономить время и ресурсы на разработку и поддержку поисковой системы.
На этом у меня все, если есть что добавить или посоветовать — велком в комменты 🙂
Источники:
https://www.postgresql.org/docs/current/textsearch.html
https://www.postgresql.org/docs/current/textsearch-tables.html
https://postgrespro.ru/docs/postgresql/17/pgtrgm
https://docs.scrapy.org/en/latest/topics/spider-middleware.html
ссылка на оригинал статьи https://habr.com/ru/articles/891578/
Добавить комментарий