Запрос DocumentDB с полями поиска Azure

Я хотел бы выполнить запрос DocumentDB, который выглядит как SELECT * FROM c, где c.teams IN (@teamsList) AND CONTAINS (c.text, "некоторая строка")

Проблема в том, что приведенный выше запрос требует больших вычислительных ресурсов и почти превышает наш предел сбора S3 (этот запрос занял 2400RU, и наш набор данных быстро растет, мы скоро достигнем предела сканирования для содержащихся).

Я знаю, что поиск Azure - более эффективный способ поиска по индексируемым полям. Мой вопрос заключается в том, как эффективно объединить результаты поиска Azure с другими полями запроса, в моем примере, ограничив их списком команд. Мы заинтересованы в создании «построителя запросов» (аналогичный пример доступен здесь), где СОДЕРЖИТСЯ является допустимым операндом в любом поле.


azure azure-cosmosdb azure-cognitive-search
person Valchris    schedule 10.03.2016    source источник
comment
Если для данного запроса истекает время ожидания из-за превышения бюджета RU, он вернется с токеном продолжения, который вы можете использовать, чтобы вернуться назад для получения дополнительных данных. Это помогает? Хотя поиск Azure был бы более эффективным для вашего предложения CONTAINS, я не уверен, будет ли он лучше / хуже для предложения IN. Возможно, вы захотите протестировать оба варианта для своего набора данных.   -  person Larry Maccherone    schedule 10.03.2016
comment
Что касается первого запроса DocumentDB, знаете ли вы, сколько документов соответствует фильтру запроса в запросе? Предложение IN будет отфильтровано через индекс. Если бы вы могли опубликовать идентификатор активности, мы можем выяснить, почему для этого требуется 2400 RU. Кроме того, если вам нужно вернуть только страницу результатов для вашего построителя запросов, вы можете значительно уменьшить количество RU, ограничив количество результатов, отображаемых по умолчанию.   -  person Aravind Krishna R.    schedule 10.03.2016
comment
Запрос SELECT TOP 100 * FROM c, где CONTAINS (c.details.title, test) возвращает 13 результатов и потребляет 2409,98 RU на портале Azure. Идентификатор активности: 6d966ad4-a196-4255-a10b-334a753a89e0   -  person Valchris    schedule 10.03.2016
comment
@LarryMaccherone, который может работать, но качество обслуживания клиентов сильно ухудшится, так как время отклика будет очень большим, правильно?   -  person Valchris    schedule 10.03.2016
comment
Что-то еще происходит. Только 13 результатов для 2400+ RU - это безумие. Пусть Аравинд выяснит, почему. Только тогда вы должны обдумать то, что я предлагаю. Если вам нужен только TOP n, то использовать TOP n можно, но если они вам действительно нужны, но вы просто хотите отобразить первую страницу, установите maxItemCount равным размеру вашей страницы плюс некоторый буфер. Затем кешируйте всю коллекцию на стороне клиента, отображая только страницу за раз.   -  person Larry Maccherone    schedule 10.03.2016

Ответы (1)


arrow_upward
0
arrow_downward

Если вы хотите использовать DocumentDB для поиска слов CONTAINS и избегать сканирования (и не использовать поиск Azure), вы можете сделать следующее:

  1. Вы превращаете text в массив слов. Вы можете использовать стандартный токенизатор, такой как Lucene.NET. Скажем, текст: «Это вопрос».
  2. Сохраните слова в виде массива, например text_tokens. Содержимое text_words: ["this", "is", "question"] (канонизировано в нижний регистр и удалены стоп-слова)
  3. Запросите значения в text_tokens, используя ARRAY_CONTAINS (c.text_tokens, «слово»). Это будет использовать index.
person Aravind Krishna R.    schedule 11.04.2017