Полнотекстовый поиск (Full-Text Search, FTS) это когда вы ищите какие-то документы, скажем, товары в интернет-магазине или статьи в блоге, по текстовому запросу, как в Google. Немногие знают, что в PostgreSQL из коробки есть полнотекстовый поиск, притом, в отличие от некоторых других РСУБД, очень даже неплохой. Далее в этой заметке будет рассказано, как им пользоваться.
Введение
Использовать встроенный в PostgreSQL полнотекстовый поиск вместо связки из PostgreSQL и специализированного ПО для FTS, такого, как Sphinx, ElasticSearch или Solr, интересно по следующим причинам. Во-первых, данные не приходится хранить в двух экземплярах. То есть, если у вас 500 Гб данных, не приходится использовать 1 Тб места на диске, что есть удобно. Во-вторых, данные всегда консистентны.
Скажем, если у вас связка из PostgreSQL и ElasticSearch, и синхронизация документов работает с запаздыванием или ломается, в поиске вы можете увидеть ерунду. Например, уже удаленные документы. Наконец, в-третьих, не приходится устанавливать и поддерживать какого-либо дополнительного ПО — обновлять его, бэкапить, мониторить, писать какие-то скрипты синхронизации, и так далее. Если у вас уже есть PostgreSQL, все просто работает.
Get Paid $2,000 In One Day With This DONE FOR YOU ARTICLES TRICK! (Make Money Online)
Из преимуществ Sphinx, Solr и так далее, следует отметить как минимум то, что будучи специализированными средствами для полнотекстового поиска, они могут работать быстрее. Хотя бы по той причине, что им не приходится беспокоиться о транзакциях, проверках целостности данных, и так далее. Если на каком-то этапе развития проекта вы видите, что скорость полнотекстового поиска в PostgreSQL вас не устраивает, и вы не видите простого способа это исправить (вертикальное масштабирование, добавить реплик, тюнинг параметров), имеет смысл обратить внимание на альтернативы. Поскольку делать бенчмарки правильно очень сложно, вопрос сравнения производительности решений для FTS я вынужден оставить за рамками сего поста.
Все описанное ниже было проверено на PostgreSQL 10, который на момент написания статьи находился в бете. Отличия от других версий, как более ранних, так и более поздних, по идее должны быть минимальными.
Немного теории
Для полнотекстового поиска в PostgreSQL предусмотрено несколько специальных типов.
Тип tsvector представляет собой что-то вроде нормализованной строки, по которой будет производиться поиск. Под нормализацией понимается выкидывание стоп-слов, таких, как предлоги, обрезание окончаний слов, и так далее. Преобразование обычной стоки в tsvector осуществляется при помощи процедуры to_tsvector:
# select to_tsvector(‘My name is Alex and I»m a software developer.’);
to_tsvector
—————————————————
‘alex’:4 ‘develop’:10 ‘m’:7 ‘name’:2 ‘softwar’:9
(1 row)
# select to_tsvector(‘russian’, ‘Меня зовут Саша и я программист.’);
to_tsvector
————————————
‘зовут’:2 ‘программист’:6 ‘саш’:3
Гуманитарный пароль. Что делать дальше? Пошаговая детальная инструкция по Сакраменто.
(1 row)
Тип tsvector можно конкатенировать:
# select to_tsvector(‘Hello,’) || to_tsvector(‘world!’);
?column?
———————
‘hello’:1 ‘world’:2
(1 row)
Тип tsquery используется для представления запросов. Для преобразования строки с запросом в tsquery используется процедура to_tsquery:
# select to_tsquery(‘Hello | world’);
to_tsquery
——————-
‘hello’ | ‘world’
(1 row)
# select to_tsquery(‘russian’, ‘Привет
to_tsquery
——————
‘привет’
plainto_tsquery
——————-
‘hello’
phraseto_tsquery
———————
‘привет’ ‘мир’
(1 row)
Все это, конечно, здорово. Вот только доставать из базы мы хотим не константы, а конкретные поля, и для этого, наверное, нужно использовать какие-то индексы. Для полнотекстового поиска PostgreSQL предлагает два индекса на выбор:
- GIN — быстро ищет, но не слишком быстро обновляется. Отлично работает, если вы сравнительно редко меняете данные, по которым ищите;
- GiST — ищет медленнее GIN, зато очень быстро обновляется. Может лучше подходить для поиска по очень часто обновляемым данным;
Если сомневаетесь, берите GIN. Обычно все используют именно его. GiST же имеет смысл использовать при довольно экзотической нагрузке. Узнать чуть больше о кишочках работы полнотекстового поиска поверх GIN и GiST можно здесь.
Fun fact! Заметьте также, что если у вас небольшой объем данных, который полностью помещается в память, может оказаться, что по нему быстрее искать вообще без индексов.
Это, конечно, далеко не вся теория, но для начала нам хватит. С остальными моментами мы разберемся уже по ходу.
Практика
Для эксперимента попробуем сделать полнотекстовый поиск по статьям из Википедии. Ссылку на скачивание дампа Википедии, а также скрипт на Python для импорта этого дампа в PostgreSQL, вы найдете в этом репозитории на GitHub.
Здесь же я приведу только схему таблицы:
CREATE TABLE IF NOT EXISTS
articles ( id SERIAL PRIMARY KEY , title VARCHAR ( 128 ) , content TEXT ) ;
Само собой разумеется, импортировать всю Википедию целиком не требуется. При написании этой заметки мною использовалась таблица, содержащая всего лишь 25 117 статей.
Чтобы избежать дублирования кода, нам понадобится следующая хранимая процедура на PL/pgSQL:
CREATE OR REPLACE FUNCTION make_tsvector ( title TEXT , content TEXT )
RETURNS tsvector AS $$
BEGIN
RETURN ( setweight ( to_tsvector ( ‘english’ , title ) , ‘A’ ) ||
setweight ( to_tsvector ( ‘english’ , content ) , ‘B’ ) ) ;
END
$$ LANGUAGE ‘plpgsql’ IMMUTABLE;
Данная процедура принимает заголовок и содержимое статьи и возвращает соответствующий ей tsvector. Здесь используется новая для нас процедура setweight, с тем, чтобы придать заголовкам статьи больший вес, чем содержимому. Веса потребуются нам чуть позже для ранжирования статей. Заметьте, что представленная процедура была объявлена, как immutable, чтобы ее можно было использовать при построении индекса.
Итак, теперь построим индекс и попробуем поискать с его помощью статьи:
CREATE INDEX IF NOT EXISTS idx_fts_articles ON articles
USING gin ( make_tsvector ( title , content ) ) ;
Используемый в to_tsquery оператор означает, что слова должны идти последовательно друг за другом. В моем случае результат получился таким:
id | title
——-+————————————————————
2470 | Binary search algorithm
2129 | Bell Labs
2130 | Bjarne Stroustrup
3665 | C (programming language)
.
(17 rows)
Обратите внимание на время выполнения запроса. Довольно неплохо для поиска по 25 тысячам статей, особенно для моего не такого уж и нового ноутбука.
Давайте теперь попробуем как-то выделить Бьерна в результатах поиска, чтобы его было лучше видно:
Обратите внимание на использование новой для нас процедуры ts_headline, а также на переменную q , благодаря которой tsquery не приходится писать два раза. Результат:
id | ts_headline
——-+————————————————————
2470 | Binary search algorithm
2129 | Bell Labs
2130 | Bjarne Stroustrup
3665 | C (programming language)
.
(17 rows)
Способ выделения при желании можно и изменить:
id | ts_headline
——-+————————————————————
2470 | Binary search algorithm
2129 | Bell Labs
2130 | Bjarne Stroustrup
3665 | C (programming language)
.
(17 rows)
Наконец, можно отсортировать статьи по их релевантности:
Обратите внимание на использование новой для нас процедуры ts_rank.
id | ts_headline
——-+————————————————————
2130 | Bjarne Stroustrup
3665 | C (programming language)
6266 | Edsger W. Dijkstra
11825 | Legacy system
2470 | Binary search algorithm
20432 | Template (C++)
2129 | Bell Labs
.
(17 rows)
Само собой разумеется, время выполнения запроса увеличилось. Заметьте, что при использовании GIN и GiST сортировка документов по релевантности происходит в памяти. Это может плохо работать при плохой селективности запросов. Если это как раз ваш случай, советую ознакомиться с новым индексом для полнотекстового поиска под названием RUM, решающим описанную проблему. Используется он практически так же, как и GIN, поэтому в рамках данного поста более подробно на RUM мы останавливаться не будем.
Приведенных выше сведений вам будет более чем достаточно в 95% случаев. Дополнительную информацию можно найти по следующим ссылкам:
- Официальная документация PostgreSQL по полнотекстовому поиску является неисчерпаемым кладезем знаний;
- Также рекомендую ознакомиться с документацией по GIN. Например, из нее можно узнать про параметр fastupdate = off . Он увеличивает время обновления индекса, но зато делает его куда более предсказуемым, что в некоторых случаях может быть полезным.
- Модуль pg_trgm предназначен для поиска по триграммам. В частности, с его помощью можно находить что-то даже по запросам, содержащим опечатки;
- Начиная с PostgreSQL 10 полнотекстовый поиск также превосходно работает по JSON’у прямо из коробки;
- На HabraHabr есть прекрасная серия статей за авторством Егора Рогова, посвященная индексам в PostgreSQL. В частности,
подробно рассматривается устройство индексов GIN, GiST и RUM;
Как видите, полнотекстовый поиск в PostgreSQL работает достаточно хорошо. Особенно, если учесть, что от разработчика приложения для этого не требуется ничего, кроме создания дополнительного индекса. Как уже отмечалось, в специализированных решениях полнотекстовый поиск вполне может работать быстрее, чем в PostgreSQL. Хотя, возможно, это и не так — я не проверял. Так или иначе, есть множество приложений, которым полнотекстового поиска PostgreSQL будет более, чем достаточно.
А что вы в это время суток используете для полнотекстового поиска, и каковы ваши впечатления от используемого решения?
Вы можете прислать свой комментарий мне на почту, или воспользоваться комментариями в Telegram-группе.
Источник: eax.me
Instant articles Facebook: что это за функция и чем она полезна?
У Facebook есть множество небольших, но полезных функций, о которых мало кто знает. К таким функциям относится и Instant Articles Facebook . Немногие знают, что это и как это правильно использовать. Мы постараемся исправить эту ситуацию.
Instant Articles на Facebook работают уже с 2015 года, но до сих пор не получили должного распространения. Функция Instant Article s д елает из ваших обычных статей «моментальные статьи».
Instant Articles Facebook — что это
Instant Articles на Facebook или моментальные статьи — это максимально «облегченные» версии статей с вашего сайта для удобного показа их на смартфонах. Фейсбук самостоятельно определяет, что можно «урезать» из статьи, чтобы она стала максимально облегченной и быстро загружалась прямо внутри соцсети и без перехода на ваш сайт.
Практически Instant Articles — это не какая-то отдельная статья или обработка статьи, эт о функция, которую в ы к ак автор, который постоянно делится своими статьями на Facebook, можете включить или отключить. «Облегченная» стать я о станется «облегченной» д аже в том случае, когда вашей статьей кто-нибудь поделится на своей странице, поэтому если любой пользователь Фейсбук а к ликнет по «облегченной» статье, то она откроется моментально.
Полезность Instant Articles Facebook
- мгновенную загрузку контента, даже если у них слабый мобильный интернет;
- увеличение фотографий по одному клику по ним;
- воспроизведение видео и аудио в автоматическом режиме;
- возможность комментировать не только всю статью, но отдельное видео или изображение;
- и др.
Instant Articles на Facebook: как начать пользоваться
- Зарегистрироваться в Creator Studio. Это внутренняя площадка Фейсбука, откуда вы сможете управлять контентом в самой соцсети и в Инстаграм е . Именно из этого кабинета вы можете настраивать моментальные статьи, а также их монетизировать. Для регистрации на этой площадке у вас должен быть аккаунт на Фейсбук е и ст ра ница для публикации кон те нта.
- Нужно настроить моментальные статьи на странице. Как только вы добавите свою страницу в вышеописанный сервис, то в ее функциях появится пункт настройки для управления контентом и монетизации моментальных статей. Зайдите в этот пункт. При необходимости выполните настройку или оставьте все по умолчанию.
- Н еобходимо подобрать способ импорта статей. Если у вас сайт на какой-либо популярной CMS, то для импорта статей есть специальные плагины от Фейсбука. Например , для сайта на WordPress это плагин Instant Articles for WP. Установите и настройте плагин, для этого вам нужен будет ID вашей страницы на Ф е йсбуке.
- Подтвердите права на сайт. С этим проблем возникнуть не должно, если вы владелец сайта. Обычно это делается путем вставки специального кода в раздел «head». На самом Facebook вам подскажут доступные способы для подтверждения ресурса.
- Необходимо отправить несколько статей, чтобы их проверили. Все п р оисходит в автоматическом режиме, вам нужно будет только нажать кнопку «Отправить на проверку» , и Фейсбук самостоятельно выберет 10 последних статей с ресурса и проверит их на пригодность. Такая проверка обычно занимает до 5 дней. Если ваши статьи подходят для создания моментальных статей, тогда вам подключат функцию Instant Articles, если нет — то нет.
Заключение
Инструменту Instant Articles на Facebook уже очень много лет, но при этом он до сих пор не набрал должную популярность в странах СНГ. Так что если вы воспользуетесь им сегодня, то все равно окаж е тесь в числе его первых пользователей.
В процессе пользования этой функцие й г лавное — поддерживать качество статей, чтобы на них был а реакция от пользователей соцсети , и регулярно публиковать моментальные статьи. Если не соблюдать эти правила, то данную функцию могут отозвать , и тогда процедуру подключения необходимо будет проходить с самого начала.
Что бы я хотел знать когда начинал изучать Django? — очень общий взгляд
Здесь на Хабре много различных инструкций по использованию Django. Эти инструкции часто включают много кода и представляют последовательность шагов, которые нужно сделать, чтобы создать проект.
Когда я начинал изучать Django и Wagtail по таким инструкциям, меня часто смущало, что пара команд создает кучу непонятных файлов (особенно на самом старте). Последующее описание этих файлов в инструкциях содержало слишком много деталей, которые трудно было усвоить за раз.
В этом посте я бы хотел посмотреть на Django с очень «философского вида» — минимум кода, максимум общих фактов. Думаю, что такой взгляд поможет тем, кто хочет начать изучать Django но теряется на старте.
Хочу также сказать, что не являюсь профессионалом по части веб-программирования — я в этой области скорее любитель, которого интересуют исключительно личные проекты — один из них сайт по расшифровке данных ДНК тестов https://ru.bezoder.com — написан на Wagtail.
Сначала давайте вспомним, что сайт в интернете это просто программа, которая, возможно, работает почти на таком же компьютере, что находится перед вами.
Ваш компьютер (телефон и т.п.) посылает какой-то запрос к чужому компьютеру в интернет, тот его обрабатывает и отвечает. При обработке чужой компьютер, возможно, делает запрос или производит запись в базу данных. Теперь представим, что необходимо запрограммировать компьютер в интернете, чтобы он правильно обрабатывал каждый запрос.
Это можно сделать вообще на каком угодно языке программирования — вы получаете запрос и на его основе что-то выполняете. Но представьте сколько может быть вариантов как запрограммировать этот компьютер — их может быть бесконечно много! Например, можно написать функцию что-то вроде:
Если запрос == google.ru: ответ «Привет» Если запрос == google.de: ответ «Hallo» .
Думаю, понятно, что это был бы ужасный вариант программирования.
Нам нужно сделать все так, чтобы код был читаемым, безопасным, легко дополняемым, использовал какие-то возможности языка, на котором написан…
С таким набором задач нужно придумать какую-то концепцию.
Концепция Django
Django предлагает все разделить на «слои». Слои отвечают за разные составляющие вашей программы. Между слоями есть связь, но она не затрудняет разработку каждого слоя изолированно (без большого внимания к другим слоям) — в Django это называется loose coupling.
Вот несколько важных слоев Django:
- Модели (Models) это слой ваших данных и то как вы их храните их в базе данных
- Виды (views) этот слой собирает все данные которые необходимо для создания веб страниц или обработки данных, отправленных через формы
- Шаблоны (Templates) этот слой получает данные из видов и отображает их на вебстранице (в этом слое вы работаете уже с html)
- Ссылки (url) этот слой организует работу ссылок на вашем сайте на какую ссылку нужно создавать какой вид и какой шаблон
- Формы (Forms) этот слой помогает создавать и обрабатывать веб формы для данных от пользователей
- .
Тут я немного подробнее остановлюсь на слоях Модели, Виды и Шаблоны.
Слой модели
Первый и, наверно, самый важный слой это модели(models) — отвечает за базу данных. База данных это много всяких таблиц — например, может быть таблица «пользователи» такого вида:
| ID | name | surname | karma |
| 1 | Михаил | Трунов | 2 |
Как видите, в базе каждая строка это запись, относящаяся к пользователю сайта. В строке есть данные различного типа — в нашем случае числа и текст.
Распространенным языком баз данных является SQL — определенными командами вы можете создавать новые таблицы в базе или вносить и получать данные в и из существующих таблиц.
У SQL есть уязвимости — подробнее. Вкратце — если определенным образом расставить кавычки и точки с запятой в данных, которые отправляются в SQL команду, часть этих данных может быть интерпретирована как составляющая SQL команды.
Django берет всю головную боль, связанную с проблемами SQL на себя — вам даже не надо знать SQL, чтобы пользоваться Django, от вас нужен только python — Django сам сформирует SQL команды для создания таблиц, поиска и записи данных в таблицы и все это будет безопасно.
Идея Django в том, что классы на python повторяют структуру таблиц вашей базы данных.
То есть, для таблицы выше я могу создать класс в python что-то вроде:
class User: def __init__(id, name, surname, karma) self.id = id self.name = name .
но как связать такой класс с базой данных? Вот тут начинается магия Django:
Вы просто используете django.db.models.Model чтобы создать класс, далее каждое поле в вашем классе это также поле, взятое из django.db.models. В моем случае поле name это текстовое поле CharField, поле karma это число float. Список всех полей (Field types) есть в официальной документации.
У каждого поля есть опции (Field options) — в коде выше опция это max_length = 20. Опции зависят от полей, которые вы создаете в базе — например, max_length = 20 это максимальная длина в символах поля name в базе. В документации по ссылке выше также описаны опции для всех полей.
На основе этого кода Django сам создаст таблицу в базе данных и то, что я назвал полями в классе будут столбцами в этой таблице. Django дает вам также удобные команды в python как получать или записывать значения в базу данных. Все делается с помощью методов models.Model а также абстракции «Manager», отвечающей в Django за коммуникацию с базой данных (в данном посте я эти абстракции детально не рассматриваю). Например, CustomUser.objects.filter(name=«Михаил») вернет всех пользователей с именем «Михаил».
Такая связь между строками в базе данных и объектами (экземплярами, инстансами) в Python называется Object-relational mapping — в нашем случае Django-ORM.
А наши модели повторяют структуру базы данных и при этом являются классами в Python. Это значит, что к моделям (классы в Python) можно добавить методы. Например, продолжая логику сайта Хабр, я могу добавить метод для изменения кармы:
from django.db import models class CustomUser(models.Model): . # пример метода в модели Django def change_karma(self, other): . if . self.karma = self.karma +1 . else: .
Тут other — это другой пользователь. Как вы знаете здесь определенная логика добавления кармы. Всю эту логику я могу, например, создать в указанном методе.
В Django вы думаете какие таблицы хотите создать в своей базе и потом просто создаете классы python по примеру выше.
Слой виды
Следующим важным, на мой взгляд, слоем является слой видов (views). Ваши модели это некоторые абстракции, с которыми вам удобно работать или они интуитивно понятны. Но, когда вы хотите что-то показать пользователям, то, возможно, вас будут интересовать иные абстракции.
Например, вы создали три модели в Django: CustomUser, Article и Advertisement с разными полями. Модель Article это статья сайта, Advertisement — это реклама, которую вы показываете на сайте, CustomUser — зарегистрированный пользователь сайта.
Есть два типа видов view в Django — функциональный и классовый.
Функциональный вид это просто Python функция с аргументом request — это запрос к вашему сайту. В нем содержится информация о пользователе, типе запроса и многом другом. На основе этой информации вы формируете ответ и возвращаете его в своей функции.
Еще один тип view — классовый. Он позволяет создавать виды не на основе функций, а виды как экземпляры классов. Тут Django предоставляет также кучу всяких облегчающих жизнь классов и функций. Предположим, вы хотите создать вид на основе статьи Article:
# импорт полезного класса from django.views.generic import DetailView # импорт созданной в другом файле модели Article from .models import Article # создание классового вида class ArticleDetailView(DetailView): # модель на основе которой мы хотим создать вид model = Article # имя, которое будет использовано в html шаблоне (это другой слой — рассмотрим далее) context_object_name = ‘article’ # имя html шаблона, на основе которого будет создана веб страница template_name = ‘article/article_detail.html’
Классовый вид на основе DetailView автоматически соберет всю информацию модели Article и затем отправит ее в следующий слой Django:
Слой шаблоны
В коде выше template_name это переменная для названия html шаблона, который будет использован для формирования веб страницы, которая и будет показана пользователю. Вот пример кода из такого шаблона:
Резюме
Это общий взгляд на некоторые Django слои. Описанная концепция позволяет разделить отдельные блоки программы. В слое модели вы создаете удобные абстракции вашей базы данных, в слое виды вы решаете, какие данные вы хотите показать, и в слое шаблоны вы создаете уже дизайн ваших страниц на основе html и добавляете в шаблоны немного логики с помощью языка Jinja — это из примера с фигурными скобками — >.
Я тут не затронул довольно много важных тем — например связи между вашими моделями. У каждой статьи может быть один автор или несколько авторов — Django с легкостью справится с любым из перечисленных вариантов, и с помощью одной строки в Python вы сможете получить автора статьи или же коллекцию авторов в виде экземпляров класса Автор, созданного на основе models.Model.
Но откуда столько файлов?
Если вы создаете какое-то сложное приложение с кучей Моделей, видов и т.п. то это огромное количество кода надо как-то разбить на отдельные файлы. И файлы желательно организовать по папкам так, чтобы файл с моделями статьи был в той же папке что и виды статьи.
Вот тут приходит еще одна ключевая идея Django — приложения, которые заслуживают отдельного поста.
Источник: habr.com