Поиск может отвечать быстро и при этом работать некорректно: показывать удалённую запись, игнорировать недавнее изменение или раскрывать содержимое, к которому у пользователя больше нет доступа. Задача не только в том, чтобы находить текст, но и в том, чтобы результаты оставались согласованными с актуальными данными и правами доступа даже при задержках или сбоях.
Чтобы спроектировать надёжный поиск по тексту в PHP, сначала определите, что именно должен находить пользователь и какая задержка допустима. Затем выберите, где выполнять запросы и как поддерживать любой производный индекс. База данных должна оставаться источником истины; поисковый индекс — это восстанавливаемое представление, а не ещё одно место для редактирования данных.
Начните с требований к поиску
Опишите реальные запросы до выбора технологии. Ищут ли пользователи слова в заголовках и описаниях, фразы, префиксы или значения в нескольких полях? Нужны ли фильтры по статусу, категории, дате, языку или владельцу? Важны ли устойчивость к опечаткам, синонимы, релевантность или сортировка по дате?
Также определите операционные цели: допустимую задержку, частоту обновления, предполагаемый объём данных и поведение системы, когда поиск недоступен. «Актуальный» может означать, что изменение появляется немедленно или через несколько секунд. Эта разница влияет на архитектуру, и её нужно явно зафиксировать.
Проверяйте качество на типичных запросах. Используйте частые и редкие термины, записи с пустыми полями, текст с диакритическими знаками, разные языки и пользователей с различными правами доступа. Проверяйте не только наличие ожидаемого результата, но и уместность порядка результатов и фильтров.
Решите, достаточно ли SQL
SQL-запроса может быть достаточно, если набор данных и запросы остаются управляемыми, фильтры просты, а возможности полнотекстового поиска базы данных подходят для задачи. Важны СУБД и её конфигурация: функции полнотекстового поиска, нормализация и оценка релевантности различаются в разных системах. Проверяйте ограничения на реальных данных и запросах.
У SQL есть практическое преимущество: данные и поиск могут использовать одну модель согласованности. Кроме того, на начальном этапе не нужно эксплуатировать дополнительный сервис и синхронизировать отдельный индекс. Это не означает, что каждый запрос нужно выполнять по частичному совпадению в столбцах без продуманной стратегии; изучите план выполнения, доступные индексы и стоимость фильтров.
Рассмотрите специализированный индекс, если запросам нужны возможности, которые SQL не обеспечивает должным образом, если задержка или нагрузка от поиска мешают основным операциям либо если релевантность, фасеты и анализ текста должны развиваться независимо. Это архитектурное решение, а не обязательное требование только потому, что приложение относится к SaaS или содержит много записей.
Сохраните источник истины и определите индекс
Транзакционная база данных должна быть авторитетным источником данных для создания, изменения и удаления записей, а также для сведений о правах доступа. Документируйте, какие сущности и поля индексируются, как они преобразуются и какой идентификатор позволяет найти исходную запись. Индекс может содержать нормализованный текст и поля для фильтров, но не должен превращаться в редактируемую копию без чёткого процесса сверки.
Особого внимания требуют права доступа. Решите, будет ли индекс хранить поля для авторизации или приложение будет проверять каждый результат по источнику истины. При любом подходе поиск не должен предоставлять доступ только потому, что документ всё ещё присутствует в индексе. Применяйте фильтры доступа на сервере и учитывайте изменения владельца, видимости или роли как изменения, которые также нужно передавать в индекс.
Если из-за задержек в обновлении прав требуется обеспечить максимальную безопасность, повторно проверяйте авторизацию при получении результатов, даже если из-за этого часть результатов придётся отбросить. Стратегия должна также определять действия при сбое такой проверки: не следует в качестве запасного варианта возвращать непроверенные результаты.
Обеспечьте восстановимую передачу изменений
Обновление базы данных и последующая отправка сообщения в очередь как две независимые операции создают риск потери: первая операция может завершиться успешно, а вторая — дать сбой. Распространённый способ избежать этого — транзакционная очередь исходящих событий, или исходящие: одна транзакция сохраняет изменение бизнес-данных и ожидающее обработки событие в той же базе данных. Отдельный процесс публикует или обрабатывает эти события и отмечает прогресс.
Обработчик асинхронно обновляет индекс. Это создаёт период рассогласования, для которого нужно задать явную целевую величину и отслеживать её. Если после записи требуется немедленное чтение, предусмотрите подходящую стратегию, например возвращайте только что сохранённую запись в ответе или временно читайте данные из источника истины. Не обещайте немедленную согласованность, если процесс асинхронный.
Проектируйте обработку так, чтобы она была идемпотентной: повторное получение одного и того же события не должно создавать дубликаты документов или перезаписывать данные более старыми значениями. Используйте стабильный идентификатор записи и, когда это уместно, версию или последовательный номер изменения. Если события могут поступать не по порядку, не позволяйте старой версии перезаписать новую. Повторная обработка должна быть безопасной, а сообщения, которые не удалось обработать, должны оставаться видимыми для расследования, а не исчезать бесследно.
Считайте удаление и перестроение обычными сценариями
Удаление нужно явно передавать в индекс. Если система физически удаляет запись до того, как обработчик успевает её прочитать, событие должно содержать идентификатор, необходимый для удаления документа. При задержках или повторной обработке маркер удаления — tombstone — или версия удаления может предотвратить повторное создание результата из старого события.
При изменении схемы или повреждении индексов перестраивайте их из источника истины небольшими пакетами. Фиксируйте точку выполнения, контролируйте ошибки и ограничивайте нагрузку на базу данных. Пока новый индекс заполняется, продолжайте передавать происходящие в это время изменения; иначе индекс может устареть ещё до переключения на него.
Когда новый индекс будет полностью заполнен и проверен, переключите чтение контролируемым способом, например с помощью конфигурации или совместимого с выбранной технологией alias. На время проверки результата сохраните возможность вернуться к прежнему варианту. Постепенное переключение — это операционное решение; оно не равнозначно неконтролируемому раскрытию пользователям изменений продукта.
Измеряйте согласованность и подготовьте эксплуатацию
Отслеживайте задержку между подтверждением изменения и его появлением в поиске, а также ожидающие события, ошибки, повторные попытки и окончательные сбои. Очередь, которая выглядит активной, может скрывать застрявшее событие. Настройте оповещения с порогами, соответствующими целевому времени актуализации, и определите процедуру повторной обработки или восстановления документов.
Запланируйте сверку: сравнивайте выборку или, если это возможно, полные наборы записей, которые должны быть проиндексированы, с существующими документами. Так можно обнаружить потерянные сообщения, ошибочные преобразования и неприменённые удаления. При обнаружении расхождения должно быть предусмотрено документированное действие, например переиндексация записи или перестроение индекса.
Контрольный список перед запуском в production
- Проверены ли запросы и критерии релевантности на типичных примерах?
- Задокументированы ли источник истины, индексируемые поля и их преобразование?
- Попадают ли изменения и удаления в индекс даже после частичного сбоя?
- Устойчива ли обработка к повторным и пришедшим не по порядку сообщениям?
- Применяются ли права доступа при поиске и обновляются ли они при изменениях?
- Измеряется ли задержка и предусмотрена ли процедура сверки и перестроения?
- Есть ли план проверки нового индекса и возврата к прежнему варианту, если результаты ухудшатся?
Надёжность поиска по тексту в PHP в меньшей степени зависит от выбора модной технологии, чем от продуманной работы с согласованностью, правами доступа и восстановлением. Начните с самого простого решения, которое соответствует измеренным требованиям. Если SQL перестанет обеспечивать нужные запросы или производительность, используйте специализированный индекс с явно определённой, наблюдаемой и восстанавливаемой синхронизацией.
