EnableScanInQuery больше не работает для новых контейнеров CosmosDB - PullRequest
Новая
       56

EnableScanInQuery больше не работает для новых контейнеров CosmosDB

1 голос
/ 07 октября 2019

Я путаюсь с политикой индексации cosmos-db и неявным полным сканированием.

Моя конечная цель:

  • предотвращение случайного полного сканирования неиндексированных свойств
  • индексировать только явно указанные свойства

Допустим, у меня есть таблица, подобная этой: 

{
  "id": "transactions",
  "indexingPolicy": {
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [
      {
        "path": "/transactionId/?"
      },
      {
        "path": "/createdOn/?"
      }
    ],
    "excludedPaths": [
      {
        "path": "/*"
      },
      {
        "path": "/\"_etag\"/?"
      }
    ]
  },
  "partitionKey": {
    "paths": [
      "/chargePointId"
    ],
    "kind": "Hash"
  }
}

Я предполагаю, что это означает, что у меня есть ровно 2 согласованных индекса (для транзакцииIid и столбцов createOn). Портал Azure не позволяет мне указывать типы индексов: он «принимает» изменение, но при перезагрузке страницы все изменения исчезают.

Теперь я выполняю запрос к несуществующему столбцу с отключенным полнымсканирование, предполагая, что оно завершится с ошибкой: An invalid query has been specified with filters against path(s) excluded from indexing. Consider adding allow scan header in the request..

Но этого не происходит. Он отлично работает и печатает 00:00:00 в консоли. 

var policy = new ConnectionPolicy()
{
    ConnectionMode = ConnectionMode.Gateway
};

var client = new DocumentClient(host, key, policy);

var queryText = "select * from c where c.asdasdasd > '2'";

var query = client.CreateDocumentQuery(
     UriFactory.CreateDocumentCollectionUri("transactions", "transactions"),
     queryText,
     new FeedOptions
     {
         PopulateQueryMetrics = true,
         EnableScanInQuery = false,
         EnableCrossPartitionQuery = true,
     }
).AsDocumentQuery();

var result = await query.ExecuteNextAsync();
var metrics = result.QueryMetrics;

Console.WriteLine(metrics.Single().Value.QueryEngineTimes.IndexLookupTime);

(код взят из этого руководства https://docs.microsoft.com/en-us/azure/cosmos-db/sql-api-query-metrics)

Таблица, о которой я говорю, создана недавно (~ несколько недель назад)У меня также есть таблица в другой учетной записи базы данных, созданной много лет назад. Если я попытаюсь сделать тот же трюк с этой таблицей - он не будет работать, как я ожидал.

Я не нашел никаких различий в учетной записи или таблицеarm-templates (экспортировано из портала Azure).

Почему не происходит сбой в новой таблице? Он все еще молча индексирует объекты или EnableScanInQuery больше не учитывается для новых таблиц?

1 Ответ

0 голосов
/ 09 октября 2019

Я из инженерной команды CosmosDB. Мы постепенно удаляем поддержку EnableScanInQuery, так как она не применялась одинаково для каждого возможного запроса (например, SELECT * из r). Кроме того, частичное сканирование все еще было разрешено, когда EnableScanInQuery имеет значение false (даже если один из наименее селективных предикатов в запросе удовлетворяет большому количеству документов и может обслуживаться из индекса, мы принимаем запрос, даже если он может эффективносканирование). Для новых контейнеров, начинающихся в начале этого года, поддержка постепенно снимается. Рекомендуемый способ оптимизировать запросы, чтобы избежать сканирования, состоит в том, чтобы изучить метрики выполнения запросов, чтобы определить, нужно ли проводить какие-либо оптимизации в отношении политики индекса.

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

...