Azure Cosmos DB добавляет составной индекс для массива строк

#c# #.net #azure #azure-cosmosdb #azure-cosmosdb-sqlapi

#c# #.net #azure #azure-cosmosdb #azure-cosmosdb-sqlapi

Вопрос:

Я пытаюсь добавить новый составной индекс для поиска по нескольким полям.

Я хотел бы знать, что следует учитывать при добавлении нового составного индекса и будет ли это работать для строки массива?

Пример документа Cosmos

 {
        "id": "ed78b9b5-764b-4ebc-a4f2-6b764679",
        "OrderReference": "X000011380",
        "SetReferences": [
            "000066474884"
        ],
        "TransactionReference": "ed78b9b5-764b-4ebc-6b7644f06679",
        "TransactionType": "Debit",
        "Amount": 73.65,
        "Currency": "USD",
        "BrandCode": "TestBrand",
        "PartitionKey": "Test-21052020-255",
        "SettlementDateTime": "2020-05-21T04:35:35.133Z",
        "ReasonCode": "TestReason",
        "IsProcessed": true,       
    }
  

Моя существующая политика индексирования

 {
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/PartitionKey/?"
        },
        {
            "path": "/BrandCode/?"
        }
    ],
    "excludedPaths": [
        {
            "path": "/*"
        },
        {
            "path": "/"_etag"/?"
        }
    ],
    "compositeIndexes": [
        [
            {
                "path": "/PartitionKey",
                "order": "ascending"
            },
            {
                "path": "/IsProcessed",
                "order": "ascending"
            }
        ]
    ]
}
  

Для извлечения данных из массива ссылок на строки, обрабатывается reasonCode.

 SELECT * FROM c WHERE ARRAY_CONTAINS(c.SettlementReferences, '00884') and c.IsProcessed = true and c.ReasonCode = 'TestReason'
  

Я планирую добавить следующую политику

 {
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/PartitionKey/?"
        },
        {
            "path": "/BrandCode/?"
        }
    ],
    "excludedPaths": [
        {
            "path": "/*"
        },
        {
            "path": "/"_etag"/?"
        }
    ],
    "compositeIndexes": [
        [
            {
                "path": "/PartitionKey",
                "order": "ascending"
            },
            {
                "path": "/IsProcessed",
                "order": "ascending"
            }
        ],
        [
            {
                "path": "/SettlementReferences",
                "order": "ascending"
            },
            {
                "path": "/IsProcessed",
                "order": "ascending"
            },
            {
                "path": "/ReasonCode",
                "order": "ascending"
            }
        ]
    ]
}
  

Пожалуйста, дайте мне знать, достаточно ли этого изменения?

Более того, я попытался сравнить RU до и после изменения. Я не вижу никакой существенной разницы, оба составляют около 133,56 Rus.

Есть ли что-нибудь еще, что мне нужно учитывать для оптимизации производительности?

Ответ №1:

Составные индексы не помогут с этим запросом и в целом не оказывают никакого влияния на утверждения о равенстве. Они полезны при выполнении порядка следования в ваших запросах. Вот почему вы не видите никакого сокращения RU / s в своем запросе. Однако вы заметите увеличение RU / s при записи.

Если вы хотите повысить производительность вашего запроса, вам следует добавить любые свойства в ваших предложениях where в « includedPaths » в вашей политике индексирования.

Еще одна вещь, на которую следует обратить внимание, заключается в том, что, как правило, рекомендуется по умолчанию индексировать все и выборочно добавлять свойства к исключенным путям. Таким образом, если ваша схема изменится, она будет проиндексирована автоматически без необходимости перестраивать ваш индекс.

Комментарии:

1. Отметьте нет, это мало что дало. Я добавил путь включения для ссылок на поселения, например { «path»: «/SettlementReferences /?» }, и я получил около 115 ссылок Ru. без добавления этого индекса я получал точно такие же Ru. в реальности я ожидаю, что индекс должен быть чем-то вроде «/ SettlementReferences /0 /?», «/ SettlementReferences / 1 /?», но не уверен, как определить в этом формате. Но при поиске через PartitionKey требуется всего 5 rus.

2. Отметьте, что это сработало, если я добавлю индекс типа «/SettlementReferences /[]/?». Сейчас Ru составляет около 5. Но я должен посмотреть, что подразумевается при записи.

3. Значение записи также не так много, так как требуется на 0,14 rus больше

Ответ №2:

Как упоминал Марк, нам нужно добавить путь включения для массива «/SettlementReferences /[]/?». После добавления мое количество Ru уменьшилось со 115 до 5 ru.