Обратный поиск Best Practices?

Question

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

Мне трудно найти решение для этого типа проблемы.

Я использую Django и думаю о том, чтобы построить поиски и выбрать их, используя объекты Q, как показано здесь: http://www.djangozen.com/blog/the-power-of-q

На мой взгляд, когда в базу данных вводится новый объект, мне придется загружать каждый сохраненный запрос из БД и каким-то образом запускать его для этого нового объекта, чтобы посмотреть, будет ли он соответствовать этому поисковому запросу. .. Это не кажется идеальным - кто-нибудь сталкивался с такой проблемой раньше?

Answer 1

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

Более 20 лет назад мы обработали хранимых запросов , обрабатывая их как минидоки и индексируя их на основе всех , которые должны иметь , а может иметь условия. Список терминов нового документа использовался как своего рода запрос к этой «базе данных запросов», и в нем был составлен список возможно интересных поисков для запуска, а затем только эти поиски запускались для новых документов. Это может показаться запутанным, но когда имеется более чем несколько хранимых запросов (скажем, от 10000 до 1000000 или более), и у вас есть сложный язык запросов, который поддерживает гибрид булевого поиска и поиска на основе подобия, это существенно уменьшило количество запросов, которые мы должны были выполнять как полные запросы, часто не более 10 или 15 запросов.

Одна вещь, которая помогла, заключалась в том, что мы контролировали по горизонтали и по вертикали всего этого. Мы использовали наш синтаксический анализатор запросов для построения дерева разбора, и это использовалось для построения списка обязательных / возможных терминов, по которым мы индексировали запрос. Мы предостерегли клиента от использования определенных типов подстановочных знаков в хранимых запросах , поскольку это может привести к взрыву в количестве выбранных запросов.

Обновление для комментария:

Краткий ответ: я точно не знаю.

Более длинный ответ: Мы имели дело с пользовательским механизмом текстового поиска, и часть его синтаксиса запросов позволяла очень эффективно разрезать коллекцию документов определенным образом, с особым акцентом на date_added. Мы играли во многие игры, потому что мы принимали 4-10 000 000 новых документов в день и выполняли их для более чем 1 000 000+ хранимых запросов на DEC Alphas с 64 МБ основной памяти. (Это было в конце 80-х / начале 90-х годов.)

Я предполагаю, что фильтрацию по чему-то, эквивалентному date_added, можно было бы использовать в сочетании с датой последнего запуска ваших запросов или, возможно, самой высокой id в последний момент выполнения запроса. Если вам нужно повторно выполнить запросы к измененной записи, вы можете использовать ее id как часть запроса.

Чтобы получить более конкретную информацию, вам нужно получить лот , более конкретно о том, какую именно проблему вы пытаетесь решить, и масштаб решения, которое вы пытаетесь решить.

Answer 2

На уровне базы данных многие базы данных предлагают «триггеры».

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

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

Хороший способ взаимодействия триггеров и оповещений - через очереди сообщений - такие очереди, как RabbitMQ и другие реализации AMQP будут масштабироваться с вашим сайтом.

Answer 3

Если вы сохранили тип (ы) объектов, участвующих в каждом сохраненном поиске, как родовое отношение , вы можете добавить сигнал после сохранения ко всем задействованным объектам. , Когда сигнал срабатывает, он ищет только те запросы, которые связаны с его типом объекта, и запускает их. Это, вероятно, все еще будет сталкиваться с проблемами масштабирования, если у вас есть тонна записей в БД и много сохраненных поисков, но это будет простой подход Django.