I'm using Cosmos DB with the Mongo adapter, accessing via the Ruby mongo driver. Currently there are about 2.5M records in the db.
When querying the total amount of records, there's no problem whatsoever:
2.2.5 :011 > mongo_collection.count
D, [2017-11-24T11:52:39.796716 #9792] DEBUG -- : MONGODB | XXX.documents.azure.com:10255 | admin.count | STARTED | {"count"=>"xp_events", "query"=>{}}
D, [2017-11-24T11:52:39.954645 #9792] DEBUG -- : MONGODB | XXX.documents.azure.com:10255 | admin.count | SUCCEEDED | 0.15778699999999998s
=> 2565825
But when I try to count the amount of records found based on a simple where, I run into the Request rate is large
error:
2.2.5 :014 > mongo_collection.find(some_field: 'some_value').count
D, [2017-11-24T11:56:11.926812 #9792] DEBUG -- : MONGODB | XXX.documents.azure.com:10255 | admin.count | STARTED | {"count"=>"some_table", "query"=>{"some_field"=>"some_value"}}
D, [2017-11-24T11:56:24.629659 #9792] DEBUG -- : MONGODB | XXX.documents.azure.com:10255 | admin.count | FAILED | Message: {"Errors":["Request rate is large"]}
ActivityId: 0000-0000-0000-000000000000, Request URI: /apps/XXX/services/XXX/partitions/XXX/replicas/XXX/, RequestStats: , SDK: Microsoft.Azure.Documents.Common/1.17.101.1 (16500), Message: {"Errors":["Request rate is large"]}
I understand how the error works, but I don't understand how such a query can max out the RU/s (set at max value 10,000), since the field I'm querying is supposed to be indexed (automatically).
Any advice would be greatly appreciated!
Azure Cosmos DB API for MongoDB operations may fail with rate-limiting (16500/429) errors if they exceed a collection's throughput limit (RUs). You can enable the Server Side Retry (SSR) feature and let the server retry these operations automatically.
Azure Cosmos DB is a fast, flexible distributed database that scales seamlessly with guaranteed latency and throughput levels. You don't have to make major architecture changes or write complex code to scale your database with Azure Cosmos DB. Scaling up and down is as easy as making a single API call.
Which consistency level consumes the least amount of request units per operation? The cost of a read operation with eventual consistency consumes the least number of request units per seconds.
The error is by design, it means that an application is sending request to DocumentDB service at a rate that is higher than the 'reserved throughput' level for a collection tier.
The solution is that retry same request after some time. For more solutions check this article.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With