Упреждающий поиск по полям документа в Azure DocumentDb

Мы заинтересованы в использовании DocumentDb в качестве хранилища данных для ряда источников данных, и поэтому мы запускаем быстрый POC, чтобы установить, соответствует ли он искомым критериям.

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

Поиск в Интернете Я видел, как люди говорили об интеграции поиска Azure, но это оказалось очень дорогостоящим механизмом для такого простого варианта использования.

Я также видел, как люди упоминали об использовании UDF, но это, по-видимому, требует сканирования всей коллекции, что нецелесообразно с точки зрения производительности.

У кого-нибудь есть альтернативные предложения? Одна вещь, которую я рассматривал, заключалась в том, чтобы просто использовать таблицу SQL и инициировать обновление каждый раз, когда документ был вставлен\обновлен\удален?


azure azure-cosmosdb
person Iain Macnab    schedule 23.02.2017    source источник
comment
Это действительно широко и требует мнения. Я не думаю, что это действительно подходит для StackOverflow — вы уже упомянули полнотекстовый поиск, у которого есть множество вариантов (включая поиск Azure, как вы упомянули). Этот вопрос больше касается ценообразования, поскольку здесь нет проблем с программированием.   -  person David Makogon    schedule 23.02.2017
comment
Вопрос основан на программировании. Я ищу, какие решения приняли пользователи для решения SQL-подобной возможности поиска, которая в настоящее время отсутствует в DocumentDb. Я хочу использовать DocumentDb для масштабируемости и гарантированной производительности в масштабе, но не вижу, как это сделать без этой функции. Я отмечаю, что я не одинок в этом, так как несколько сотен голосов за эту функцию на feedback.azure.com/forums/263030-documentdb/suggestions/   -  person Iain Macnab    schedule 23.02.2017

Ответы (2)


arrow_upward
1
arrow_downward

DocumentDB поддерживает индексы STARTSWITH и диапазонов для поддержки префиксного/упреждающего поиска.

Вы можете постепенно делать запросы, подобные следующим, в зависимости от того, что ваш пользователь вводит в текстовое поле:

SELECT TOP 10 * FROM hotel H WHERE STARTSWITH(H.name, "H")
SELECT TOP 10 * FROM hotel H WHERE STARTSWITH(H.name, "Hi") 
SELECT TOP 10 * FROM hotel H WHERE STARTSWITH(H.name, "Hil")
SELECT TOP 10 * FROM hotel H WHERE STARTSWITH(H.name, "Hilton")

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

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

person Aravind Krishna R.    schedule 24.02.2017
comment
Большое спасибо Аравинд. Это отлично подходит для простого поиска, но не там, где требуется сложное сопоставление деталей. - person Iain Macnab; 06.03.2017
comment
Ян, не могли бы вы привести несколько разных случаев сложного сопоставления деталей? Я был бы рад расширить свой ответ, если это возможно, чтобы охватить и их. - person Aravind Krishna R.; 06.03.2017

arrow_upward
1
arrow_downward

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

Мой сценарий заключался в том, что потенциально тысячи одновременных пользователей выполняли бы такой поиск; при тестировании этого под нагрузкой, чтобы избежать насыщения и регулирования, мы обнаружили, что нам придется увеличить объем пропускной способности DocumentDB Request Unit (RU) до точки, которая была финансово нецелесообразна для нас в наших конкретных обстоятельствах .

Мы решили, что DocumentDB лучше всего использовать в качестве постоянного хранилища и «полного» извлечения данных — и с этой ролью он справляется исключительно хорошо — в то время как небольшой кластер ElasticSearch выполняет роль, для которой он был разработан — text search, faceted search , weighted search, stemming и наиболее важные для вашего вопроса autocomplete analyzersи completion suggesters.

Тему запросов с опережением ввода, создания индексов, анализатора автозаполнения и времени запроса «поиск по мере ввода» в ElasticSearch можно найти здесь, здесь и здесь

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

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

Стоимость была ниже, чем у Azure Search (в которой используется ElasticSearch).

person dmcquiggin    schedule 19.04.2017