#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.