Обратные поисковые лучшие практики?
Я делаю приложение, которое имеет потребность в обратных поисках. Этим я подразумеваю, что пользователи приложения введут поисковые параметры и сохранят их; затем, когда любые новые объекты вводятся на систему, если они будут соответствовать существующим поисковым параметрам, которые сохранил пользователь, то уведомление будет отправлено и т.д.
Мне нелегко находить решения для этого типа проблемы.
Я использую Django и думаю о создании поисков и солении их использующий Q объекты, как обрисовано в общих чертах здесь: http://www.djangozen.com/blog/the-power-of-q
Путем я вижу его, когда новый объект вводится в базу данных, я должен буду загрузить каждый сохраненный запрос из дб и так или иначе выполнить его против этого нового объекта видеть, соответствовало ли это тому поисковому запросу... Это не кажется идеальным - кто-либо занялся такой проблемой прежде?
3 ответа
На уровне базы данных многие базы данных предлагают "триггеры".
Другой подход заключается в том, чтобы иметь задания по времени, которые периодически извлекают из базы данных все элементы, имеющие дату последнего изменения с момента последнего запуска; затем они фильтруются и выдаются предупреждения. Возможно, вы можете поместить часть фильтрации в оператор запроса в базе данных. Однако это немного сложнее, если необходимо отправлять уведомления о том, что элементы удалены.
Можно также поместить триггеры вручную в код, который отправляет данные в базу данных, что, возможно, более гибко и, конечно, не зависит от специфических особенностей базы данных.
Хорошим способом взаимодействия триггеров и оповещений являются очереди сообщений - очереди, такие как RabbitMQ и другие AMQP реализации, будут масштабироваться вместе с вашим сайтом.
Если бы вы хранили тип(ы) объектов, участвующих в каждом сохраненном поиске, как общее отношение, вы могли бы добавить пост-сохранение сигнала ко всем участвующим объектам. Когда сигнал срабатывает, он просматривает только те поиски, в которых участвует его тип объекта, и запускает их. Вероятно, это все равно столкнется с проблемами масштабирования, если у вас тонна записей в базу данных и много сохраненных поисков, но это был бы простой подход Django.
Объем усилий, которые вы прикладываете для решения этой проблемы, напрямую зависит от количества сохраненных запросов , с которыми вы имеете дело.
Более 20 лет назад мы обрабатывали сохраненных запросов , рассматривая их как минидокументы и индексируя их на основе всех условий , которые должны иметь и могут иметь термины. Список терминов нового документа использовался как своего рода запрос к этой «базе данных запросов», и в результате был построен список , возможно, интересных поисков для запуска, и затем только эти поиски выполнялись для новых документов. Это может показаться запутанным, но когда имеется более нескольких сохраненных запросов (скажем, от 10 000 до 1 000 000 или более), и у вас есть сложный язык запросов, поддерживающий гибрид логического поиска и поиска на основе сходства, это существенно уменьшило количество, которое нам приходилось выполнять в качестве полноценных запросов - часто не более 10 или 15 запросов.
Помогло только то, что мы контролировали горизонталь и вертикаль всего. Мы использовали наш синтаксический анализатор запросов для построения дерева синтаксического анализа, которое использовалось для построения списка обязательных / возможных терминов, по которым мы проиндексировали запрос. Мы предупредили клиента от использования определенных типов подстановочных знаков в сохраненных запросах , поскольку это может привести к резкому увеличению количества выбранных запросов.
Обновление для комментариев:
Краткий ответ: точно не знаю.
Более длинный ответ: мы имели дело со специально созданной системой текстового поиска, и часть ее синтаксиса запросов позволяла очень эффективно нарезать коллекцию документов определенными способами, с особым акцентом на date_added . Мы играли во множество игр, потому что мы загружали 4–10 000 000 новых документов в день и запускали их с более чем 1 000 000 сохраненных запросов на DEC Alpha с 64 МБ основной памяти. (Это было в конце 80-х - начале 90-х.)
Я предполагаю, что фильтрация по чему-то, эквивалентному date_added , может быть использована в сочетании с датой последнего выполнения ваших запросов или возможно, самый высокий идентификатор во время последнего выполнения запроса. Если вам нужно повторно запустить запросы к измененной записи, вы можете использовать ее id как часть запроса.
Для меня, чтобы получить более конкретную информацию, вам нужно получить лот , более конкретный о том, какую именно проблему вы пытаетесь решить, и масштаб решения, которое вы пытаетесь решить.