In the previous article of this series, "[A deep dive into Azure’s billing system](https://nebula-graph.io/posts/a-deep-dive-into-azure-marketplace-billing-system)", we talked about the billing and listing of your SaaS offer. In fact, in addition to SaaS services, Azure Marketplace has other service models. This article will use the practical experience of NebulaGraph as an example to talk about several ways that are suitable for combining technical products like graph databases with cloud vendors, here I distinguish them as:

*   SaaS Fully managed service
*   Azure Application Self-service provisioning
*   Managed Service

The above-mentioned service types have their corresponding similar service models in all major cloud vendors and are not unique to Azure, so this article is a general discussion of solutions separate from cloud vendor platforms.

## SaaS Fully managed service

Fully managed service is the most widely known cloud service model, where the service provider manages the machine and service resources, assumes all operations and maintenance responsibilities, guarantees service stability, and provides customers with an out-of-the-box experience. It has the following advantages.

Provide SaaS services, allowing users to build their own business quickly out of the box without the effort of service operation and maintenance

With a fully managed cloud service model, resources and manpower are allocated in a reasonable manner, making cloud services more advantageous in terms of the overall cost.

1.  Software providers usually pre-purchase resources in bulk and can bargain with the cloud vendor for resources based on the advantage of high volume, and the price of obtaining the same amount of computing resources is usually more affordable than what the average user sees when purchasing.
2.  Cloud service users, considering that they don’t need additional investment in operation and maintenance effort, essentially save their own costs.

Provide a full set of solutions, supporting products are better integrated and easier to use, and make it easier for users to get started. And with the volume of fully managed cloud services, it is often easier to receive comprehensive feedback and develop a more universal solution.

With the above advantages, users of fully managed SaaS services generally only need to think about:

1.  Whether they trust the software vendor enough to be willing to leave the machine and service resources to the vendor to manage their DevOps.
2.  Weighing this against their own situation, they conclude that using cloud services is a more cost-effective solution.
      ![](http://www-cdn.nebula-graph.io/nebula-website-5.0/images/blogs/azure-marketplace-three-cloud-service-models-for-isvs/figure1.png)

## Azure application self-service provisioning

Compared to fully managed SaaS services, self-service provisioning is actually similar to the traditional On-Premise model, except that it uses machine resources on the cloud and is more closely integrated with the cloud vendor. The software vendor can quickly help users automatically request machine resources to create standalone services on the cloud by defining deployment templates for the services and the corresponding execution scripts. This service model has the following benefits.

1.  Compared with the traditional On-Premise model, the self-service provisioning model is better integrated, integrating the steps of machine resource preparation, service deployment and network allocation, saving the installation and deployment time of users or delivery implementers and standardizing the delivery process. And it is closely integrated with the cloud vendor, relying on the cloud vendor platform commonality function to facilitate daily resource control and observation.
2.  Compared to the fully managed SaaS model, the self-service provisioning model often uses the BYOL (Bring your own license) model of payment. Users pay the cloud vendor for the resources used to run the service, and then buy a software license from the software provider to activate the service. The overall fee is generally higher than fully managed, but the advantage is that the data and machine resources are controlled by the user, which is suitable for customers who have extremely high requirements for data security and do not allow data to be stored in a third party.

Since the machine and data resources exist under the user's private cloud VPC, when the service is deployed, the operation and maintenance of the subsequent service need to be borne by the user. Even if vendors can be invited to provide operation and maintenance by purchasing consulting services, they cannot respond as quickly as fully-managed services.
![](http://www-cdn.nebula-graph.io/nebula-website-5.0/images/blogs/azure-marketplace-three-cloud-service-models-for-isvs/figure2.png)


## Managed service

The managed service model is a compromise between a fully managed cloud service and a self-service model, based on a hypothetical scenario: let the machine and data services remain in the user's VPC, and the machine and service operations and maintenance responsibilities to the software vendor. The integrity of cloud vendors’ intermediate operations and maintenance is either guaranteed by audit logs provided by them or by third-party security assessment agencies.

Here is how the managed service model is realized in Azure:

*   The deployment of services is similar to the self-service model, where the software vendor defines the deployment templates and corresponding scripts for the services, enabling the user to complete one-click deployment of the generated services.
*   The subscriber authorizes their VPC rights to the software vendor either temporarily or permanently through the authorization capabilities provided by the cloud vendor, so that the software vendor can intervene to perform DevOps operations.
*   Currently Azure requires the user to take the initiative to submit a work order to the software vendor on the cloud vendor platform to request DevOps. The prerequisite requirement here is that the user is required to identify the problem, and then the software vendor is required to resolve it.
*   Since the authorized and operated machine resources come from the cloud vendor platform, Azure is currently providing audit logs specific to the resource level to facilitate users to review the actions done by the software vendor on their machines when needed, but service level auditing is not yet available.

From a personal point of view, the current form of Managed Service provided by Azure is still quite a distance from the ideal state of managed service model.

*   Cloud vendors need to provide better control and oversight roles, and provide a more fine-grained level of service audit logging capabilities.
*   The discovery of DevOps issues should ideally not depend on the user, which would be similar to the SaaS fully managed experience, so that the user does not need to care about DevOps and does not need to have knowledge about it.
![](http://www-cdn.nebula-graph.io/nebula-website-5.0/images/blogs/azure-marketplace-three-cloud-service-models-for-isvs/figure3.png)

## Conclusion

This is part of NebulaGraph's past experience in exploring cloud-based graph database services. If we compare the three service models, from my personal point of view, the fully managed cloud service model is undoubtedly the best choice for the future as people's usage habits change and the corresponding infrastructure is improved. We have recently released our SaaS [fully managed offering of NebulaGraph](https://portal.azure.com/#create/vesoftcompanylimited1625556994617.nebula_graph_cloud/preview) on the Azure Marketplace and you are welcome to try it out.

In addition, for users who need to keep their data in their own hands, our Manage Service on Azure is also under development, please stay tuned.

## About the author

Jerry Liang is a technical lead at NebulaGraph’s Cloud division. He and his team are behind a series of NebulaGraph’s visualization tools such as [Nebula Dashboard](https://nebula-graph.io/products/dashboard/), [Nebula Explorer](https://nebula-graph.io/products/explorer/), and [Nebula Studio](https://nebula-graph.io/products/studio/).

*   [Part I: How to list your cloud offer successfully?](https://nebula-graph.io/posts/how-to-list-cloud-offer-azure-marketplace)
*   [Part II: A deep dive into Azure's billing system](https://nebula-graph.io/posts/a-deep-dive-into-azure-marketplace-billing-system)
*   [Part III: My takes on three cloud service models for ISVs](http://nebula-graph.io/posts/azure-marketplace-three-cloud-service-models-for-isvs)

In addition to SaaS services, Azure Marketplace has other service models. In this article I will talk about the difference between Azure's SaaS Fully managed service, Azure Application Self-service provisioning, and its Managed Service.

Azure Marketplace series: My take on three cloud service models for ISVs

I would like to share my opinionated reference data infrastructure stack with some of those best open-source projects with modern ETL, Dashboard, Metadata Governance, and Data Lineage Management.

Introducing a metadata management system that uses NebulaGraph as graph database

Graph databases are a relatively new and exciting type of NoSQL database that have been increasingly used for sophisticated applications over the past decade. Graph databases model their data using nodes and edges that form a “graph” (hence the name).

Graphs are mathematical abstractions of networks: for example, a social network where each person (or organization) is a node, and the connections between them are edges. This allows intuitive queries like: "Find me all people I went to school with", or "Get me all friends of my friends who work in advertising". 

# **How graph databases work**

A graph database is a kind of NoSQL database. It's a type of database that focuses on storing data as entities and their relations.

Graphs are a natural way to model complex relationships in data, such as user profiles, social connections and recommendations.

The term "graph" might seem a bit abstract, but it actually refers to a type of data structure that's used to model relationships between different pieces of information. For example, if you have a list of friends and their contact information, you can use a graph database to store this data in the form of nodes (pieces of information) and edges (connections between them).

Graph databases are different from other types of NoSQL databases because it stores data as nodes (vertices) and edges, rather than as rows and columns. This makes them ideal for storing highly connected data, such as social networks or recommendation systems.

![](http://www-cdn.nebula-graph.io/nebula-website-5.0/images/blogs/what-is-a-graph-database/figure1.png)

They are used for a variety of applications, including social networking, recommendation systems, fraud detection and analysis, and logistics.

# What are the benefits of a graph database?

Graph databases are a relatively new concept in the database world. They are best known for their ability to handle relational data, such as relationships between people, places and things. Graphs are a good match for complex relationships between entities, and graph databases can be used to model complex data in many domains.

This makes them a good fit for many real-world use cases, from social networks to supply chains, where multiple entities are connected in complex ways.

The power of graph databases in a nutshell: The best way to understand the power of using a graph database is to compare it with its traditional counterpart — the relational database.

**Some of the benefits of using a graph database include:**

**Every entity and their relationships in the real world can be represented as a graph.** This means you get all of the benefits of traditional relational databases without having to worry about foreign keys or other limitations. Also, the modeling of real-world data will be more intuitive because you are essentially abstracting the real world into a graph of entities and relations.
![](http://www-cdn.nebula-graph.io/nebula-website-5.0/images/blogs/what-is-a-graph-database/figure)

**Graph databases support structured or unstructured data.** You can store any type of data in a graph database without worrying about restructuring it first. You can also combine different types of data sources into one query if they're all represented as nodes and edges.

**Simple querying for multi-hop queries.** Graph databases allow you to perform multi-hop queries to find out how far away something is from another point in just one line of GQL statement, which is almost impossible in traditional relational databases.

**Supports both structured data and unstructured data. **Graph databases support both structured data, like tabular data, and unstructured data, like JSON, making them ideal for storing semi-structured data such as sensor data collected by IoT devices.
![](http://www-cdn.nebula-graph.io/nebula-website-5.0/images/blogs/what-is-a-graph-database/figure3.png)

**Graph databases are also highly performant** because they allow you to query complex queries over the network of connections between objects rather than just individual objects themselves. For example: find all people who know each other through their friend groupings; find all people who like each other's posts on Facebook; or find all people who live in the same city as each other even if they don't know each other directly but may have passed by each other during their daily commute.

# Graph database use cases

Graph databases can be used to support various graph-based scenarios. These include social networking, recommendation systems, fraud detection, and chatbot systems, etc.

## Fraud detection

Fraud detection is important to any organization, be it a financial service or simply a web service. With the increase in technology and the ease of information being shared with other parties, traditional methods of fraud detection have been rendered obsolete.&nbsp;

Graph technology is the state of the art of fraud detection. The reason is that it contains a massive amount of data, and even if one piece of information is incorrect or missing, the system will still be able to identify the user as fraudulent. Graph technology is used by financial institutions to detect fake identities (e.g., people trying to open accounts with fake ID cards), credit card fraud (e.g., someone applying for credit with a stolen credit card), and money laundering (e.g., someone trying to move money from one account into another).

Related: [Fraud detection: How to detect and visualize fraudulent activities using knowledge graph](https://nebula-graph.io/posts/fraud-detection-using-knowledge-and-graph-database)

## Real-time recommendation

Recommendation engines are widely used by websites such as Amazon, Netflix, Spotify and others for generating personalized recommendations for products or content based on a user's prior interests or history with the website.&nbsp;

For example, if you've bought X before then perhaps we should recommend Y? The most common type of recommendation engine is collaborative filtering which makes recommendations by analyzing user behavior data collected from previous purchases etc.

Graph databases are well suited for this task because they can leverage users' relationships with friends or colleagues to recommend relevant content.

## Chatbot system

Natural languages can be transformed into knowledge graphs and stored in a graph database. A question organized in a natural language can be resolved by a semantic parser in an intelligent question-answer system and re-organized. Then, possible answers to the question can be retrieved from the knowledge graph and provided to the one who asked the question.

## Social networking

Social networking is a very popular use case for graph databases. Graph databases such as NebulaGraph and Neo4j are specifically designed to support social networks.&nbsp;A social network is a way of representing relationships between people or things. They are often represented visually in the form of graphs that show how things are connected. Graphs can be used to represent both online and offline relationships between people; for example, Facebook uses them to represent friendships between users and LinkedIn uses them to represent professional connections between users.

# Latest trends in graph database

Graph database is a somewhat novel piece of technology and it is consistently evolving. The field was once dominated by traditional powerhouse Neo4j, but now the market is much more dynamic, with new players like NebulaGraph, AWS Neptune, and Janus Graph.

Graph databases have been around for more than 20 years. They were first used by computer scientists working on artificial intelligence (AI) projects, who needed a way to model complex systems that can't be represented as tables or lists of records.

Today, businesses are increasingly using graph databases for their own needs. The graph database market is expected to grow from $1.59 billion&nbsp; in 2020 to $11.25 billion by 2030, according to [Emergen Research](https://www.prnewswire.com/news-releases/graph-database-market-size-to-reach-usd-11-25-billion-in-2030--increasing-demand-for-flexible-online-schema-environments-is-a-key-factor-driving-industry-demand-says-emergen-research-301478726.html#:~:text=Global%20graph%20database%20market%20is,is%20boosting%20market%20revenue%20growth.).

The popularity of graph databases has been driven by several factors:

Data grows rapidly — Every day we generate more than [2.5 quintillion bytes of data](https://techjury.net/blog/how-much-data-is-created-every-day/) globally. This is expected to grow exponentially over time as sensors become more prevalent, mobile devices become more ubiquitous and machine-to-machine communication increases

Data types vary widely — From unstructured text documents and images to structured data such as financial transaction records or sensor readings, many different types of data exist today

Data distribution varies widely — Data can be distributed across multiple locations at different scales (local vs global) and in different formats (JSON vs XML).&nbsp;

Because of the explosion of global data volume and the distribution of data, graph databases are becoming more important and are adapting themselves to these trends.

Here are some of the latest trends in the graph database field.

## Distributed graph databases

Distributed graph databases is the latest trend in graph database as global data grows rapidly. A distributed database is a database that is split into multiple servers, so that the throughput and storage capacity of the entire system is greater than the sum of its parts.

A distributed graph database is a database that consists of two or more files located in different sites either on the same network or on entirely different networks. Portions of the database are stored in multiple physical locations and processing is distributed among multiple database nodes.

Distributed databases provide high availability and fault tolerance because they maintain multiple copies of data that can be accessed through processes known as replication and shadowing. The cost of maintaining such systems has traditionally been considered too high for general purpose applications like spreadsheets or word processors, but with the advent of inexpensive disk storage there are now many applications that require such features.

Distributed databases are ideal for large-scale applications with complex data requirements, such as e-commerce systems and the Internet. They can also be useful when there are some constraints on the location of the data — for example, if you need to keep certain records in a certain jurisdiction (eg. the EU) because they contain sensitive information or if you have regional offices that need to share data across their networks.

The technical and cost advantages of distributed systems (like NebulaGraph) over single machines (e.g. Neo4j) or small machines are more obvious due to the increasing volume of data and computation. Distributed systems allow applications to access these thousands of machines as if they were local systems, without the need for much modification at the code level.

[NebulaGraph](https://nebula-graph.io/) is a distributed, easily scalable, and native graph database. It is capable of hosting graphs with hundreds of billions of vertices and trillions of edges, and serving queries with millisecond-latency.

With a shared-nothing distributed architecture, NebulaGraph offers linear scalability, meaning that you can add more nodes or services to the cluster without affecting performance. It also means that if you want to horizontally scale out NebulaGraph, you don’t need to change the configuration of the existing nodes. As long as the network bandwidth is sufficient, you can add more nodes without changing anything else.

## GQL - The graph query language standard

One of the disadvantages of graph databases was the lack of a standard graph query language like SQL for relational databases.&nbsp;

In the past, you have got [Cpher](https://en.wikipedia.org/wiki/Cypher_(query_language)), a declarative graph query language invented by Neo4j; [Gremlin](https://tinkerpop.apache.org/gremlin.html), a graph traversal language developed by Apache TinkerPop; and [nGQL](https://nebula-graph.io/posts/graph-query-language-comparison-cypher-gremlin-ngql), NebulaGraph’s SQL-like graph query language.

The lack of a standard in query languages made it difficult to build applications that used different graph databases from different vendors.

However, in the last few years, there has been a lot of research activity in this area and some standardization efforts have been made by the industry.

In September 2019, members of ISO/IEC Joint Technical Committee, which is responsible for international Information Technology standards, proposed a project to create a new standard graph query language (ISO/IEC 39075 Information Technology — Database Languages — GQL). GQL is intended to be a declarative database query language, like SQL.

The [GQL project proposal](https://isotc.iso.org/livelink/livelink?func=ll&objId=20911483&objAction=Open&viewType=1) states:
> "Using graph as a fundamental representation for data modeling is an emerging approach in data management. In this approach, the data set is modeled as a graph, representing each data entity as a vertex (also called a node) of the graph and each relationship between two entities as an edge between corresponding vertices.> The graph data model has been drawing attention for its unique advantages. Firstly, the graph model can be a natural fit for data sets that have hierarchical, complex, or even arbitrary structures. Such structures can be easily encoded into the graph model as edges. This can be more convenient than the relational model, which requires the normalization of the data set into a set of tables with fixed row types. Secondly, the graph model enables efficient execution of expensive queries or data analytic functions that need to observe multi-hop relationships among data entities, such as reachability queries, shortest or cheapest path queries, or centrality analysis.> There are two graph models in current use: the Resource Description Framework (RDF) model and the Property Graph model. The RDF model has been standardized by W3C in a number of specifications. The Property Graph model, on the other hand, has a multitude of implementations in graph databases, graph algorithms, and graph processing facilities.> However, a common, standardized query language for property graphs (like SQL for relational database systems) is missing. GQL is proposed to fill this void."

It is expected that the GQL standard become available by the end of this year(2022). In June 2022, the GQL Standard website said in an [update](https://www.gqlstandards.org/) that “It turns out that writing a database language standards is a lot of work, but we are making progress.”

Just like how SQL provided to a boost to the popularity of relational databases, the availability of GQL standard is also expected to further promote the use of graph database.

## Take away: Graph database is the future of business intelligence

Graph databases have been around for decades. In recent years, however, they’ve become increasingly popular because they offer new ways of visualizing and analyzing data that can help companies make better decisions about their business processes.

It's not just a buzzword; companies like Facebook, LinkedIn, Google and Twitter are using graph databases to store their data and make sense of it.

Graph databases are a carrier of big data, which makes it possible to process anything you need using an intuitive and effective means; by using information, relational data and non-relational data as input. The graph databases market is now young enough to raise your interest – the future looks very promising for graph databases.

For now, the future of business intelligence appears to be a distinctive blend of "old and new". Relational databases will continue to be widely used but increasingly supplemented with or replaced by graph databases – with the caveat that this switch is not an "either/or" affair. Nor does it represent a radical change in attitude toward data storage: the key lies in adopting an enterprise-wide understanding of data, rather than one based on individual silos.

A graph database is a specialized type of NoSQL database that stores the connections between entities (nodes) and the relations associated with them (edges).

What is a graph database and what are its use cases - Definition, examples & trends


![how-to-list-cloud-offer-azure-marketplace](https://user-images.githubusercontent.com/57335825/164643613-7828d649-0c02-4096-bd38-9fded2db6ce5.png)

*This post is part of a series that is focused on how to successfully launch your software solution on the Azure Marketplace, Microsoft's online market for buying and selling cloud solutions certified to run on Azure.*

I work for NebulaGraph, an open-source graph database management system. We've recently launched NebulaGraph on the Azure Marketplace to provide Azure users with a cloud-based database as a service (DBaaS). This is the result of six months' effort from me and my team members. During the whole process, we have encountered numerous challenges and failed miserably a lot of times. Now I'm telling my story and experience and, hopefully, this series of articles will help you navigate Azure's complex reviewing system and resolve some of the problems you may encounter.

## The What – What is Azure Marketplace
Azure Marketplace is an online market that allows software providers to offer their cloud solutions to a global audience of businesses. Azure will handle account and billing systems so that you don't have to. The marketplace is a great channel where independent software vendors (ISVs) like NebulaGraph can sell their products. All you need to do in order to list your product in the Marketplace is to register as a Microsoft partner. Once you have a listing in place, customers can purchase it directly through the marketplace using their Microsoft accounts and billing information. It allows your solution to be easily discovered by customers. The marketplace can be used as a valuable marketing tool to acquire new customers.

The products you can offer in the Azure Marketplace mainly fall into three categories:

- Software, which includes virtual machine images, web applications, and developer services
- Data services, which include business intelligence, analytics, and networking services
- Consulting services

In the article, we will mainly focus on how to publish a software offer, but the process is pretty much the same for the other two types of products.

## The Why – Azure Marketplace benefits for software solutions
After lots of research and comparison, we decided to list our product as a SaaS offer in the Azure Marketplace. One of the most obvious reasons is that Azure is huge – it is [one of the world's largest public cloud service providers](https://www.gartner.com/en/newsroom/press-releases/2021-06-28-gartner-says-worldwide-iaas-public-cloud-services-market-grew-40-7-percent-in-2020) with 19.7% of the global market. This means that our listing will be visible to millions of [enterprise customers](https://azure.microsoft.com/en-gb/case-studies/) like 3M Informatics and Verizon. 

But as a team leader of a cloud database product, I'm a big fan of the Azure Marketplace also for the following reasons:

### Easy onboarding

The Azure Marketplace provides a great opportunity for us to onboard new customers that are already using Microsoft Azure. Microsoft customers can easily find our cloud service in the Azure Marketplace, try it with a few clicks, and quickly get started with a free trial or by purchasing through their Azure subscription.

![why-azure-marketplace-easy-onboarding](https://user-images.githubusercontent.com/57335825/164644410-8e5912ec-28a9-4a02-bcfd-f702cc7d4226.png)

### We can leverage Azure's account and billing systems directly

Azure Marketplace provides a neat solution for startups like NebulaGraph. Customers can purchase free or paid offers on-demand using Azure's account and billing systems directly. Microsoft's account and billing systems will help us gain more trust from potential customers – this is critically important since we are still new to the market. Plus, it will largely simplify the billing logic for us, reducing a lot of redundant work.

Azure also offers an easy and helpful admin system for you to configure your SaaS offer on demand. 

![why-azure-marketplace-leverage-account-billing-system](https://user-images.githubusercontent.com/57335825/164644662-c4e6c439-4b9f-46ab-9b90-ba8b3a3a66f2.png)

## The How - How to create a listing, correctly

While Azure already provided detailed [instructions](https://docs.microsoft.com/en-us/azure/marketplace/plan-saas-offer) on how to list a SaaS offer in the marketplace, we still encountered numerous difficulties during the process. Here, I'd like to introduce the steps from my own experience. I hope this will have you navigate the process and reduce unnecessary back and forth.

First, you need to sign up for an account at the [Microsoft Partner Center](https://docs.microsoft.com/en-us/azure/marketplace/create-account). This will allow you to create and configure your SaaS offer.

After you have created your commercial marketplace account, you can start to create a product. You can choose from many types of offers, including SaaS, managed services, and even consulting services. In this example, we will choose the SaaS offer type.

### Create a demo listing

Your first step of successfully creating a SaaS listing will be creating a demo listing. In the SaaS Create Demo setup page, you will need to fill in all the configurations listed on the left sidebar, including the offer overview, properties, availability, and so on. You can refer to Azure's [Plan a test and development SaaS offer](https://docs.microsoft.com/en-us/azure/marketplace/plan-saas-dev-test-offer) for more details on how to fill in this information.

![create-demo-listing-azure-marketplace](https://user-images.githubusercontent.com/57335825/164645203-35c26df2-cb92-4e2c-9565-876d0fe7293a.png)

Once you have finished the basic setup and published it to preview, you will be prompted with a preview link where you can visit the SaaS offer you have created. On the preview page, you can create a test subscription to see if it works.

Here is where you can find your preview link.

![azure-marketplace-demo-listing-preview](https://user-images.githubusercontent.com/57335825/164655257-ff5a21f1-a331-4238-ad98-d92fa532df01.png)

Here is an example of the preview of your SaaS offer in the Azure Marketplace.

![azure-marketplace-demo-listing-preview-example](https://user-images.githubusercontent.com/57335825/164657003-184f95ef-ea91-4f91-ab0a-cf706a5c4309.png)

You may wonder how the Azure marketplace communicates with your SaaS application or solution. In the Technical configuration tab, you can find configurations that help Azure talk to your application.

- Landing page URL – A SaaS website URL that customers will land on after subscribing to your offer from the Azure Marketplace.
- Connection webhook – Microsoft will send all asynchronous events, including subscription creation, cancellation, and upgrade, to you through the webhook.
- Azure Active Directory tenant ID and Azure Active Directory application ID – You can find your tenant ID for your Azure Active Directory and your application ID in the App registrations blade in Azure Active Directory.

![azure-marketplace-demo-listing-configuration](https://user-images.githubusercontent.com/57335825/164658763-6b8076ee-b599-47ce-9d52-4c5987689a18.png)

### Set up billing

You can create SaaS offers that are billed according to non-standard units you have defined upfront, such as bandwidth, CPU, or storage. Customers then pay according to their consumption of these units. You will also need to inform Azure about these billable events via the commercial marketplace metering service API as they occur. For more details about how to set up the billing system, refer to Azure's [documentation](https://docs.microsoft.com/en-us/azure/marketplace/partner-center-portal/saas-metered-billing) here.

### Go live

Once you have completed the basic settings for your SaaS application, you can click the "Go live" button to publish your offer for real users to access.

![azure-marketplace-demo-listing-go-live](https://user-images.githubusercontent.com/57335825/164662127-0a5b5d93-40bb-46d2-b2a4-06995fa81b55.png)

## Billing is a big challenge

Billing is one of the biggest challenges we faced during the listing process. While Azure has provided a solid billing solution, there are still quite a few problems you have to watch out for.

The first problem is how to keep users' usage on our own server updated with Azure's billing system. We know that Azure has provided an API where we can upload users' usage to the billing system. In order to keep the two sources of data up to date, you have to follow the following rules:

- One resource metric can only be updated once within one hour. You may encounter a duplicate error if you try to update twice within an hour.
- You have to update users' usage data to Azure's billing system within 24 hours. I think this rule helps avoid billing users more than what they should pay.
- Azure will notify you via the webhook you have configured if a user cancels their subscription. You have to confirm via the webhook that you have received the message. Otherwise, the notification will repeat forever.

The second problem you have to watch out for is that upon the configuration of your SaaS offer, you can only configure up to 30 billing metrics, or non-standard units as mentioned above. Metrics may include traffic usage, disk space, and emails sent. Remember that you cannot delete or update any of these metrics once you have published your SaaS offer. My advice is that you think thoroughly about what billing metrics you want to add and make sure you don't want to make any changes in the near future. 

The last challenge related to billing is that Azure only provides a relatively fixed billing logic, meaning that sometimes you cannot configure your pricing and plans the way you wanted. For example, with Azure's vanilla billing system, you can't offer a pricing plan that gives new users a 30% discount for one year, or change the price of an existing subscriber if you need to.

Our solution to inflexible Azure's billing system is adding a standalone billing metric called "service credit" on our end. This billing metric is different from the billing metrics we defined. It solely serves as a buffer metric that enables us to control users' usage more flexibly. For example, if we want to give new users a 30% discount for one year, we will give them service credits that are equivalent to 30% of their billing amount so that they are essentially paying 70% of the amount of their billings. 

I will talk more about billing problems in a follow-up article. Please stay tuned.

## Brief Summary

This article is about the main steps of listing a SaaS product in the Azure Marketplace. I mainly want to give you an overview of the whole process from a developer's perspective. In the rest of this series about how to deliver a SaaS product in the Azure Marketplace, I will talk about the following topics:

- Problems and limits of Azure's billing system and how to fix them.
- The difference between Azure's managed service, SaaS offer, and Azure Lighthouse.

Finally, NebulaGraph Cloud is currently available in the Azure Marketplace and it is in a beta period that offers a generous 70% off for beta users. Sign up here to [get the offer](https://nebula-graph.io/nebula-graph-cloud/) if you are interested.

## About the author

Jerry Liang is a technical lead at NebulaGraph's Cloud division. He and his team are behind a series of NebulaGraph's visualization tools such as [Nebula Dashboard](https://nebula-graph.io/products/dashboard/), [Nebula Explorer](https://nebula-graph.io/products/explorer/), and [Nebula Studio](https://nebula-graph.io/products/studio/).

NebulaGraph has just been launched as a DBaaS offer on Microsoft Azure Marketplace. This article shares how to list the cloud offer successfully on Azure Marketplace.

The Azure Marketplace series: How to list your cloud offer successfully?


![How to Migrate Data from Neo4j to NebulaGraph](https://user-images.githubusercontent.com/57335825/93444876-a1604080-f885-11ea-93aa-4c7c74a62869.png)

This article mainly introduces how to migrate your data from Neo4j to [NebulaGraph](https://github.com/vesoft-inc/nebula) with NebulaGraph Exchange (or Exchange for short), a data migration tool backed by the NebulaGraph team. Before introducing how to import data, let's first take a look at how data migration is implemented inside NebulaGraph.

## Data processing in NebulaGraph Exchange

The name of our data migration tool is NebulaGraph [Exchange](https://github.com/vesoft-inc/nebula-java/tree/master/tools/exchange). It uses Spark as the import platform to support huge dataset import and ensure performance. The DataFrame, a distributed collection of data organized into named columns, provided by Spark supports a wide array of data sources. With DataFrame, to add new data source, you only need to provide the code for the configuration file to read and the Reader type returned by the DataFrame.

![Create DataFrame in Spark](https://user-images.githubusercontent.com/57335825/93446469-24819680-f886-11ea-9060-abe90ddfce6f.png)

As mentioned above, a DataFrame is a distributed collection of data organized into rows and columns. A DataFrame can be stored in multiple partitions. The partitions are stored on different machines to support parallel operations. Besides, Spark also provides a set of APIs that allow users to operate DataFrames easily, just like operating locally. What's more, most of the databases support exporting data into DataFrames. Even if a database does not provide such a function, you can manually build a DataFrame with the database driver.

After transforming data into a DataFrame, NebulaGraph Exchange traverses each row in the DataFrame, obtain the corresponding values by column names according to the fields mapping relationship in the configuration file. After traversing `batchSize` rows, Exchange writes the obtained data into NebulaGraph at one time. Currently, Exchange generates nGQL statements and then writes data asynchronously by the Nebula Client. We will support exporting the sst files stored in the underlying storage of NebulaGraph to acquire better performance. Next, let's move on to the implementation of Neo4j data import.

## Implementing Data Import from Neo4j

Neo4j provides an official library to export data directly as a DataFrame. However, it doesn't support resumable downloads. Therefore, we did not use this library directly. Instead, we use the official Neo4j driver to read data. To obtain better performance, Exchange executes different `skip` and `limit` Cypher statements by calling Neo4j drivers on different partitions, and distributes data to different partitions. The number of partitions is specified by the configuration parameter `partition`.

Exchange imports the Neo4j data in the following steps: First, the Neo4jReader class in Exchange replaces the Cypher statement `exec` and statement after the `return` in the user configuration with `count(*)` and executes them to obtain the total data size. Second, the Exchange calculates the initial offset and size for each partition according to the partition number. If parameter `check_point_path` is configured, Exchange reads the file under this directory, too. If the download is in resumable status, Exchange calculates the initial offset and size for each partition, then adds different `skip` and `limit` after the Cypher statements in each partition and calls the driver to execute. Last, Exchange transforms the returned data to DataFrame.

The procedure is demonstrated in the following picture:

![image](https://user-images.githubusercontent.com/57335825/93451598-3c5c1900-f88c-11ea-9656-f4425f730bd5.png)

## Practice Data Importing from Neo4j to NebulaGraph

We use the following system environment to demonstrate the import here:

Hardware:

- CPU name: Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz
- CPU cores: 14
- memory size: 251G

Software:

- Neo4j version: 3.5.20 community
- NebulaGraph: Deployed with [Docker Compose](https://github.com/vesoft-inc/nebula-docker-compose). We use the default configurations and deploy NebulaGraph on the preceding machine.
- Spark: Single node. Version: 2.4.6 pre-build for hadoop2.7.

Since NebulaGraph is a strongly-typed schema database, you need to create a space, tags, and edges types before importing data. For more information, see [Create space syntax](https://docs.nebula-graph.io/manual-EN/2.query-language/4.statement-syntax/1.data-definition-statements/create-space-syntax/).

Here we create a space named test, with the replication number as one. We create two types of tags: tagA and tagB. Both have four properties. In addition, we create an edge type edgeAB, which also has four properties. The nGQL queries are as follows:

```sql
# Create graph space test
CREATE SPACE test(replica_factor=1);
# Use graph space test
USE test;
# Create tag tagA
CREATE TAG tagA(idInt int, idString string, tboolean bool, tdouble double);
# Create tag tagB
CREATE TAG tagB(idInt int, idString string, tboolean bool, tdouble double);
# Create edge type edgeAB
CREATE EDGE edgeAB(idInt int, idString string, tboolean bool, tdouble double);
```

Now let's import the Mock data to Neo4j. The Mock data contains one million vertices labeled with tagA and tagB, ten million edges labeled with edgeAB. Note that data exported from Neo4j must have properties, the data type must be exactly the same as that of NebulaGraph.

Finally, to speed up the Mock data importing to Neo4j and improve the read performance, we created indexes for the property `idInt` both in tagA and tagB. Attention here, Exchange does not import indexes and constraints to NebulaGraph. So do remember to [create](https://docs.nebula-graph.io/manual-EN/2.query-language/4.statement-syntax/1.data-definition-statements/#create_index) and [rebuild index](https://docs.nebula-graph.io/manual-EN/2.query-language/4.statement-syntax/1.data-definition-statements/#rebuild_index).

Then we import the data from Neo4j to NebulaGraph. First let's download and pack the project. You can find the project in the `tools/exchange` directory of the [nebula-java](https://github.com/vesoft-inc/nebula-java) repository. Run the following commands:

```shell
git clone https://github.com/vesoft-inc/nebula-java.git
cd nebula-java/tools/exchange
mvn package -DskipTests
```

Then you see the `target/exchange-1.0.1.jar` file.

Next, we move to the configuration file. The format of the configuration file is HOCON (Human-Optimized Config Object Notation). Let's modify based on the `src/main/resources/server_application.conf` file. First, configure address, user, pswd, and space for NebulaGraph. We use the default test environment here so we don't modify anything here. Next, configure the tags. We only demonstrate configurations for tagA because configurations for tagB are the same as that of tagA.

```shell
{
    # ====== connection configuration for neo4j=======
    name: tagA
    # Must be exactly the same as the tag name in NebulaGraph. Must be created before importing.
    server: "bolt://127.0.0.1:7687"
    #  address configuration for neo4j
    user: neo4j
    # neo4j username
    password: neo4j
    # neo4j password

    encryption: false
    # (Optional): Whether to encrypt the transformation. The default value is false.
    database: graph.db
    # (Optional): neo4j databases name, not supported in the Community version

    # ======import configurations============
    type: {
        source: neo4j
        # PARQUET, ORC, JSON, CSV, HIVE, MYSQL, PULSAR, KAFKA...
        sink: client
        # Write method to NebulaGraph, only client is supported at present. We will support direct export from NebulaGraph in the future.
    }

    nebula.fields: [idInt, idString, tdouble, tboolean]
    fields       : [idInt, idString, tdouble, tboolean]
    # Mapping relationship fields. The upper is the nebula property names, the lower is the neo4j property names. All the property names are correspondent with each other.
    # We use the List instead of the Map to configure the mapping relationship to keep the field order, which is needed when exporting nebula storage files.

    vertex: idInt
    # The neo4j field corresponds to the nebula vid field. The type must be int.

    partition: 10
    # Partition number.
    batch: 2000
    # Max data write limit.

    check_point_path: "file:///tmp/test"
    # (Optional): Save the import information directory, used for resumable downloads.

    exec: "match (n:tagA) return n.idInt as idInt, n.idString as idString, n.tdouble as tdouble, n.tboolean as tboolean order by n.idInt"
}
```

The configurations for edges are similar to that of vertices. However, you need to configure source vid and destination vid for edges because a NebulaGraph edge contains source vid and destination vid. The edge configurations are as follows:

```shell
source: {
  field: a.idInt
  # policy: "hash"
}
# configuration for source vertex ID
target: {
  field: b.idInt
  # policy: "uuid"
}
# configuration for destination vertex ID

ranking: idInt
# (Optional): The rank field.

partition: 1
# Set partition number as 1. We set it to one here. We will talk about the reason later.

exec: "match (a:tagA)-[r:edgeAB]->(b:tagB) return a.idInt, b.idInt, r.idInt as idInt, r.idString as idString, r.tdouble as tdouble, r.tboolean as tboolean order by id(r)"
```

You can use the hash policy or the UUID policy for vertices, edge source vertices, and edge destination vertices. The hash/uuid function maps the string type fields into the integer type fields.

Because the preceding example uses integer VIDs, no policy setting is needed. See [here](https://docs.nebula-graph.io/manual-EN/2.query-language/2.functions-and-operators/uuid/) to know the difference between hash and uuid.

In Cypher, we use keywords `ORDER BY` to ensure the same order for the same query. Although the returned data order seems the same without `ORDER BY`, to avoid data loss in data importing, we strongly suggest using `ORDER BY` in Cypher, though the importing speed is sacrificed to some extent. To raise the importing speed, you'd better sort the indexed properties. If there aren't any indexes, check the default order and choose a suitable one to improve performance. If you can't find any sorting rules in the default returned data, you can sort the data by the vertex/edge ID, and set the `partition` value as small as possible to reduce the sorting pressure for Neo4j. That's why we set the `partition` number to one in this example.

In addition, NebulaGraph uses ID as the unique primary key when creating vertices and edges. If the primary key exists before inserting new data, the old data under the primary key will be overwritten. Therefore, using repetitive Neo4j property values as the NebulaGraph ID will lead to data loss because vertices with the same ID are regarded as one vertex and only the last write is saved. Since the data importing to NebulaGraph is parallel, we don't guarantee that the final data is the latest data in Neo4j.

Another thing you need to pay attention to is the resumable download. Between the breakpoint and the resume, the database must not change status, for example inserting or deleting data is not allowed. The `partition` number mustn't be modified or data loss can occur.

Finally, because Exchange executes different `skip` and `limit` Cypher queries on different partitions, the users mustn't provide queries including `skip` and `limit`.

Next, run the Exchange to import data. Execute the following commands:

```shell
$SPARK_HOME/bin/spark-submit  --class com.vesoft.nebula.tools.importer.Exchange --master "local[10]" target/exchange-1.0.1.jar -c /path/to/conf/neo4j_application.conf
```

Under the preceding configurations, importing one million vertices takes 13 seconds, importing ten million edges takes 213 seconds. Thus the total importing takes 226 seconds.

## Appendix: Comparisons between Neo4j 3.5 Community and NebulaGraph 1.0.1

Neo4j and NebulaGraph are different in system architecture, data model, and access method. So we have listed some frequently-seen differences in the following table for your reference:

![Comparison between Neo4j and NebulaGraph](https://user-images.githubusercontent.com/57335825/93454914-7e875980-f890-11ea-87af-c19d429457b6.png)

> Hi, I’m Mengjie Li, the software engineer in NebulaGraph. Currently I am involved in storage engine development. I hope this article is helpful and let me know if you have any thoughts and suggestions. Thanks!

## You might also like

1. [New Players: Something You Should Know When Reading NebulaGraph Source Code](https://nebula-graph.io/posts/how-to-read-nebula-graph-source-code/)
1. [Performance Comparison: Neo4j vs NebulaGraph vs JanusGraph](https://nebula-graph.io/posts/performance-comparison-neo4j-janusgraph-nebula-graph/)

This article describes how you can migrate data from Neo4j to NebulaGraph using the NebulaGraph Exchange tool based on Spark.

How to Migrate Data from Neo4j to NebulaGraph with NebulaGraph Exchange


![nebula graph benchmark report](https://user-images.githubusercontent.com/57335825/92886598-a118fe80-f3c8-11ea-9f61-941c70d97863.png)

## Testing Environment

### Specs

- CPU: Intel® Xeon® CPU E5-2697 v3 @ 2.60GHz, 2(sockets) * 14(cores) * 2(threads)
- Memory: DDR4，64GB * 4
- Storage: HP MT0800KEXUU，NVMe，800GB * 2
- Network: Mellanox MT27500 10Gb/s

- Five servers in total have been used for this testing:

1. One for graphd (the query engine process)
2. Three for storaged (the storage engine process).The meta service is deployed on the same hosts with the storage service.
3. One for (Golang) client. A single process with multiple goroutines.

- OS: Centos 7.5
- NebulaGraph Version: V1.0.0 GA 1
- Graph Space partition: 24

### Key Configs in NebulaGraph

#### Storaged

```bash
# One RocksDB instance per disk
# The default reserved bytes for one batch operation
--rocksdb_batch_size=4096
# The default block cache size used in BlockBasedTable.
# The unit is MB.
--rocksdb_block_cache=102400
--num_io_threads=24
--num_worker_threads=18
--max_handlers_per_req=256
--min_vertices_per_bucket=100
--reader_handlers=28
--vertex_cache_bucket_exp=8

--rocksdb_disable_wal=true
--rocksdb_column_family_options={"write_buffer_size":"67108864",
  "max_write_buffer_number":"4","max_bytes_for_level_base":"268435456"}
--rocksdb_block_based_table_options={"block_size":"8192"}
```

#### Graphd

```bash
# The number of networking IO threads, 0 for # of CPU cores
--num_netio_threads=20
# The number of threads to execute user queries, 0 for # of CPU cores
--num_worker_threads=32
--storage_client_timeout_ms=600000
--filter_pushdown=false
```

## Intro to the Dataset

### Data source

LDBC Social Network Benchmark Dataset

The LDBC is designed to be a plausible look-alike of a social network site. For a detailed introduction to the dataset, see [https://github.com/ldbc](https://github.com/ldbc)

### Data scale

- Scale Factor is 1000
- Data size: 632GB
- Disk size occupied: ~500GB (* number of replicas)
- Number of Vertices: 1,243,792,996
- Number of Edges: 8,397,443,896

### Schema

![schema](https://user-images.githubusercontent.com/57335825/92889809-64023b80-f3cb-11ea-9b4e-20a09c578f40.png)

## The K-Hop Out-degree Distribution in LDBC

### One-hop out-degree distribution

Most vertices have less than 10 outgoing edges. Some super vertices have 700 outgoing edges.

![One-hop out-degree distribution](https://user-images.githubusercontent.com/57335825/92889971-8d22cc00-f3cb-11ea-9f57-116c22499408.png)

### Two-hop out-degree distribution

Most vertices have less than 2000 two-hop adjacency nodes. Some super vertices have 40000 such nodes, though.

![Two-hop out-degree distribution](https://user-images.githubusercontent.com/57335825/92890180-b93e4d00-f3cb-11ea-9279-7de88120dc28.png)

### Three-hop out-degree distribution

Most vertices have less than 100,000 three-hop adjacency nodes. Some super vertices have 2,000,000 such nodes, though.

![Three-hop out-degree distribution](https://user-images.githubusercontent.com/57335825/92890293-d96e0c00-f3cb-11ea-855c-4f158e84043d.png)

## Query Samples

### K-hop without Retrieving Properties

```bash
GO 1 STEP FROM $ID$ OVER knows 
GO 2 STEP FROM $ID$ OVER knows 
GO 3 STEP FROM $ID$ OVER knows 
```

### K-hop with Retrieving Properties

```bash
GO 1 STEPS FROM $ID$ OVER knows YIELD knows.time, $$.person.first_name,\
   $$.person.last_name, $$.person.birthday
                                     
GO 2 STEPS FROM $ID$ OVER knows YIELD knows.time, $$.person.first_name,\
   $$.person.last_name, $$.person.birthday
                                     
GO 3 STEPS FROM $ID$ OVER knows YIELD knows.time, $$.person.first_name,\
   $$.person.last_name, $$.person.birthday     
```
Note: The $ID$ in the statements is the placeholder of the starting vertex for a graph traverse. It will be substituted by the some random vertex ID upon query execution.

## Testing Results

The results include the throughput and latency for each query.

### One-hop Results without Properties

![One-hop Results without Properties](https://user-images.githubusercontent.com/57335825/92891739-066eee80-f3cd-11ea-8915-0ad2150fcba1.png)

### Two-hop Results without Properties

![Two-hop Results without Properties](https://user-images.githubusercontent.com/57335825/92891888-26061700-f3cd-11ea-9bc0-de51173b5412.png)

### Three-hop Results without Properties

![Three-hop Results without Properties](https://user-images.githubusercontent.com/57335825/92892041-4504a900-f3cd-11ea-87da-b7d5e05b88d2.png)

### One-hop Results with Properties

![One-hop Results with Properties](https://user-images.githubusercontent.com/57335825/92892155-5d74c380-f3cd-11ea-96a4-950af0852ce1.png)

### Two-hop Results with Properties

![Two-hop Results with Properties](https://user-images.githubusercontent.com/57335825/92892263-79786500-f3cd-11ea-92b7-5750897f3287.png)

### Three-hop Results with Properties

![Three-hop Results with Properties](https://user-images.githubusercontent.com/57335825/92892409-9745ca00-f3cd-11ea-8815-1ac0e15b78e1.png)

You can find the testing code and the nGQL queries in this repo: [https://github.com/vesoft-inc/nebula-bench](https://github.com/vesoft-inc/nebula-bench)

For batch write performance, refer to the [Spark Writer doc](https://github.com/vesoft-inc/nebula-docs/blob/b515c37b950b54e3217066c6e4437107d3a45aa1/docs/manual-EN/3.build-develop-and-administration/5.storage-service-administration/data-import/spark-writer.md).

Share your thoughts by leaving comments below!


NebulaGraph has just published the benchmark data based on the LDBC social networking benchmark dataset. The report mainly focuses on the k-hop read latency and throughput performance.

NebulaGraph 1.0 Benchmark Report based on the LDBC Dataset


![Something You Should Know When Reading NebulaGraph Source Code](https://user-images.githubusercontent.com/57335825/89273066-e8ef7d80-d5f3-11ea-82a9-43ab5921de5c.png)

When I saw the NebulaGraph code repository for the first time, I was so shocked by its huge size that I didn't know how to dig into the source code. Then I worked up the nerve. After reading the code and running the use cases over and over, I finally gained some experience worth sharing with you, hoping that all my experience could push you to give NebulaGraph source code a shot to know more about the graph DBMS, to improve your graph database knowledge, and to fix some bugs that are not so complicated of this repository.

In this article, I took the `SHOW SPACES` statement as an example to show you how NebulaGraph processes an nGQL statement after it was input on the client side. GDB, the GNU Project debugger, was used to trace the execution.

Additionally, some open-source libraries are used in NebulaGraph. For more information, see the _Libraries_ section.

## Architecture of NebulaGraph

![Architecture of NebulaGraph](https://user-images.githubusercontent.com/57335825/89273171-0cb2c380-d5f4-11ea-9911-503fc21eee48.png)

A complete NebulaGraph DBMS contains three services: Query Service, Storage Service, and Meta Service. Each service has its own executable binary files.

Query Service is responsible for these tasks:

- Managing connection to the client
- Parsing an nGQL statement input from a client into an AST (Abstract Syntax Tree) and then parsing the AST to an execution plan 
- Optimizing the execution plan
- Executing queries with the optimized execution plan

Storage Service is responsible for distributed data store.

Meta Service is responsible for these tasks:

- Operating CRUD on graph schema objects
- Managing the cluster
- Performing user authentication

In this case, I used Query Service as an example to show you some experience.

## Source code directory hierarchy

When we get the source packages and have them unzipped, we should do a check of the source code directory hierarchy. Each package has its own functions. Here is how the `src` directory looks like.

```markdown
|--src
    |--client // Provides the code for the client
    |--common // Provides some common basic components
    |--console
    |--daemons
    |--dataman
    |--graph // Contains most codes of Query Service
    |--interface // Contains some communication interfaces for meta, storage, and query services
    |--jni
    |--kvstore
    |--meta // Relates to meta service information 
    |--parser // Contains modules for lexical parsing (Lexer) and semantic analysis 
    |--storage // Contains codes about the storage layer
    |--tools
    |--webservice
```

## Code tracing

In the `scripts` directory, use the scripts to start the metad and the storaged services.

![code tracking 01](https://user-images.githubusercontent.com/57335825/89273573-9498cd80-d5f4-11ea-8cce-77a005fe6eb8.png)

When the services are started, run the `nebula.service status all` to do a check of the service status.

![code tracking 02](https://user-images.githubusercontent.com/57335825/89273667-b5612300-d5f4-11ea-9547-506b9513bc61.png)

Start GDB and run the `nebula-graphd` binary program, which is in the `bin` directory.

```cpp
gdb> set args --flagfile  /home/mingquan.ji/1.0/nebula-install/etc/nebula-graphd.conf   //specify the arguments
gdb> set follow-fork-mode child   // This is a daemon, so the new process is debugged after a fork and the parent process runs unimpeded.
gdb> b main         // Set a breakpoint at entry to main
```

Use the `run` command to start the `nebula-graphd` program under GDB, and then use the `next` command to execute the code line by line until the command stops at the `gServer->serve();   // Blocking wait until shut down via gServer->stop()` line. It means the thread to receive the connection from the client is blocked and the server is waiting for the connection, so we need to find the function that processes the request sent from the client.

NebulaGraph uses FBThrift to define the communication interfaces for different services, and in the `src/interface/graph.thrift` file, you can find the communication interface definition for GraphService as follows.

```cpp
service GraphService {
    AuthResponse authenticate(1: string username, 2: string password)
    oneway void signout(1: i64 sessionId)
    ExecutionResponse execute(1: i64 sessionId, 2: string stmt)
}
```

The `gServer->serve()` line is preceded with the following lines.

```cpp
auto interface = std::make_shared<GraphService>();
status = interface->init(ioThreadPool);
gServer->setInterface(std::move(interface));
gServer->setAddress(localIP, FLAGS_port);
```

From these codes, we know that the `GraphService` object is the one that processes the connection and request sent from the client, so we can set a breakpoint at the `GraphService.cpp:future_execute` line to trace the execution.

Now, let's launch another terminal and change the path to the nebula installation directory. Run `./nebula -u=root -p=nebula` to connect to the nebula services. And then, run the `SHOW SPACES` statement. You will see that no result is returned. It is because the services are blocked for debugging on the server side. Let's go back to the server side and run the `continue` command, and the following lines are returned.

![show space code execution](https://user-images.githubusercontent.com/57335825/89273798-e5102b00-d5f4-11ea-9543-b9886ad2154a.png)

After `session` is verified, go to the `executionEngine->execute()` and run the `step` command to step inside the function.

```cpp
auto plan = new ExecutionPlan(std::move(ectx));
plan->execute();
```

Run the `step` command to step inside the `execute` function of `ExecutionPlan` and then run the following command.

```cpp
auto result = GQLParser().parse(rctx->query());
```

The `parse` module is mainly composed of Flex and Bison. Flex, working like regular expressions, is used to divide the input statements into tokens, and the **src/parser/scanner.lex** file is used as the lexicon data file. Bison is used to parse the tokens into an AST, and the **src/parser/parser.yy** file is used for semantic analysis. The semantic analysis works as follows.

```cpp
go_sentence
    : KW_GO step_clause from_clause over_clause where_clause yield_clause {
        auto go = new GoSentence();
        go->setStepClause($2);
        go->setFromClause($3);
        go->setOverClause($4);
        go->setWhereClause($5);
        if ($6 == nullptr) {
            auto *cols = new YieldColumns();
            for (auto e : $4->edges()) {
                if (e->isOverAll()) {
                    continue;
                }
                auto *edge  = new std::string(*e->edge());
                auto *expr  = new EdgeDstIdExpression(edge);
                auto *col   = new YieldColumn(expr);
                cols->addColumn(col);
            }
            $6 = new YieldClause(cols);
        }
        go->setYieldClause($6);
        $$ = go;
    }
```

When `GO` statements are matched, applicable nodes are constructed for an AST, and then the nodes are handled by Bison and the AST is generated.

After lexical analysis and semantic analysis are done, the execution module works. Still inside GDB, go inside the `execute` function and run the `step` command line by line and stop at the `ShowExecutor::execute` line.

![showExecutor](https://user-images.githubusercontent.com/57335825/89273954-1be64100-d5f5-11ea-8279-158019ffc874.png)

Run the `next` command line by line, and when it comes to the `showSpaces()` function, run the `step` command to step inside it.

```cpp
auto future = ectx()->getMetaClient()->listSpaces();
auto *runner = ectx()->rctx()->runner();
'''
'''
std::move(future).via(runner).thenValue(cb).thenError(error);
```

From the instructions above, we see that Query Service obtained the `spaces` data through the communications between metaClient and Meta Service, and then used the `cb` callback to return the data. Till now, the `SHOW SPACES` statement is executed completely. Other nGQL statements, even those more complicated ones, are executed in the similar way.

- For a running service, it is recommended that you have the process ID and then run the `gdb attach PID` command to debug this process. 
- If you don't want to launch both the server and the client for debugging, you can use the `test` directory. Each function under the `src` directory has its own `test` directory. It contains all the code for unit testing of the applicable function or module. These codes can be used to compile the functional module, and the execution can be traced. The `test` directory can be used as follows: 
   1. Under a directory for a functional module, find its `CMakeLists.txt` file and find the module name in this file. 
   1. In the `build` directory, run the `make <module name>` command. The applicable binary program is generated in the `build/bin/test` directory. 
   1. Start GDB to debug and trace the execution.


## Libraries

Before reading the NebulaGraph source code, you may need to know something about these libraries:

1. [Flex & Bison](https://pandolia.net/tinyc/ch1_overview.html): tools used for lexical analysis and semantic analysis. They parse the input nGQL statements into an AST.
1. [FBThrift](https://github.com/facebook/fbthrift#thrift-files): an open-source RPC framework, developed by Facebook. It defines the communication process among the Meta, Storage, and Graph layers of NebulaGraph DBMS.
1. [folly](https://github.com/facebook/folly): an open-source library of C++14 component, developed by Facebook. It offers functions like the Boost and the `std` libraries, but with optimized performance.
1. [Gtest](https://github.com/google/googletest): an open-source framework for C++ unit testing, developed by Google.

> Hi, I'm Ming Quan, engineer at NebulaGraph. I'm interested in database storage and would like to share my experiences in this regard. Hope my post is of help to you. Please let me know if you have any ideas about this. Thanks.

## You might also like

1. [NebulaGraph Architecture — A Bird’s View](https://nebula-graph.io/posts/nebula-graph-architecture-overview/)
1. [An Introduction to NebulaGraph's Storage Engine](https://nebula-graph.io/posts/nebula-graph-storage-engine-overview/)
1. [An Introduction to NebulaGraph’s Query Engine](https://nebula-graph.io/posts/nebula-graph-query-engine-overview/)

This article teaches you how to read the NebulaGraph source code by explaining how a graph query is executed in NebulaGraph in detail.

New Players: Something You Should Know When Reading NebulaGraph Source Code

This post will discuss the ideas and considerations behind graph databases such as their use cases, advantages and the trends behind this database model with several real-world case example.

A Review of Graph Databases


![Graph Query Language Comparison Series - Gremlin vs Cypher vs nGQL](https://user-images.githubusercontent.com/57335825/83609880-b1048500-a533-11ea-9174-8b3f31150887.png)

In September 2019, [Graph Query Language](https://www.gqlstandards.org/home) is accepted as a new database query language in a vote by the International SQL Standards Committee, the unification of GQL takes time.  

![GQL](https://user-images.githubusercontent.com/38887077/75741236-f357d380-5d44-11ea-8c43-65283b49bbef.png)

In this post, we've selected some mainstream graph query languages and compared the CRUD usage in these languages respectively.

# Which Graph Query Languages to Be Compared

![image](https://user-images.githubusercontent.com/38887077/75741240-f5ba2d80-5d44-11ea-80f6-f44d39fff43a.png)

## Gremlin

[Gremlin](https://tinkerpop.apache.org/gremlin.html) is a graph traversal language developed by Apache TinkerPop and has been adopted by a lot of graph database solutions. It can be either **declarative** or **imperative**.

Gremlin is Groovy-based, but has many language variants that allow developers to **write Gremlin queries natively** in many modern programming languages such as Java, JavaScript, Python, Scala, Clojure and Groovy.

**Supported graph databases**: Janus Graph, InfiniteGraph, Cosmos DB, DataStax Enterprise(5.0+) and Amazon Neptune.

## Cypher

[Cypher](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=13&cad=rja&uact=8&ved=2ahUKEwi5-ZfEtfvnAhWSad4KHTDpClwQFjAMegQIBRAB&url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCypher&usg=AOvVaw3rCtDns3Bbr5mIuBpSN4hr) is a declarative graph query language that allows expressive and efficient data querying in a property graph.

The language was designed with the power and capability of SQL. The keywords of the Cypher language are not case sensitive, but attributes, labels, relationship types and variables are case sensitive.

**Supported graph databases**: Neo4j, AgensGraph and RedisGraph

## nGQL

**NebulaGraph** introduces its own query language, [nGQL](https://docs.nebula-graph.io/manual-EN/1.overview/1.concepts/2.nGQL-overview/), which is a declarative, textual query language like SQL, but designed for graphs.

The keywords of the nGQL language are case sensitive and it support statement composition so that there's no need for statement embedding.

**Support graph databases**: NebulaGraph

# Terms Comparison

Before comparing the three graph query languages, let's take a look at their terms and concepts first. The table below explains how these languages define nodes and edges:

| Graph Terms | Gremlin | Cypher | nGQL |
| --- | --- | --- | --- |
| Vertex | Vertex | Node | Vertex |
| Edge | Edge | Relationship | Edge |
| Vertex Type | Label | Label | Tag |
| Edge Type | label | RelationshipType | edge type |
| Vertex ID | vid | id(n) | vid |
| Edge ID | eid | id(r) | \ |
| Insert | add | create | insert |
| Delete | drop | delete | delete / drop |
| Update | setProperty | set | update |

# Syntax Comparison - CRUD

After understanding the common terms in Gremlin, Cypher, and nGQL, let's take a look at the general syntax of these graph query languages.

This section will walk you through the basic CRUD syntax for Gremlin, Cypher and nGQL respectively.

## Graph

Refer to the following example on how to create a graph space. We omitted Cypher since you don't need to create a graph space before you can add any data to the graph databases.

```shell
# Create a graph that Gremlin can traverse
g = TinkerGraph.open().traversal()

# Create a graph space in nGQL
CREATE SPACE gods
```

## Vertex

We all know that graph consists of nodes and edges. A node in Cypher is called a vertex in Gremlin and nGQL. And an edge is the connection among two nodes.

Refer to the following example on inserting new vertex in these query languages respectively.

```shell
# Insert vertex in Gremlin
g.addV(vertexLabel).property()

# Insert vertex in Cypher
CREATE (:nodeLabel {property})

# Insert vertex in nGQL
INSERT VERTEX tagName (propNameList) VALUES vid:(tagKey propValue)
```

### Vertex Type

The nodes/vertices can have types. They are called `labels` in Gremlin and Cypher , and `tags` in nGQL.

A vertex type can have multiple properties. For example, vertex type _Person_ have two properties, i.e. _name_ and _age_.

![image](https://user-images.githubusercontent.com/38887077/75741241-f8b51e00-5d44-11ea-8a39-b02a88de44a3.png)

#### Create Vertex Type

Refer to the following example on vertex type creation. We omitted Cypher since you don't need a label before inserting data.

```shell
# Create vertex type in Gremlin
g.addV(vertexLabel).property()

# Create vertex type in nGQL
CREATE tagName(PropNameList)
```

Note that Gremlin and nGQL both support `IF NOT EXISTS`. This keyword automatically detects if the corresponding vertex type exists. If it does not exist, a new one is created. Otherwise, no vertex type is created.

#### Show Vertex Types

When the vertex types are created, you can show them with the following queries. They will list all the labels/tags rather than certain labels/tags.

```shell
# Show vertex types in Gremlin
g.V().label().dedup();

# Show vertex types in Cypher method 1
MATCH (n) 
RETURN DISTINCT labels(n)
# Show vertex types in Cypher method 2
CALL db.labels();

# Show vertex types in nGQL
SHOW TAGS
```

### CRUD on Vertices

This section introduces the basic CRUD operations on vertices using the three query languages.

#### Insert Vertices

```shell
# Insert vertex of certain type in Gremlin
g.addV(String vertexLabel).property()

# Insert vertex of certain type in Cypher
CREATE (node:label) 

# Insert vertex of certain type in nGQL
INSERT VERTEX <tag_name> (prop_name_list) VALUES <vid>:(prop_value_list)
```

#### Get Vertices

```shell
# Fetch vertices in Gremlin
g.V(<vid>)

# Fetch vertices in Cypher
MATCH (n) 
WHERE condition
RETURN properties(n)

# Fetch vertices in nGQL
FETCH PROP ON <tag_name> <vid>
```

#### Delete Vertices

```shell
# Delete vertex in Gremlin
g.V(<vid>).drop()

# Delete a vertex in Cypher
MATCH (node:label) 
DETACH DELETE node

# Delete vertex in nGQL
DELETE VERTEX <vid>
```

#### Update a Vertex's Property

This section shows you how to update properties for vertex.

```shell
# Update vertex in Gremlin
g.V(<vid>).property()

# Update vertex in Cypher
SET n.prop = V

# Update vertex in nGQL
UPDATE VERTEX <vid> SET <update_columns>
```

Both Cypher and nGQL use keyword `SET` to set the vertex type, except that the `UPDATE` keyword is added in nGQL to identify the operation. The operation of Gremlin is similar to the above-mentioned fetching vertex, except that it adds operations for changing property.

## Edges

This section introduces the basic CRUD operations on edges.

### Edge Types

Like vertices, edges can also have types.

```shell
# Create an edge type in Gremlin
g.edgeLabel()

# Create an edge type in nGQL
CREATE EDGE edgeTypeName(propNameList)
```

####CRUD on Edges

#### Insert Edges of Certain Types

Inserting an edge is similar to inserting vertices. Cypher  uses `-[]->` and and nGQL uses `->` to represent edges respectively. Gremlin uses the keyword `to()` to indicate edge direction.

Edges are by default directed in the three languages. The chart on the left below is a directed edge while the one on the right is an undirected edge.

![image](https://user-images.githubusercontent.com/38887077/75741248-fbb00e80-5d44-11ea-9c80-0c11fd41a277.png)

```shell
# Insert edge of certain type in Gremlin
g.addE(String edgeLabel).from(v1).to(v2).property()

# Insert edge of certain type in Cypher
CREATE (<node1-name>:<label1-name>)-
  [(<relationship-name>:<relationship-label-name>)]
  ->(<node2-name>:<label2-name>)

# Insert edge of certain type in nGQL
INSERT EDGE <edge_name> ( <prop_name_list> ) VALUES <src_vid> -> <dst_vid>: ( <prop_value_list> )
```

#### Delete Edges

```shell
# Delete edge in Gremlin
g.E(<eid>).drop()

# Delete edge in Cypher
MATCH (<node1-name>:<label1-name>)-[r:relationship-label-name]->()
DELETE r

# Delete edge in nGQL
DELETE EDGE <edge_type> <src_vid> -> <dst_vid>
```

#### Fetch Edges

```shell
# Fetch edges in Gremlin
g.E(<eid>)

# Fetch edges in Cypher
MATCH (n)-[r:label]->()
WHERE condition
RETURN properties(r)

# Fetch edges in nGQL
FETCH PROP ON <edge_name> <src_vid> -> <dst_vid>
```

## Other Operations

In addition to the common CRUD on vertices and edges, we will also show you some combined queries in the three graph query languages.

### Traverse edges

```shell
# Traverse edges with specified vertices in Gremlin
g.V(<vid>).outE(<edge>)

# Traverse edges with specified vertices in Cypher
Match (n)->[r:label]->[]
WHERE id(n) = vid
RETURN r

# Traverse edges with specified vertices in nGQL
GO FROM <vid> OVER <edge>
```

### Traverse edges reversely

In reverse traverse, Gremlin uses `in` to indicate reversion, Cypher uses `<-`. nGQL uses keyword `REVERSELY`.

```shell
# Traverse edges reversely with specified vertices Gremlin
g.V(<vid>).in(<edge>)

# Traverse edges reversely with specified vertices Cypher
MATCH (n)<-[r:label]-()

# Traverse edges reversely with specified vertices nGQL
GO FROM <vid>  OVER <edge> REVERSELY
```

### Traverse edges bidirectionally

If the edge direction is [irrelevant](https://www.google.com/search?q=irrelevant&spell=1&sa=X&ved=2ahUKEwjR1fPGovvnAhUsIDQIHXSzDRIQkeECKAB6BAgOECs) (either direction is acceptable),  Gremlin uses `bothE()`, Cypher use `-[]-`, and nGQL use keyword `BIDIRECT` .

```shell
# Traverse edges reversely with specified vertices Gremlin
g.V(<vid>).bothE(<edge>)

# Traverse edges reversely with specified vertices Cypher
MATCH (n)-[r:label]-()

# Traverse edges reversely with specified vertices nGQL
GO FROM <vid>  OVER <edge> BIDIRECT
```

### Query N hops along specified edge

Gremlin and nGQL use `times` and `STEP` respectively to represent N hops. Cypher uses `relationship*N`.

```shell
# Query N hops along specified edge in Gremlin
g.V(<vid>).repeat(out(<edge>)).times(N)

# Query N hops along specified edge in Cypher
MATCH (n)-[r:label*N]->()
WHERE condition
RETURN r

# Query N hops along specified edge in nGQL
GO N STEPS FROM <vid> OVER <edge>
```

### Find paths between two vertices

```shell
# Find paths between two vertices in Gremlin
g.V(<vid>).repeat(out()).until(<vid>).path()

# Find paths between two vertices in Cypher
MATCH p =(a)-[.*]->(b)
WHERE condition
RETURN p

# Find paths between two vertices in nGQL
FIND ALL PATH FROM <vid> TO <vid> OVER *
```

# Example queries

This section introduces some demonstration queries.

## Demo model: The Graphs of Gods

The examples in this section make extensive use of the toy graph distributed with [Janus Graph](https://janusgraph.org/) called _[The Graphs of Gods](https://docs.janusgraph.org/#getting-started)_ as diagrammed below。

This example describes the relationships between the beings and places of the Roman pantheon.

![image](https://user-images.githubusercontent.com/38887077/75741255-ffdc2c00-5d44-11ea-9da6-b15327f03ad4.png)

## Inserting data

```bash
# Inserting vertices
# nGQL
nebula> INSERT VERTEX character(name, age, type) VALUES hash("saturn"):("saturn", 10000, "titan"), hash("jupiter"):("jupiter", 5000, "god");
# Gremlin
gremlin> saturn = g.addV("character").property(T.id, 1).property('name', 'saturn').property('age', 10000).property('type', 'titan').next();
==>v[1]
gremlin> jupiter = g.addV("character").property(T.id, 2).property('name', 'jupiter').property('age', 5000).property('type', 'god').next();
==>v[2]
gremlin> prometheus = g.addV("character").property(T.id, 31).property('name',  'prometheus').property('age', 1000).property('type', 'god').next();
==>v[31]
gremlin> jesus = g.addV("character").property(T.id, 32).property('name',  'jesus').property('age', 5000).property('type', 'god').next();
==>v[32]
# Cypher
cypher> CREATE (src:character {name:"saturn", age: 10000, type:"titan"})
cypher> CREATE (dst:character {name:"jupiter", age: 5000, type:"god"})

# Inserting edges
# nGQL
nebula> INSERT EDGE father() VALUES hash("jupiter")->hash("saturn"):();
# Gremlin
gremlin> g.addE("father").from(jupiter).to(saturn).property(T.id, 13);
==>e[13][2-father->1]
# Cypher
cypher> CREATE (src)-[rel:father]->(dst)
```

## Deleting

```bash
# nGQL
nebula> DELETE VERTEX hash("prometheus");
# Gremlin
gremlin> g.V(prometheus).drop();
# Cypher
cypher> MATCH (n:character {name:"prometheus"}) DETACH DELETE n 
```

## Updating

```bash
# nGQL
nebula> UPDATE VERTEX hash("jesus") SET character.type = 'titan';
# Gremlin
gremlin> g.V(jesus).property('age', 6000);
==>v[32]
# Cypher
cypher> MATCH (n:character {name:"jesus"}) SET n.type = 'titan';
```

## Fetching/Reading

```bash
# nGQL
nebula> FETCH PROP ON character hash("saturn");
===================================================
| character.name | character.age | character.type |
===================================================
| saturn         | 10000         | titan          |
---------------------------------------------------
# Gremlin
gremlin> g.V(saturn).valueMap();
==>[name:[saturn],type:[titan],age:[10000]]
# Cypher
cypher> MATCH (n:character {name:"saturn"}) RETURN properties(n)
  ╒════════════════════════════════════════════╕
  │"properties(n)"                             │
  ╞════════════════════════════════════════════╡
  │{"name":"saturn","type":"titan","age":10000}│
  └────────────────────────────────────────────┘
```

## Finding the name of Hercules's Father

```bash
# nGQL
nebula>  LOOKUP ON character WHERE character.name == 'hercules' | \
      -> GO FROM $-.VertexID OVER father YIELD $$.character.name;
=====================
| $$.character.name |
=====================
| jupiter           |
---------------------
# Gremlin
gremlin> g.V().hasLabel('character').has('name','hercules').out('father').values('name');
==>jupiter
# Cypher
cypher> MATCH (src:character{name:"hercules"})-[:father]->(dst:character) RETURN dst.name
      ╒══════════╕
      │"dst.name"│
      ╞══════════╡
      │"jupiter" │
      └──────────┘
```

## Finding the name of Hercules's Grandfather

```bash
# nGQL
nebula> LOOKUP ON character WHERE character.name == 'hercules' | \
     -> GO 2 STEPS FROM $-.VertexID OVER father YIELD $$.character.name;
=====================
| $$.character.name |
=====================
| saturn            |
---------------------
# Gremlin
gremlin> g.V().hasLabel('character').has('name','hercules').out('father').out('father').values('name');
==>saturn
# Cypher
cypher> MATCH (src:character{name:"hercules"})-[:father*2]->(dst:character) RETURN dst.name
      ╒══════════╕
      │"dst.name"│
      ╞══════════╡
      │"saturn"  │
      └──────────┘
```

## Find the characters with age > 100

```bash
# nGQL
nebula> LOOKUP ON character WHERE character.age > 100 YIELD character.name, character.age;
=========================================================
| VertexID             | character.name | character.age |
=========================================================
| 6761447489613431910  | pluto          | 4000          |
---------------------------------------------------------
| -5860788569139907963 | neptune        | 4500          |
---------------------------------------------------------
| 4863977009196259577  | jupiter        | 5000          |
---------------------------------------------------------
| -4316810810681305233 | saturn         | 10000         |
---------------------------------------------------------
# Gremlin
gremlin> g.V().hasLabel('character').has('age',gt(100)).values('name');
==>saturn
==>jupiter
==>neptune
==>pluto
# Cypher
cypher> MATCH (src:character) WHERE src.age > 100 RETURN src.name
      ╒═══════════╕
      │"src.name" │
      ╞═══════════╡
      │  "saturn" │
      ├───────────┤
      │ "jupiter" │
      ├───────────┤
      │ "neptune" │
      │───────────│
      │  "pluto"  │
      └───────────┘
```

## Find who are Pluto's cohabitants, excluding Pluto himself

```bash
# nGQL
nebula>  GO FROM hash("pluto") OVER lives YIELD lives._dst AS place | GO FROM $-.place OVER lives REVERSELY WHERE \
$$.character.name != "pluto" YIELD $$.character.name AS cohabitants;
===============
| cohabitants |
===============
| cerberus    |
---------------
# Gremlin
gremlin> g.V(pluto).out('lives').in('lives').where(is(neq(pluto))).values('name');
==>cerberus
# Cypher
cypher> MATCH (src:character{name:"pluto"})-[:lives]->()<-[:lives]-(dst:character) RETURN dst.name
      ╒══════════╕
      │"dst.name"│
      ╞══════════╡
      │"cerberus"│
      └──────────┘
```

## Pluto's Brothers

```bash
# which brother lives in which place?
# nGQL
nebula> GO FROM hash("pluto") OVER brother YIELD brother._dst AS god | \
GO FROM $-.god OVER lives YIELD $^.character.name AS Brother, $$.location.name AS Habitations;
=========================
| Brother | Habitations |
=========================
| jupiter | sky         |
-------------------------
| neptune | sea         |
-------------------------
# Gremlin
gremlin> g.V(pluto).out('brother').as('god').out('lives').as('place').select('god','place').by('name');
==>[god:jupiter, place:sky]
==>[god:neptune, place:sea]
# Cypher
cypher> MATCH (src:Character{name:"pluto"})-[:brother]->(bro:Character)-[:lives]->(dst)
RETURN bro.name, dst.name
      ╒═════════════════════════╕
      │"bro.name"    │"dst.name"│
      ╞═════════════════════════╡
      │ "jupiter"    │  "sky"   │
      ├─────────────────────────┤
      │ "neptune"    │ "sea"    │
      └─────────────────────────┘
```

In addition to the basic operations in the three graph query languages, we will work on another piece of comparison of advanced operations in these languages. Stay tuned!

# You might also like

1. [The Review on Graph Database](https://nebula-graph.io/posts/review-on-graph-databases/)
1. [NebulaGraph Architecture — A Bird’s View](https://nebula-graph.io/posts/nebula-graph-architecture-overview/)


Graph users have to learn different graph query languages due to the lack of international standard like SQL. This post compares the basic ops among Cypher, Gremlin, and nGQL.