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.
-
Support Cypher as a query language for Graph data
Add Cyhper (see http://www.opencypher.org/) as a language to query graph databases. Cypher is a human readable query languages to easily access a graph database.
401 votesThis is currently not on our road map. However, we will review this item in the future as we prioritize future releases.
-
Support Gremlin Bytecode to enable the fluent API of Gremlin.NET
Azure Cosmos DB Graph API doesn't support Gremlin Bytecode. Therefor it is not possible to use the fluent traversal API of Gremlin.NET.
Within the Azure Cosmos DB Graph .NET API (https://docs.microsoft.com/en-us/azure/cosmos-db/graph-sdk-dotnet) it is recommended to use Gremlin.NET. So it would be really nice if all features of Gremlin.NET would be supported.
See also the idea of a "better type-safe APIs fro Gremlin" (https://feedback.azure.com/forums/263030-azure-cosmos-db/suggestions/19340761-better-type-safe-apis-for-gremlin) within the Graph API feedback.
355 votesThis is currently on our road map. Stay tuned for this in an upcoming release.
Thanks.
-
Implement a graphql provider
graphql {http://graphql.org/} is becoming increasingly adopted by front end frameworks (including mobile) for querying backend / API data.
Rather than having to translate each graphql query into a DocumentDB client call it would be optimal and very powerful to issue the query directly.
It would also provide enhanced query abilities over the existing REST approach.
253 votesApologies for the confusion on our part.
This is currently not on our roadmap. However, we will review this item in the future as we prioritize future releases.
Thanks for your suggestion.
-
Better type-safe APIs for Gremlin
Hello guys,
With the recent announcement of CosmosDB which includes Gremlin APIs, is there any plan to have a more fluent/linq/lambda-friendly APIs on .Net SDK?
I'm looking at this sample https://github.com/Azure-Samples/azure-cosmos-db-graph-dotnet-getting-started/tree/master/GraphGetStarted from docs, and the Gremlin queries are fully string-based.
I could contribute that to a package like Microsoft.Azure.Graphs.Extensions or something like that.
I know that lambda/linq syntax don't map 100% to the the Gremlin one.
So the idea would be translate:
g.addV('person').property('id', 'thomas').property('firstName', 'Thomas').property('age', 44)"
to something like that:graph.Vertice<Person>().Property(p => p.Id == "thomas").Property(p => p.FirstName == "thomas").Property(p => p.Age == 44);
That would internally build the proper Gremlin…177 votesThis is a bytecode dependency. We’re hoping to address bytecode here shortly. Hopefully by end of 2018, but it’s at the back of our backlog, so we can’t promise on it. We will update here when this work gets started.
Thanks.
-
Support Gremlin APIs on Cosmos DB Emulator
The Cosmos DB Emulator currently does not support the Gremlin API. So at the moment it is not possible to test against the emulator using the Gremlin Console (http://tinkerpop.apache.org/docs/3.2.5/tutorials/the-gremlin-console/)
168 votesWe are currently working on this. Expect release before end of 2018.
Thank you.
-
Support for W3C SPARQL as a query language
SPARQL is a mature W3C standard for querying and updating graph-like data with well defined semantics and rich query capabilities.
93 votesWe don’t have any plans for SPARQL yet. We will keep this on our backlog and track user interest here as we prioritize upcoming work sprints.
Thanks.
-
Gremlin queries from stored procedures
It would be nice to have the ability to execute Gremlin queries against the Graph API from a stored procedure. Ideally, this would also enable transactions.
86 votesWe have not taken a look at this one yet but will review it this semester and update here.
Thank you for the input.
-
Unique indexes on Graph vertex/edge properties
I need to ensure global uniqueness for things like username/email/mobile number/etc. Since we no longer have traditional SQL, this capability is lacking. Allow me to define unique indexes so the write region has only one occurrence of a distinct value.
Ideally, this should also make FILTERED unique indexes possible.
55 votesThis is currently not on our road map. But we will revisit this again in our next review.
Thank you for your feedback.
-
Microsoft join and support GQL
I think it would be a great benefit for Cosmos DB to support the new movement to get to a single Graph Query Language. Microsoft joining this movement might help in rapid evolution and acceptance of such a language.
Taken from https://neo4j.com/blog/time-for-single-property-graph-query-language/:
The time has come to create a single, unified property graph query language.
Different languages for different products help no one. We’ve heard from the graph community that a common query language would be powerful: more developers with transferable expertise; portable queries; solutions that leverage multiple graph options; and less vendor lock-in.
One language, one skill set.
…
43 votesSupport for this is not on our roadmap but will mark as unplanned and leave open for future consideration.
Thank you for your suggestion.
-
Support for Graph API in Data Migration tool
Looking for a way to do backup/restore or manual export/import of a Cosmos DB graph using Graph API - or equivalent.
I want to be able to restore state of a database while developing and found that Data Migration tool can do what I want, but does not support Graph API.42 votesThis is currently not on our road map. But we will revisit this again in our next review.
Thank you for your feedback.
-
Add support for Text Search Predicates
Support Text Search Predicates like JanusGraph, eg:
http://kelvinlawrence.net/book/Gremlin-Graph-Guide.html#janpred
32 votesThis is in plan for us but we do not have an ETA on this yet. Will update here when this changes.
Thank you for your suggestion.
-
add spatial support to Graph API
Enable the same support for spatial queries that exists for DocumentDb for graph elements. Similar to Neo4j Spatial.
31 votesThis is not in the Tinkerpop specification. We have no plans to add support to this just yet.
We will revisit this in the future however.
Thank you for you feedback.
-
Enable GraphSON v2 support for Gremlin API
Enable using the GraphSON v2 serializer from the server side to parse Vertex/Edge objects automatically in the client-side.
19 votesWe are looking at this now and will update here in the near future.
Thank you for your suggestion.
-
Support for schemas (full, mixed and none)
Support schema-full and schema-mixed modes like OrientDB. This way one can _design_ a graph with vertex and edge classes. This is extremely useful when modelling known domains and removes all burden to do this in code.
17 votesCosmos DB is intended to be a schemaless database so we don’t support schemas in general. Support for this is not on our roadmap but will mark as unplanned and leave open for future consideration.
Thanks for your suggestion.
-
Allow me to create global read replicas with different partition keys
There is really no way to come up with a single partition key for my graph database to satisfy all queries. Some queries would benefit from a different partition key, so why not let people create copies of their whole graphs with different partition keys and give them a way to intelligently route queries to the correct server?
one write region with partition key A
multiple read regions with partition key A
multiple read regions with partition key B
multiple read regions with partition key C
...In other words, there would still be a single write region but multiple…
13 votesThis is something you can do this yourself with change feed to replicate a specific range or partition key to a different account.
To learn more about ChangeFeed, start here, https://docs.microsoft.com/en-us/azure/cosmos-db/change-feed
Thanks for your suggestion.
-
Support strategies on graph traversals
Currently, the graph traversal in Cosmos DB graph (usually referenced by 'g') does not support the 'withStrategies'-method that is normally part of a Tinkerpop implementation. 'withStrategies' allows e.g to enhance the traversal with custom vertex- and edge-filtering on every step (by a SubgraphStrategy).
12 votesWe would like to investigate this. Can you provide more context/details and usage scenarios around this?
Thank you.
-
transaction support for Gremlin API
Switch from Janus Graph to COSMOSDB relief me from maintaining a deployment, which is really great. However, Janus natively supports transaction and many existing business logic heavily relies on that: query to uncommitted vertex/edge, rollback entire transaction once any faulty state.
Also, if each query will go to COSMOSDB server, the latency from an entire business flow is really unacceptable. So I'm thinking if CosmosDB could provide a more sophistic client to handle transaction and cache?
(we're trying to achieve this by ourselves, but for complex query we found it really complicated. But I think CosmosDB already have much knowledge…12 votes -
Gremlin Graph: Add support for array values in group() and groupCount()
You should be able to group by an array of values. it is perfectly valid to do a group() or groupCount() like so:
g.V().groupCount().by(values('id','name').fold())
Other Graphs implementing Gremlin will give you a result, while CosmosDB fails with:
"Unexpected Error: Cannot resolve object to a primitive value."
10 votes -
CosmosDB Graph API should support array types inside Gremlin properties
Currently, the CosmosDB Graph API does not support array types inside of Gremlin properties. This forces users to rebuild their graph models to match what the Graph API requires. The CosmosDB Graph API should support array types inside of Gremlin properties.
10 votesWe support this on vertex property, but if you are looking key property support can you provide more details/specific examples of what you are looking for?
Thank you for your suggestion.
-
Gremlin console in Azure portal
Currently the option to do search queries in azure portal with gremlin is very slow. To avoid the setup of a local Gremlin console, it would be an improvement to have a gremlin console integrated into the portal. No need to specify connection string and keys, just ready to use and fast.
Would same time to each developer and be a frictionless no setup, just ready to use.
10 votesAzure portal already supports a way to visualize and query graph. What specifically are you looking for here?
Thank you. We appreciate any additional feedback you can provide.
- Don't see your idea?