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.
-
Allow multi Order By
From what I see it is impossible to run a query with more than one column in the Order By.
532 votesThis work is still currently in progress and actively working on it. Stay tuned for this feature in an upcoming release.
Thank you for your patience.
-
Support ORDER BY on the ST_DISTANCE spatial function
Ordering results by the ST_DISTANCE spatial function is currently not supported.
264 votesThis is currently not on our road map. However, we will review this item in the future as we prioritize future releases.
Thanks.
-
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.
248 votes -
Support LINQ ANY or WHERE for child object collections
Example trying to query Sales
var querySales = DocumentDb.Client.CreateDocumentQuery<Sale>(collectionLink)
.Where(q => q.Type == "Sale" && q.Stage <= 99 && q.InvolvedParties.Any(qq => qq.Id == userId))Buy ANY not supported
Also tried
.Where(q => q.Type == "Sale" && q.Stage <= 99 && q.InvolvedParties.Where(qq => qq.Id == advisorUserId).Count() > 0)get WHERE not supported
Really want the DB to perform the search as a lot of results will come back.
sample data:
{
"id": "af10eebf-b0b6-49d5-8db5-96f54c4985d2",
"Type": "Sale",
"GroupId": 1,
"InvolvedParties": [
{
"Id": "344595a3-4e73-4bd5-9988-849858f045f1",
"PartyType": 0,
"Name": "test user"
}
],130 votesWe have started work on this feature and plan to release it in an upcoming release. I cannot give an exact date but this should be released soon. Will update here once a date is known or once it is publicly available.
Thank you for your suggestion.
-
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…
61 votes -
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.
57 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.
53 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.
-
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…
50 votesThis is currently not on our roadmap but will revisit this in future planning cycles.
Thank you for your suggestion.
-
Permit executing a stored procedure from another stored procedure
function () {
var context = getContext();
var collection = context.getCollection();collection.executeStoredProcedure('foo', {}, function (error, result){});
}
49 votesYou can call a UDF from a stored procedure, however you can’t do crud operations within a UDF.
This is not on our roadmap. If you can provide more details around why/how you’d need to call a stored procedure from a stored procedure please comment/vote.
Thanks 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.
-
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');43 votesThis is on our backlog and are reviewing this. Will revisit in an upcoming planning cycle.
Thank you for your suggestion.
-
Add DateTimeOffset support
The DocumentDb engine should be able to recognize and properly order DateTimeOffset serialized fields.
42 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.
-
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.
41 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.
-
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.
28 votes -
26 votes
This work has started and should be released very soon. Polygon support will include up to 4k points. Will update here once this is publicly available.
Thank you for your suggestion.
-
DocumentDB driver/package for R
There is one for MySQL. Not sure how hard it would be to build one for DocumentDB.
18 votesThis is currently not on our roadmap. Will mark this as unplanned and leave open in case this changes.
Thank you for your suggestion.
-
Include documentdb in Stack.
Include support of documentdb in Azure Stack. So that an application already running on Azure live can also be used on Azure Stack.
16 votesThis is on our road map and planned for a future release. There is no ETA for this item but will update here as this progresses.
-
monitor and kill queries
Add ability to monitor (ie. see SQL query) and kill long running user queries from within Data Explorer.
13 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.
-
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.
…
12 votes -
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
- Don't see your idea?