подхода для эффективного поиска в результате набор

Question

короткой версию

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

Моя идея

Я планирую сделать эту операцию на 2 части. Сначала поисковая система будет запрашиваться для взвешенного/отсортированного набора идентификаторов, соответствующих полнотекстовому поиску. Этот набор идентификаторов будет отфильтровываться, удаляя любые идентификаторы, не входящие в исходный набор пользователя.

Есть ли лучший способ сделать это? Если нет, можете ли вы дать какие-либо рекомендации по эффективному выполнению этого?

Long Version

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

Я хотел бы разрешить пользователям выполнять полнотекстовый поиск результатов в этих наборах данных. Глядя на what Google does for searching within a result set, их подход простого добавления раннего поискового запроса к новому запросу для включения «поиска внутри» может оказаться невозможным для моих данных.

Принятый ответ this question способствует идее использования операций базы данных для фильтрации результатов, поступающих из поисковой системы.

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

Environment Подробности

Я бегу Python 2.7 на AppEngine.

В этом приложении, я ожидаю, что исходные наборы результатов (которые будут найдены внутри) будут содержать от 10 до 2000 вершин. Общее количество вершин во всей базе данных может быть на пару порядков больше.

Answer 1

Если вы попытаетесь использовать хранилище данных GAE для аналитики, you are going to have a bad time.

Запросы Datastore очень ограничены, не имеют фильтрации неравенств по нескольким свойствам или имеют полный текстовый поиск.

Возможно, вы захотите посмотреть в Google BigQuery, который имеет rich queries и поддерживает фильтрацию регулярных выражений. Он также поддерживает «промежуточные таблицы», где вы можете использовать результат одного запроса в качестве входных данных для другого - я не полностью понимаю вашу проблему, но, похоже, это то, что вам нужно.

Answer 2

TLDNR: Можете ли вы выполнить предварительную обработку для создания большого хеш-словаря, который клиент может использовать для поддержки различных запросов?

Насколько динамичны и велики ваши данные? Я работаю над тем, что может быть похоже, если ваши данные относительно статичны. У нас есть веб-страница, которая позволяет пользователям создавать выбор И и ИЛИ, выбирая любую комбинацию из 300 переменных. Каждая переменная может иметь много сотен элементов, связанных с ней. Поскольку наборы данных для переменных относительно статичны и не являются ginormous, мы создали их как json.dumped text в поле TextProperty. Когда анализируется браузером, json просто становится большим словарем с ключом идентификаторов переменных. Каждое значение ключа представляет собой массив элементов (идентификаторы изображений в нашем случае), связанные с выбранным ключом. Все пересечения и комбинации выполняются с помощью нескольких небольших функций Javascript, которые подаются с этими массивами. Это очень сработало - пользователи дополняют скорость, и этот подход значительно упрощает сторону GAE. Все json-переменные загружаются/обновляются в несколько ленивом режиме почти в режиме реального времени через кроссы и задачи. Для окончательного отображения результаты форматируются и вставляются в внутренний HTTML div. После того, как все изображения будут кэшированы, ответ браузера на форматирование и отображение сотен изображений размером 420x280 пикселей почти мгновенен. Очень здорово видеть, и дань уважения людям, работающим в браузерах, - как макет, так и оптимизация JS. (Я должен отметить, что мы используем чистую JS, чтобы обеспечить минимальные накладные расходы против чего-то вроде JQuery.) HTH -stevep