I'm interested in using the Azure CosmosDB for it's Graph capability.
Looking through the docs i saw that it sores graph vertices and edges as JSON documents (with an agreed schema) and so it can be accessed as a plain old DocumentDB.
Taking this into consideration what is the meaning of the API selection you need to make when creating a new instance (link)?
eg :
what am i losing if i create the DB as SQL (DocumentDB) and
manipulating data via the graph part of the client (eg CreateGremlinQuery)
what am i losing if i create the DB as Graph and
manipulating data via the DocumentDB part of the client (eg CreateDocumentAsync)
UPDATE : I am aware of the portal difference (as described below by Jesse Carter). I am interested if this switch drives anything else under the hood in the specific scenario of choosing between SQL(Document DB) vs Graph
There is no functional difference from the perspective of interacting with your Cosmos Collection through either SQL or Graph APIs regardless of which API you choose at creation time.
HOWEVER, there is a difference from the perspective of the Azure portal when navigating your resources. Collections created specifically using the Graph API will get tagged as such and enable additional UI features in the portal for executing Gremlin queries and basic graph visualization.
If you don't care about those querying abilities in the Azure portal, then you're fine to create the collection with either option.
API selection is to avoid confusion for users who are only familier with gremlin and don’t want to learn documentDB.
If you are an advanced user, using both graph and documentDB will give you more power.
Note that we are committed to making the gremlin and documentDB SQL integration even more seamless.
Please drop us a note askcosmosdbgraphapi#microsoft.com, if you want to lean more or set up a time to talk to us.
Jayanta
Related
I have been thinking about what are the pros and cons of SQL Graph Database and Cosmos Graph Database, as far as I understand, SQL graph database is using nodes and vertex, but it still stores all of the information in tables.
So my question would be if the graph data can be handled by graph Db, what are the advantages of using SQL graph database? What is the added value of it compared with the original graph Database ?
SQL Graph Database and Cosmos Graph Database both are almost same kind of services, just the structure of handling the data is different. As such there are no advantages and disadvantages, but choosing the right service based on your use-case is the key factor.
Azure Cosmos DB's Gremlin API combines the power of graph database
algorithms with highly scalable, managed infrastructure to provide a
unique, flexible solution to most common data problems associated with
lack of flexibility and relational approaches.
So, by using Azure Cosmos DB Gremlin API, you will get more leverage on the datasets with additional features. On the top of that, all the prerequisites will be taken care by CosmosDB while creating the database using Gremlin API.
In SQL Graph DB, nodes and edges are in tabular form, whereas in Cosmos DB it is in JSON like format.
I would highly encourage you to analyze how these databases support graph database models and the mechanism to exploit the maximum potential of these database systems for the right use-cases.
Please refer below articles to get the better understanding of both the services.
SQL Graph Architecture
Introduction to Gremlin API in Azure Cosmos DB
I am evaluating databases for my new project where existing data is stored in cosmos SQL database.
For our use case graphDB seem to be a good solution. My Options are Gremlin API or TigerGraph.
I heard Gremlin API is built on top of document database so queries will be slower as Graph queries first gets converted to nosql queries, is that true statement? Any pointers here?
The Gremlin query language is part of Apache TinkerPop. TinkerPop does not dictate how a back end store and query engine be built. It ships with a reference in-memory graph written in Java that actually uses a simple HashMap to store data. TinkerPop has been ported to many different back end stores and storage models. It is not very common however for that to be a document store and there is no need to convert Gremlin queries to SQL unless perhaps you port TinkerPop on top of a Relational or other store and implement it that way. Most Graph DBs I have worked with that implement support for Apache TinkerPop use custom built graph engines and have their own query optimizers that are nothing to do with SQL. I should add that I am not familiar with how the CosmosDB Gremlin support is implemented. The main point is that TinkerPop does not dictate the type of store that be used or how the Gremlin support is implemented.
In one of our apps we need to introduce a feature of users being able to choose friends, see friends activity, etc.
So far we use CosmosDb container with SQL API (for things app does beside this social network aspect).
I am wondering is there a reason not to model it with SQL API but to go strictly with Gremlin?
I’ve seen examples on Microsoft site about modeling basic social network done with ordinary SQL API but i am not sure if i am missing something that would bite me down the road in a case not going with Gremlin?
You should be safe in choosing either. From docs:
Each API operates independently, except the Gremlin and SQL API, which
are interoperable.
The stored data is JSON in both cases.
More on choosing an API.
My team uses CosmosDb to store data.
For our use case some of this data needs to be searchable.
Currently there are some filters in the Gremlin that has been implemented in CosmosDb so far, but not enough to suit our needs, which are mainly search in text.
This would be implemented to make a fuzzy search for a vertex, say, a person, where both name, email and company name would be included in the text.
In https://github.com/Azure/azure-documentdb-dotnet/issues/413 there was some talk of some string filters, but there has been no updates for a while.
My question is would it be better to use Azure Search for this use case?
We could add a step in the pipeline that would synchronize our data to an Azure Search service upon doing CRUD, but this would mean slower CRUD as well as data duplication, and the consumer of our api would have to use a search endpoint to get an id, and then do an additional lookup afterwards to get any related data.
If you can expose the data you want to make searchable to Azure Search using a "vanilla" (non-Gremlin) SQL API query, consider using Azure Search indexers for Cosmos DB. However, for simple string matching searches Azure Search may be an overkill - use it if you need more sophisticated searches (natural language-aware in many languages, custom tokenization, custom scoring, etc.).
If you need a tighter integration between Cosmos DB Graph API and Azure Search, vote for this UserVoice suggestion.
As far as I can work out, CosmoDB has the ability to make Graph queries using the Gremlin query language. Apart from that the pricing, marketing etc. all seem the same. It seems strange that they came up with a new product to add Gremlin when they didn't do the same to add MongoDB support. What are the discernable differences between these two products?
The Azure Cosmos DB team member here.
Azure Cosmos DB started as “Project Florence” in 2010 to address developer pain-points faced by large scale applications inside Microsoft. Observing that the challenges of building globally distributed apps are not a problem unique to Microsoft, in 2015 we made the first generation of this technology available to Azure developers in the form of Azure DocumentDB. Since that time, we’ve added new features and introduced significant new capabilities. Azure Cosmos DB is the result. It is the next big leap in globally distributed, at scale, cloud databases. As a part of this release of Azure Cosmos DB, DocumentDB customers, with their data, are automatically Azure Cosmos DB customers. The transition is seamless and they now have access to the new breakthrough system and capabilities offered by Azure Cosmos DB.
In the evolution of Cosmos DB, we have added significant new capabilities since 2015 (when DocumentDB was made generally available) but only a subset of these capabilities was available in DocumentDB. These capabilities are in the areas of the core database engine as well as, global distribution, elastic scalability and industry-leading, comprehensive SLAs. Specifically, we have evolved the Cosmos DB database engine to be able to efficiently map all popular data models, type systems and APIs to the underlying data model of Cosmos DB. The developer facing manifestation of this work currently will experience it via support for Gremlin and Table Storage APIs. And this is just the beginning… We will be adding other popular APIs and newer data models over time with more advances towards performance and storage at global scale.
We also have extended the foundation for global and elastic scalability of throughput and storage. One of the very first manifestations of it is the RU/m (https://learn.microsoft.com/en-us/azure/cosmos-db/request-units-per-minute) but we have more capabilities that we will be announcing in these areas. The new capabilities will help save cost for our customers for various workloads. We have made several foundational enhancements to the global distribution subsystem. One of the many developer facing manifestations of this work is the consistent prefix consistency model (making in total 5 well-defined consistency models). However, there are many more interesting capabilities we will release as they mature.
It is important to point out that we view Azure Cosmos DB as a constantly evolving database service. Typically, we first validate all new capabilities with the large scale applications inside Microsoft, subsequently expose them to key external customers, and finally, release them to the world.
It is also important to point out that DocumentDB’s SQL dialect has always been just one of the many APIs that the underlying Cosmos DB was capable of supporting. As a developer using a fully managed service like Cosmos DB, the only interface to the service is the APIs exposed by the service. To that end, nothing really changes for a DocumentDB customer. Cosmos DB offers the exactly the same SQL API that DocumentDB did. However, now (and in the future) you can get access to other capabilities which were previously not accessible.
DocumentDB is one of the APIs for CosmosDB. Others include Table Storage, MongoDB, Gremlin.
Think about CosmosDB as the database platform that handles scaling, throughput, consitency, etc and DocumentDB as one of the types of the databases than run on CosmosDB.
Azure Cosmos DB natively supports multiple data models including documents, key-value, graph, and column-family. The core content-model of Cosmos DB’s database engine is based on atom-record-sequence (ARS). Atoms consist of a small set of primitive types like string, bool, and number. Records are structs composed of these types. Sequences are arrays consisting of atoms, records, or sequences.
The database engine can efficiently translate and project different data models onto the ARS-based data model. The core data model of Cosmos DB is natively accessible from dynamically typed programming languages and can be exposed as-is as JSON.
https://learn.microsoft.com/en-us/azure/cosmos-db/introduction
CosmosDB is the new DocumentDB for NoSQL solution.
As Cosmosdb architect Rimma mentioned
The Azure Cosmos DB DocumentDB API or SQL (DocumentDB) API is now
known as Azure Cosmos DB SQL API. You don't need to change anything to
continue running your apps built with DocumentDB/DocumentDB API. The
functionality remains the same. Thanks.
DocumentDB is one of the APIs for CosmosDB.As of now, if you go to Azure portal and try to create an Azure Cosmos DB, you have to select one of the 4 APIs available there:
Gremlin (Graph)
MongoDB
SQL (DocumentDB)
Table (key-value)