If you have spent any time looking at the documentation for Microsoft CosmosDB / DocumentDB, you will see a lot of examples where the data model has a property named "Tags" that is a list of strings. But you don't see many times they query on something in that Tag property... One example I saw a query on Tags[0] = "some value" I don't know how often I will need that, but you know, good to know you can do it.
After looking through the SQL syntax reference. The 2 ways I most likely query the Tags would be to use a join on the Tags property or use the ARRAY_CONTAINS function.
Side note; the performance of the two methods are basically identical, leading me to believe the query optimizer generates the same instruction sets for both. So unless you have an array of complex objects, just use ARRAY_CONTAINS.
Cool, we know how to query for documents that have our tag on them now... One small problem, when you load a million, or even a hundred thousand documents, your queries start taking seconds to complete, and 10's of thousands of request units. That's not going to work.
It seams the default indexing policy doesn't index the values in an array, and then that means that CosmosDB is having to open every document that matches your base query. Thankfully there is a way around this. If you add a path of "/tags/[]/?" you will find the same query returns in a fraction of a second, and less then 100 RUs.
Sample Index Policy:
After looking through the SQL syntax reference. The 2 ways I most likely query the Tags would be to use a join on the Tags property or use the ARRAY_CONTAINS function.
Side note; the performance of the two methods are basically identical, leading me to believe the query optimizer generates the same instruction sets for both. So unless you have an array of complex objects, just use ARRAY_CONTAINS.
Cool, we know how to query for documents that have our tag on them now... One small problem, when you load a million, or even a hundred thousand documents, your queries start taking seconds to complete, and 10's of thousands of request units. That's not going to work.
It seams the default indexing policy doesn't index the values in an array, and then that means that CosmosDB is having to open every document that matches your base query. Thankfully there is a way around this. If you add a path of "/tags/[]/?" you will find the same query returns in a fraction of a second, and less then 100 RUs.
Sample Index Policy:
{
"indexingMode": "lazy",
"automatic": true,
"includedPaths": [
{
"path": "/*",
"indexes": [
{
"kind": "Hash",
"dataType": "String",
"precision": -1
},
{
"kind": "Range",
"dataType": "Number",
"precision": -1
}
]
},
{
"path": "/tags/[]/?",
"indexes": [
{
"kind": "Hash",
"dataType": "String",
"precision": -1
},
{
"kind": "Range",
"dataType": "Number",
"precision": -1
}
]
}
],
"excludedPaths": []
}