Azure Cosmos DB
Azure Cosmos DB is a globally distributed database service designed to enable you to elastically and independently scale throughput and storage across any number of geographical regions with comprehensive SLAs. You can develop document, key/value, or graph databases with Cosmos DB using a series of popular APIs and programming models.
SQL API:
With the SQL API, Azure Cosmos DB provides rich and familiar SQL query capabilities with consistent low latencies over schema-less JSON data. In this article, we provide an overview of the Azure Cosmos DB’s SQL API, and how to best use the API.
Gremlin API:
Azure Cosmos DB provides the Gremlin API for graph modeling and traversal, along with turn-key global distribution, elastic scaling of storage and throughput, and low latency.
Cassandra API
Azure Cosmos DB supports the Cassandra API. This means that by using existing drivers, your application written for Cassandra can now communicate with Azure Cosmos DB instead of Apache Cassandra/Datastax Enterprise databases, and gain benefits like global distribution and elastic scale.
MongoDB API:
Azure Cosmos DB supports the MongoDB API. This means that by using existing drivers, your application written for MongoDB can now communicate with Cosmos DB instead of MongoDB databases, and gain benefits like global distribution & elastic scale.
Table API:
Azure Cosmos DB provides the Table API for key-value workloads. This provides a premium experience for Azure Table storage with secondary indexes, global distribution, low latency, and dedicated throughput.
-
Cosmos DB BulkExecutor for .NET Core
I would like Azure Cosmos DB BulkExecutor library for .NET Core compatible version.
Recent application often uses Microsoft.Azure.DocumentDB.Core package, so the need for the .NET Core version is high.
316 votesWork on this feature has started. Will update here when this becomes generally available.
Thank you for your suggestion and votes.
-
Support ORDER BY on the ST_DISTANCE spatial function
Ordering results by the ST_DISTANCE spatial function is currently not supported.
303 votesWork on this feature has started. Will update here when this becomes generally available.
Thank you for you suggestion and votes.
-
Make COUNT() aware of indexes
Queries with COUNT() or other aggregates are very expensive and all appear to be scan driven vs. index driven.
I have 50k documents in collection, each has "Type" property with string value. The indexing policy is default.
The following simple query consumes 615 RUs:
SELECT VALUE COUNT(1) FROM x WHERE x.Type ='Content'The result is 9738 records.
The query metrics are:
RetrievedDocumentCount: 9738
RetrievedDocumentSize: 69506571
OutputDocumentCount: 1
OutputDocumentSize: 53
IndexHitDocumentCount: 0
IndexHitRatio: 0So what we see is that database reads all "Contents" and than counts them. But it's enough to just count the index entries not to read all…
114 votesWe have started work on this feature. Will update here when this becomes generally available.
Thank you for your request and votes.
-
Add DateTimeOffset support
The DocumentDb engine should be able to recognize and properly order DateTimeOffset serialized fields.
93 votesThis feature is now on our roadmap. There is no ETA for when this feature will become available but we will update here when work on this feature has started.
Thank you for your suggestion.
-
Support multiple collections in stored procedures
Currently CosmosDB Stored procedures only allow access to a SINGLE collection (because they seem to be scoped to collections rather than to the database), via getContext() :
var collection = getContext().getCollection();
But any "useful" / "real-life" application using ComosDB will typically have to interact with more than one collection. For example, it is currently IMPOSSIBLE to insert documents into two distinct collections within a database using a single stored procedure -- a VERY SERIOUS drawback / limitation.
I would propose that stored procedures be scoped to the database level and then we would be allowed to do something like:
var…
75 votesThis is currently not on our roadmap but will revisit this in future planning cycles.
Thank you for your suggestion.
-
Deploy Stored Procedures from Source Control
It would be great if we could deploy sprocs from visualstudio.com as we can with Azure Functions or Azure Web Sites.
69 votesWe have reviewed this request and at this time this is not on our road map.
We will keep this as unplanned to keep it opened and will revisit this again in the future.
Thank you for your suggestion and votes.
-
Order By Null Handling
Currently if you do an order by on a nullable value, the documents are not returned at all. Please add functionality similiar to Application Insights where you can specify if the documents with the null value appear at the beginning or end of the sort.
63 votesWe are actively working on this. No ETA on a release date but will update here once it becomes available or this is released.
Thank you for your suggestion.
-
Add built-in cast function for SQL queries
Need built-in function for casting string datatypes to INT, NUMBER, DOUBLE, etc. in SQL queries as our data loader is converting the number to string during document creation. We have a requirement to filter on numeric values in our application.
63 votesThis is on our roadmap and work has started on implementing this feature. We do not have an ETA on when this will be released but it should be within the next 2-3 months. Will update with an ETA when this feature gets closer to completion.
Thank you for your suggestion.
-
The ability to reference JavaScript libraries (e.g. underscore) within server-side scripting
It'd be nice to be able to reference javascript libraries within server-side scripting. Something like an AMD or RequireJS loader.
For example:
var _ = require('lodash');50 votesThis is on our backlog and are reviewing this. Will revisit in an upcoming planning cycle.
Thank you for your suggestion.
-
stored procedures & functions in .NET (C#)
Would be great to have the option to implement stored procedures, functions and triggers in .NET (C#) as well.
46 votesThis is not on our roadmap and we have no plans for it long term.
Thank you for your suggestion.
-
Support Querying a Subset of Logical Partitions in a Partitioned Collection
With the 10GB limit for a logical partition, there is a possibility where a partition key cannot be broken down far enough to avoid the upper limit without implementing a partitioning scheme similar to:
Partition Keys:
{Tenant Id}{Document Type}{Partition 1}
{Tenant Id}{Document Type}{Partition 2}
{Tenant Id}{Document Type}{Partition 3}
.
.
.
{Tenant Id}{Document Type}{Partition N}Where N is a defined as the total # of partitions per tenant id / document type combination to have. This is just an example where a single collection contains data from multiple tenants and document types, but could apply to other scenarios as well.
…
34 votes -
Use Json.Net contract resolver when using Linq to generate SQL queries
Member names in SQL queries generated from Linq currently look at the member for either a JsonPropertyAttribute or DataMemberAttribute. If the ability to specify custom JsonSerializerSettings is implemented (see http://feedback.azure.com/forums/263030-documentdb/suggestions/6422364-allow-me-to-set-jsonserializersettings ), this will need to be implemented to actually remove the need to annotate every member of your data object classes.
34 votes -
Support case insensitive indexing
Order by returns lowercase characters before uppercase characters.
x
y
z
A
B
CI know you can work around this by storing an all lower or all upper case version of the string you want to query by on your object but over time and scale that does add to your RU usage
30 votesThis is unplanned currently but will keep open and revisit in upcoming cycles.
Thank you for your request and votes.
-
Improve scaling down experience: remove redundant physical partitions
During initial import we increased RU to 200K. Cosmos Db SQL API created 20 physical partitions with 10K throughput each.
During regular day we just need 30K Ru. That would mean each physical partition would have only 1,5K RU allocated and a lot of redundant partitions with possible expensive cross-partition calls (total data size is less than 30GB)Is there way to decrease amount of physical partitions to reasonable value?
In a nutshell it is not fair pricing, when you are limited to 1,5K RU and a lot of cross-partition calls you have to pay extra30 votes -
Filtered unique indexes
I need my unique indexes to work when a soft delete flag is set to zero so that only the active records will participate in the uniqueness constraint per partition. This also makes it easier to determine deleted records in the Change Feed.
23 votes -
DocumentDB driver/package for R
There is one for MySQL. Not sure how hard it would be to build one for DocumentDB.
17 votesThis is currently not on our roadmap. Will mark this as unplanned and leave open in case this changes.
Thank you for your suggestion.
-
monitor and kill queries
Add ability to monitor (ie. see SQL query) and kill long running user queries from within Data Explorer.
14 votesThis capability is not on our road map today but we do provide query metrics using our SDK’s. You can read more about what we provide here, https://docs.microsoft.com/azure/cosmos-db/sql-api-sql-query-metrics#query-execution-metrics.
Thank you for your suggestion.
-
Allow us to define global unique keys across all partitions
Unique keys are scoped to partitions, but this makes it challenging to store data that's supposed to be globally unique like email address or mobile number. I ended up creating a traditional SQL Server table for this, but I'd like to migrate it to Cosmos DB.
12 votesHi Greg.
Currently this is not on our short term roadmap but we will evaluate this for our upcoming dev cycle which starts this Summer.
Thanks for your suggestion.
-
Fix issue with linq criteria on child object
In a project i'm currently working on, we have come to realise that we should not use DocumentDb collections as if they are the equivalent of a table in f.ex SQL Server. As a result, we are now persisting all of the entities, belonging to a single tenant in a single collection.
We already have lots of linq queries in our codebase which assume that each document type (aggregate root) is persisted in a dedicated collection. In an attempt to make the transition painless, i set out to refactor our data access object, so that its api continues to reason…
10 votes -
(Java) remove final from FeedResponse in azure-documnetsDb so I can mock it nicely in unit tests
as a Dev writing a unit test against the documentClient.queryDocuments method,
I want to mock the call and its DTO's
So that I can unit test it effectively.
i.e.private void givenAResponse(List<Document> response) {
FeedResponse feedResponse = mock(FeedResponse.class);
QueryIterable queryIterable = mock(QueryIterable.class);
when(feedResponse.getQueryIterable()).thenReturn(queryIterable);
when(queryIterable.toList()).thenReturn(response);
when(documentClient.queryDocuments(eq(CONNECTION_LINK), any(String.class), any(FeedOptions.class)))
.thenReturn(feedResponse);
}all fail due to:
Cannot mock/spy class com.microsoft.azure.documentdb.FeedResponse
Mockito cannot mock/spy following:
- final classesI am using: https://mvnrepository.com/artifact/com.microsoft.azure/azure-documentdb/1.16.0
10 votes
- Don't see your idea?