Поиск по нескольким объектам - дизайн базы данных / стратегия кода?

Question

Я заблудился о том, как лучше всего подойти к компоненту поиска по сайту.У меня есть пользовательский контент, похожий на yelp.Люди могут искать локальные места, локальные события, локальные фотографии, участников и т. Д. Поэтому, если я введу «Том» в поле поиска, я ожидаю, что поиск выдаст результаты всех пользовательских объектов, которые соответствуют Тому.Теперь слово «Том» может быть где угодно, например, в названии ресторана или в описании ресторана, или в обзоре, или в чьем-то комментарии, и т. Д.объедините около 15 таблиц объектов, чтобы просмотреть все различные пользовательские объекты + отсканировать несколько столбцов в каждой таблице, чтобы найти все поля / столбцы.Теперь я не знаю, так ли это нормально, или есть лучший способ?Я видел такие вещи, как Solr / Apache / Elasticsearch, но я не уверен, как они вписываются в мой случай, и даже если я использую их, я предполагаю, что мне все еще нужно сканировать все 15 таблиц + 30-40 столбцов правильно?Моя платформа php / mysql.Кроме того, какие-либо практики кодирования / архитектуры компонентов / проектирования БД для этого?Друг сказал, что я должен объединить все объекты в 1 таблицу, но это не сработает, поскольку вы не можете объединить фотографии, видео, комментарии, страницы, профили и т. Д. В 1 таблицу, поэтому я теряюсь, как это реализовать.

Answer 1

Вероятно, ваш друг имел в виду объединение всех доступных для поиска полей в одну таблицу.

Основная идея состоит в том, чтобы создать таблицу, которая действует как индекс.Один столбец индексируется и хранит слова, тогда как другой столбец содержит список ссылок на объекты, которые содержат это слово в одном из этих полей (например, объект может быть изображением, а его полями для поиска могут быть заголовок и комментарии).

Список ссылок может храниться разными способами, так что вы можете, например, иметь строку переменной длины, скажем, BLOB, и в ней хранить JSON-кодированный массив идентификаторов и типов объектов, поэтомучтобы потом их можно было легко найти, выполнив поиск этого идентификатора в таблице, соответствующей типу объекта).

Конечно, при любом добавлении / удалении / изменении индексируемых данных вы должны обновить свой индекссоответственно (но вы можете использовать ленивые методы обновления, которые в конечном итоге обновляют индекс в фоновом режиме - это потому, что большинство людей ожидают, что индексы будут точными в течение, возможно, нескольких минут до текущего состояния данных. Одна реализациятакой индекс Apache Cassandra , ноЯ бы не стал использовать его для небольших проектов, где вам не нужны распределенные базы данных и тому подобное).