Graph databases are becoming increasingly prominent in the DBMS market for its advantages in uncovering important relationships of multiple datasets. Thus, they are ideal for use cases such as real-time recommendations, fraud detection and  knowledge graph constructions. Neo4j has been a leader since the early stage of the development of graph databases, therefore widely adopted by numerous organizations. However, with the explosion of data growth, organizations find sharding Neo4j too complicated and time-consuming, and looking for a solution to replace it. 

To help organizations with Neo4j’s challenges of operations and performance at scale  to make the critical decision of replacement, we hereby present a Neo4j alternative that is not only powerful but also open source, distributed, and fast. We also illustrate why big established companies are migrating to NebulaGraph. Welcome to the world of NebulaGraph.

# NebulaGraph: Open-Source, Distributed and Lighting Fast
NebulaGraph has cemented its name in the DBMS market as a lightning fast graph database with millisecond latency. Extremely huge quantities of graph data can be processed at speeds, which is a delight to any data scientist or developer.

As we lay out the following strengths that make NebulaGraph standout as a go-to alternative to Neo4j, you will notice that the strengths that make NebulaGraph a better alternative are those very qualities that those who work with data crave to see in a DBMS. 

From flexibility to efficiency that dazzles, let's see why NebulaGraph is finding wide acceptance as a perfect alternative and a solution to the challenges that many users encounter with Neo4j. 

Top strengths of NebulaGraph over Neo4j
- Shared-nothing distributed architecture
- Excellent at processing ultra large-scale connected data sets that have hundreds of billions of nodes and trillions of edges
- No bottleneck whatsoever when it comes to single-master write
- Supports linear expansion of reading and writing

Let’s now get into the details; 

## 1. Performance

NebulaGraph is highly performant thanks to RocksDB, the powerful storage engine that offers high throughput plus low latency read and write. The design is best described as state of the art, capable of achieving the following:

- Fast graph traversals (including complex graph traversals)
- Efficient memory use
- Real-time write performance
- Concurrent user access at very high levels
- Fast batch data import
- Efficient  n-hop query performance

Fact: Of all the open source graph database options in the market today, NebulaGraph is the only one that is capable of processing graph data that contains trillions of edges and vertices.

Read: [Why the Meituan team selected NebulaGraph as their graph storage engine after they performed intensive comparison tests](https://www.nebula-graph.io/posts/benchmarking-mainstraim-graph-databases-dgraph-nebula-graph-janusgraph).

## 2. High availability
This is another advantage that accrues from the horizontal scalability capability. Even in the midst of failures, you can be sure that NebulaGraph will be available.

An in-built [snapshot feature](https://www.nebula-graph.io/posts/nebula-graph-snapshot-introduction) makes it possible to capture snapshots of instances. You can then use these snapshots to restore data to any specific point in time. In case of data loss, the snapshots will come in handy.

What will happen if an instance fails? NebulaGraoh will get the failed instance out of the cluster, then create a new instance based on the snapshot. This new one will replace the failed instance. Remember all this happens automatically in real-time, and you can see everything, which is important for transparency.

## 3. Horizontal scalability
When it comes to scalability, NebulaGraph provides linear scalability - thanks to a shared nothing architecture. With this, you are able to add more and more nodes as well as services to the cluster without fearing a likelihood to compromise performance.

Additionally, you need not make any changes to the configurations of the nodes whenever you want to scale horizontally - as long as the bandwidth is enough.  It’s the best scalable graph database out here. 

## 4. Efficiency
NebulaGraph uses its own query language known as nGQL. The good thing with this query language is that it's very easy to understand, learn how it works and use. The greatest highlight of nGQL is that it transforms complex SQL queries to simple, brief queries. This single feature introduces significant efficiency that you will find hard to come by in Neo4j.

NGQL is also compatible with ISO-GQL and openCypher. With this level of compatibility, you are able to cut down on costs associated with learning and migration (more on migration shortly). Compatibility is another huge win for efficiency.

## 5. Flexibility
NebulaGraph works perfectly well wherever you take it. On-premises, macOS/Windows, public cloud, or hybrid cloud, NebulaGraph will work smoothly all the way.

Additionally, it comes with visualization tools that are so easy to use from the browser. This kind of flexibility unchains users and enables them to apply the database in creative ways.

## 6. Graph RAG (Retrieval-Augmented Generation)
NebulaGraph's [Graph RAG](https://www.nebula-graph.io/posts/graph-RAG#post-what-is-graph-rag) is the first of its kind in the industry. It combines [knowledge graphs with LLMs](https://www.nebula-graph.io/posts/graph-RAG) to enhance search results, meaning the results are intelligent, accurate and the process is cost-effective.

This is a welcome relief from the traditional methods which depend on keyword matching which is not effective especially when it comes to long tail queries.

Also Read:  [Graph RAG vs. Graph + Vector RAG](https://www.nebula-graph.io/posts/graph-RAG#post-demo-graph-rag-vs-vector-rag-vs-text2cypher)

## Visualization

Visualization is a key pillar of graph databases, and NebulaGraph offers multiple amazing visualization tools, including:
- [Nebula Dashboard](https://www.nebula-graph.io/products/dashboard)
- [Nebula Studio](https://www.nebula-graph.io/products/studio) (Community edition)
- [Nebula Explorer](https://www.nebula-graph.io/products/explorer) (Enterprise edition only)

## 8. Algorithm
The Nebula Algorithm is a GraphX- based Spark application that submits a Spark task to perform computing on data in a NebulaGraph database.

It's also possible to use the algorithm programmatically under the lib repository to accomplish graph computing on dataframe.

Please go through the overview of the [NebulaGraph algorithm](https://docs.nebula-graph.io/3.4.1/graph-computing/nebula-algorithm/).

## 9. Zero Learning Curve
nGQL, the query language for NebulaGraph, is gradually compatible with openCypher. This means new adopters can simply get started without worrying about the learning curve.

This is a very important quality because it means developers can get started with no complications, while operations professionals can equally work with Nebula Graph without being intimidated on the technical side. 

Here is a quick glance at what [nGQL](https://docs.nebula-graph.io/3.6.0/3.ngql-guide/1.nGQL-overview/1.overview/) supports:

- Graph traversals
- Aggregation
- Access control
- Composite queries
- Index

nGQ is constantly being improved and new features added to ensure the best experience for users.

## 10. A vibrant open-source community
The ever vibrant NebulaGraph community, through Nebula Contrib, boasts many contributions from members. Many tools have been contributed so far, including these that have recently been embraced:

- [NebulaGraphQL](https://github.com/nebula-contrib/NebulaGraphQL): Supports graph queries
- [nebulagraph-docker](https://github.com/nebula-contrib/nebulagraph-docker-ext): An extension that makes it possible to launch NebulaGraph Docker services in 10 seconds only.
- [testcontainers-nebula](https://github.com/nebula-contrib/testcontainers-nebula): To support  containerized testing

## Use cases for NebulaGraph

NebulaGraph is versatile in application with following use cases:

- [Fraud detection](https://www.nebula-graph.io/posts/fraud-detection-with-graph-analytics)
- [Real-time recommendation systems](https://www.nebula-graph.io/posts/use-cases-of-graph-databases-in-real-time-recommendation)
- [Social networking](https://www.nebula-graph.io/posts/social-networks-with-graph-database-1)
- [Knowledge graph](https://www.nebula-graph.io/posts/how-to-build-knowledge-graph)
- [Graph analytics and algorithms](https://docs.nebula-graph.io/3.5.0/graph-computing/nebula-analytics/)
- [Graph Embedding](https://www.nebula-graph.io/posts/graph-embeddings)
- [Artificial intelligence](https://www.nebula-graph.io/posts/graph-ai)
- [Network Security](https://www.nebula-graph.io/posts/intrusion-detection-with-graph-technology)
- [Anti money laundry](https://www.nebula-graph.io/posts/financial-fraud-detection-one-of-the-best-practices-of-knowledge-graph)

# Case Study

We have seen many users migrating from Neo4j to NebulaGraph for better operation and performance at scale. [Guotai Junan Securities](https://en.wikipedia.org/wiki/Guotai_Junan_Securities) is one of those looking for horizontal scalability, better graph inquiry and computing capabilities as well as enterprise support. Guotai Junan adopted Neo4j in 2018 for knowledge graphs for the corporation itself and industrial supply chain. However, in face of the changing business scenarios and needs, they decided to migrate to an alternative which excels at elastic capabilities of expansion and contraction. Meanwhile, as the business scenarios involve equity penetration, ultimate beneficiary as well as other business-related algorithms, the alternative needs to handle at least 10,000 API calls a day with second-level latency requirement. 

After the thorough evaluation of all the alternatives in the market, they finally chose to migrate to NebulaGraph Enterprise edition in 2023. With the successful migration, Guotai Junan Securities‘ graph platform based on NebulaGraph has a significant improvement in terms of overall performance and stability, effectively creating more value for the business development.

# Migrating from Neo4j to NebulaGraph

It's easy to [migrate data from Neo4j to NebulaGraph](https://www.nebula-graph.io/posts/how-to-import-data-from-neo4j-to-nebula-graph), thanks to NebulaGraph Exchange. This is NebulaGraph's migration tool that uses Spark to support the importation and high performance of huge datasets.

Here is an easy [guide](https://www.nebula-graph.io/posts/how-to-import-data-from-neo4j-to-nebula-graph) to help you migrate from Neo4j to NebulaGraph. Please [contact us](https://www.nebula-graph.io/contact) should you experience difficulties in understanding any part.

It's common knowledge that a good number of companies went to Neo4j for graph-related  use cases. However, at present, these companies are discovering it's no longer meeting their constantly changing needs especially on scalability and performance.

In fact, many enterprise customers of NebulaGraph confess that they made the decision because they were looking for alternatives to Neo4j and finally chose NebulaGraph.

# Conclusion
Big corporations in key industries have tested and compared NebulaGraph against Neo4j. The results have been amazing and this explains the reason a good number are migrating to Nebula Graph.

As the NebulaGraph ecosystem and community continues to grow at record speed, the team behind this powerful graph database is focussed on delivering a graph database landscape where users will spend more time deriving value as opposed to solving challenges.

Try NebulaGraph [free](https://www.nebula-graph.io/choose-a-cloud-vendor), available in both AWS and Microsoft Azure.


Explore an open-source, distributed, and fast Neo4j alternative, NebulaGraph, addressing operational and performance challenges. Discover why major companies are transitioning to NebulaGraph.

Neo4j Alternative: Open-Source, Distributed and Lightning Fast

We are thrilled to share that NebulaGraph has reached a significant milestone on our journey of empowering enterprises with stable and reliable infrastructure software! We have reached 10,000 stars on GitHub! It is not easy as only 3,400 GitHub repos have more than 10,000 stars all over the world. This achievement comes five years after our initial release, and we couldn't have done it without you.

“The graph databases that were available in the market at the time were basically either standalone versions or not highly scalable. After fully understanding the industry's demand for graph databases, and recognizing the shortcomings of existing graph database products, I began to invest in the research and development of NebulaGraph in 2018." Sherman Ye, the founder and CEO of Vesoft, said. "From the moment we wrote the first line of code for NebulaGraph, we realized that it had to be an open-source, distributed, linearly scalable, and high-performance graph database."

We want to extend a heartfelt THANK YOU to each and every one of you for your participation, contribution and support. From contributing codes and reporting bugs, to providing sincere feedback on our product, you have been instrumental in helping us reach this milestone.

![image](https://www-cdn.nebula-graph.io/blogs/star_history.png)

Since NebulaGraph’s first beta release in May 2019, We have achieved: 

- 106 contributors
- 2,599 merged pull requests
- 25 releases
- 5,000,000+ downloads
- 2,000+ enterprise users

Let’s take a look back at how we got here with top 10 milestones and what you could expect next! 🌟

Our journey commenced in October 2018, with the establishment of Vesoft to embark on the NebulaGraph project. By June 2019, we had launched the initial alpha version of NebulaGraph, turning it open-source and inviting a broader community to experiment and provide feedback. By October 2019, 360 Digital had incorporated NebulaGraph into their production, marking a significant milestone in the product's maturity.
We've seen tremendous growth since then. We held our first large annual community conference, NebulaGraph User Conference, in October 2021, to engage our community to share their experiences and expectations. In September 2022, we launched [NebulaGraph on AWS, Azure and Alibaba Cloud](https://www.nebula-graph.io/cloud), which led to rapid community growth and 1,000 enterprise users by the end of the year.
Our hard work did not go unnoticed. In August 2023, [Gartner recognized Vesoft as a trusted vendor for NebulaGraph](https://www.nebula-graph.io/posts/gartner-market-guide), a leading open-source distributed graph database renowned for its exceptional management capabilities of datasets containing hundreds of billions of vertices and trillions of edges, and DB-Engines ranked it as the top 3 graph databases worldwide since Apr 2023.
In September 2023, [we introduced "Graph RAG" with Llamindex](https://www.nebula-graph.io/posts/graph-RAG), a concept leveraging knowledge graphs and Large Language Models (LLMs) to enhance search engines' contextual understanding. And now, we've reached our most recent milestone: 10,000 GitHub stars!

![image](https://www-cdn.nebula-graph.io/blogs/10k_star_milestone.jpg)

"I am extremely proud and grateful to see 10,000 stars on GitHub," says Sherman Ye. "This represents the support from our open-source community users, which will continue to inspire and drive us to create better products for the community. The achievements of NebulaGraph today couldn't be made without the support of the community. Thank you to everyone involved in the journey."

In the days ahead, NebulaGraph is set to continue its exciting journey of innovation and growth. We are devoted to strengthening the stability and performance of NebulaGraph, making it faster, easier to use and more intuitive. Furthermore, we are broadening our suite of offerings with the development of the NebulaGraph DbaaS version and the roll-out of new features in our upcoming major releases. As we explore the possibilities of graph technology, we are committed to helping businesses harness their data's potential by providing robust infrastructure software. As always, we are grounding our work on user insights and feedback, and we are excited to have such a committed community!

In conclusion, we are incredibly thankful to our community for all the support and feedback we have received over the years! Your contributions have made NebulaGraph a battle-tested distributed scalable graph database. We are so excited about the journey ahead to empower more enterprises to unlock the relationship between hidden data, and we are looking forward to your continued support and feedback!

Here's to the next 10,000 stars! 🎉🌟


We are thrilled to share that NebulaGraph has reached a significant milestone on our journey of empowering enterprises with stable and reliable infrastructure software! We have reached 10,000 stars on GitHub!

Celebrating 10,000 GitHub Stars for NebulaGraph

As we bid farewell to another year filled with its own unique set of triumphs and trials, it's time to pause, rewind, and reflect on the journey we've navigated together. This blog post is dedicated to a comprehensive recap of the past 12 months, a year that was anything but ordinary. From the smallest improvements to the most significant milestones, we'll be revisiting the moments that made us grow. So join us as we journey back through the year in review.

# Product Refined for Upgraded Stability and Performance

Throughout the year, NebulaGraph prioritized stability as its primary focus. We introduced the innovative feature, [Memory Tracker](https://www.nebula-graph.io/posts/memory-tracker-practices), to implement fine-grained memory usage control in order to improve NebulaGraph’s kernel stability. Additionally, we undertook several rounds of comprehensive testing, incorporating tools and methods like fuzzer to give NebulaGraph a thorough "health check" to make sure its development meets our expectations. **Overall, the latest release, v3.6.0, witnessed stability improvement and performance enhancements in common graph-based queries, such as path and multi-hop queries, with the highest performance improvement reaching six-fold.** More details of the latest version are available in [**Enterprise v3.6.0 Introduction**](https://www.nebula-graph.io/posts/announcing_nebulagraph_enterprise_v3.6.0).

In addition to a more stable kernel, we have also enhanced NebulaGraph’s cloud native infra to better serve **enterprise customers** deploying NebulaGraph on Kubernetes. Check out some of the highlighted features introduced in 2023:



* Provided the NebulaAutoscaler CRD to implement [Horizontal Pod Autoscaling (HPA) ](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)for the Graph service.
* K8s scheduled backup, and restore tasks could be done within the Operator with CRD
* Supported zone management, a logical rack used to group storage Pods within a cluster, to improve the resilience of the cluster by ensuring an even distribution of data replicas across each zone. Scheduler plugins are provided to maintain an even distribution after scaling in.
* mLTS are supported to ensure secure communication between clients and Nebula Pods.
* Support for extended configurations such as init-container, sidecar-container, etc., which can be used in scenarios like log collection, service-mesh, and more.


## Adding LLM related functions to NebulaGraph tools

Several NebulaGraph tools underwent significant functional iterations in 2023, and below are some important updates you should not miss.

* Nebula Studio
    * extended to LLM related functions, such as **AI assistant** that converts natural language into query statements and **KG builder** that can realize automatically importing data into the NebulaGraph database. Based on the mentioned functions, more large model application scenarios can be derived.
    * supported displaying schema creation statements for graph space in version v3.4.0, including graph spaces, tags, edge types, and indexes.
    * adapted to the ARM architecture in version v3.7.0 and optimized the visualization of execution plans.
* Nebula Importer was refactored in version v4.0.0, significantly improving import performance and readability of import configuration files.
* Nebula Exchange supported reading HDFS configuration files in version v3.4.0, preprocessing data sources in v3.5.0, batch deletion and updates in v3.6.0, and obtaining template configuration files based on data sources in the latest v3.7.0.
* Clients, including nebula-go, nebula-java and nebula-console, have supported HTTP/2 since version v.3.6.0.

Throughout 2023, NebulaGraph has been proved to be excelling in scalability, stability and performance for enterprise customers. Industries, such as finance, social media, and e-commerce, adopted NebulaGraph due to its ability to effectively handle complex data relationships, providing insightful analysis for better decision-making. The past year has witnessed NebulaGraph's commitment to providing superior solutions and services.

As we step into 2023, we are filled with optimism and excitement for the opportunities it brings. NebulaGraph remains committed to delivering advanced, reliable and scalable graph database solutions, striving to empower our enterprise customers with the best technology to drive their business forward.

From enhancing stability with features like Memory Tracker to refining product performance with v3.6.0, we've prioritized user experience. Plus, new LLM functions in Nebula Studio! Dive into our detailed journey in 2023 here.

NebulaGraph Year in Review 2023 Part 1: Enhancing Stability, Speed, and Usability

In [Part 1](https://www.nebula-graph.io/posts/nebulagraph_year_in_review_2023_part1_snhancing_stability_speed_and_usability), we have journeyed back to all the milestones of NebulaGraph database and its ecosystem tools. In Part 2, let’s take a look at how the open-source community collaboration enables NebulaGraph to benefit more community users.

## Practical Tools Contributed by the Community

Beyond the official NebulaGraph tools, the [nebula-contrib](https://github.com/nebula-contrib) organization has embraced a variety of practical tools contributed by our community. We have seen several exciting additions this year.

* nebulagraph-docker-ext to enable NebulaGraph Docker services to be launched in just 10 seconds: [https://github.com/nebula-contrib/nebulagraph-docker-ext](https://github.com/nebula-contrib/nebulagraph-docker-ext)
* NebulaGraphQL to support GraphQL queries: [https://github.com/nebula-contrib/NebulaGraphQL](https://github.com/nebula-contrib/NebulaGraphQL)
* NebulaResultSetBoot for converting query results into JSON format: [https://github.com/nebula-contrib/NebulaResultSetBoot](https://github.com/nebula-contrib/NebulaResultSetBoot)
* zio-nebula on Scala client: [https://github.com/nebula-contrib/zio-nebula](https://github.com/nebula-contrib/zio-nebula)
* testcontainers-nebula for containerized testing: [https://github.com/nebula-contrib/testcontainers-nebula](https://github.com/nebula-contrib/testcontainers-nebula)
* Analytics for implementing PersonalizedPageRank, TrustRank, and BeliefPropagation graph algorithms based on Plato: [https://github.com/nebula-contrib/analytics](https://github.com/nebula-contrib/analytics)
* Operator-cli as the CLI tool for NebulaGraph Operator [https://github.com/nebula-contrib/operator-cli](https://github.com/nebula-contrib/operator-cli) 
* Graph-player, a visualization graph exploration tool implemented using the CoCos game engine: [https://github.com/nebula-contrib/graph-player](https://github.com/nebula-contrib/graph-player)

## Partnership with Ecosystem Projects

In addition, we have also worked closely with other open-source projects to provide users with an effortless experience.

* Apache Doris: Zhihu's technical team added the graph engine NebulaGraph to Doris, realizing integration with the graph engine based on multi-dimensional analysis and full-text retrieval. [Doris#19209](https://github.com/apache/doris/pull/19209) 
* KubeBlocks: KubeBlocks’ team completed the integration of KubeBlocks and NebulaGraph, allowing more K8s enthusiasts to have more database deployment options. [KubeBlocks#3944](https://github.com/apecloud/kubeblocks/pull/3944) and [KubeBlocks#3981](https://github.com/apecloud/kubeblocks/pull/3981)

## NebulaGraph + LLMs

Nothing can be more trending this year than Large machine learning models (LLMs). **NebulaGraph leverages its strength in handling intricate data relationships to deliver enhanced contextual comprehension. This, in turn, yields more precise and insightful outcomes. Further enriching its offerings, NebulaGraph's Graph RAG (Retrieval-Augmented Generation) combines knowledge graphs with LLMs to provide more cost-effective, intelligent, and precise search results**. In case you missed the latest updates, below are the links you could dive into.


* [NebulaGraph Launches Industry-First Graph RAG: Retrieval-Augmented Generation with LLM Based on Knowledge Graphs](https://www.nebula-graph.io/posts/graph-RAG)
* [Pioneering the New Paradigm of "Graph + AI" Applications](https://www.nebula-graph.io/posts/graph-ai)
* [How NebulaGraph database helps industry-level large language model Applications](https://www.nebula-graph.io/posts/graph-llm)
* [7 Query Strategies for Navigating Knowledge Graphs With NebulaGraph and LlamaIndex](https://www.nebula-graph.io/posts/Knowledge-Graph-and-LlamaIndex)
* [Webinar recording][Graph Databases, Knowledge Graphs, and RAG](https://youtu.be/30BiMAoP4BU)
* [Workshop] [Building RAG with Knowledge Graphs](https://youtu.be/VEvFPRlCcvI) and [Demo Outline of Graph LLM](https://colab.research.google.com/drive/1tLjOg2ZQuIClfuWrAC2LdiZHCov8oUbs)

What’s more, online community programs are one of our focuses to engage with our community all over the world. From Hacktoberfest, to [Celebrating Thanksgiving with NebulaGraph](https://www.nebula-graph.io/posts/Celebrating_Thanksgiving_with_NebulaGraph) and [Query Statements Commentary Program](https://www.nebula-graph.io/posts/nebulagraph_query_statements_commentary), we’ve seen participants join, contribute and give feedback. We are so thankful for the engagement and we look forward to more chances to communicate with all community members. The image below shows all the contributors’ headshots of NabulaGraph and total number of PRs submitted. We feel heartfelt thankful to all of you.

![image](https://www-cdn.nebula-graph.io/pic-upload/community_2023.png)

## Keep heading to a better NebulaGraph

Reflecting on the year that has passed, NebulaGraph's journey through 2023 has been marked by significant advancements and a steadfast commitment to stability and high performance. We would like to express our sincerest thanks to all our users, partners, and team members for their unwavering support and dedication. We are excited about what lies ahead and we can't wait to share our journey with you.

Here's to another year of growth, innovation, and success with NebulaGraph!

Open-source collaboration took #NebulaGraph to new heights in 2023! Community contributions, partnerships with Apache Doris & KubeBlocks, and strides in LLMs made this year unforgettable.

NebulaGraph Year in Review 2023 Part 2: Open-source Collaboration Benefits Greater and More

Many community members learn NebulaGraph's proprietary query language, nGQL, via our documentation. While [nGQL](https://docs.nebula-graph.io/3.6.0/3.ngql-guide/1.nGQL-overview/1.overview/) is a declarative, programming-style query language, its uniqueness necessitates some learning. To facilitate this, our NebulaGraph documentation provides plentiful examples for each clause, such as the `MATCH` clause usage.

```
nebula> MATCH (v) \
        WITH v, properties(v) as props, keys(properties(v)) as kk \
        WHERE [i in kk where props[i] == "Tim Duncan"] \
        RETURN v;
+----------------------------------------------------+
| v                                                  |
+----------------------------------------------------+
| ("player100" :player{age: 42, name: "Tim Duncan"}) |
+----------------------------------------------------+

nebula> WITH ['Tim Duncan', 'Yao Ming'] AS names \
        MATCH (v1:player)-->(v2:player) \
        WHERE v1.player.name in names \
        RETURN v1, v2;
+----------------------------------------------------+----------------------------------------------------------+
| v1                                                 | v2                                                       |
+----------------------------------------------------+----------------------------------------------------------+
| ("player133" :player{age: 38, name: "Yao Ming"})   | ("player114" :player{age: 39, name: "Tracy McGrady"})    |
| ("player133" :player{age: 38, name: "Yao Ming"})   | ("player144" :player{age: 47, name: "Shaquille O'Neal"}) |
| ("player100" :player{age: 42, name: "Tim Duncan"}) | ("player101" :player{age: 36, name: "Tony Parker"})      |
| ("player100" :player{age: 42, name: "Tim Duncan"}) | ("player125" :player{age: 41, name: "Manu Ginobili"})    |
+----------------------------------------------------+----------------------------------------------------------+
```
However, you might find yourself pondering over the examples: what exactly are these examples demonstrating? What's the purpose of the `WITH` clause?

In truth, while our documentation offers numerous usage examples, it lacks the explanatory notes for each statement that would make understanding their functionality much easier. This is particularly crucial for NebulaGraph novices since it helps them swiftly grasp the potential of the clauses. Therefore, we're excited to launch the community program, NebulaGraph Query Statements Commentary, with the aim of making nebula-docs more accessible with the assistance of our community members.

## Program Overview
The program encourages you to add comments to the existing NebulaGraph documentation, specifically to v3.6.0, so that the forthcoming version v3.7.0 includes your nGQL comments. The program runs until March 31, 2024.

### Efficient Commenting Process:
Instead of copying the entire documentation locally, which may be time-consuming, we recommend making page-level PR submissions directly on the individual document page. Here are the detailed steps:
- Step 1: Access the master document at: [https://docs.nebula-graph.io/3.6.0/](https://docs.nebula-graph.io/3.6.0/)
- Step 2: Identify the clause page you're familiar with and click the pencil icon in the upper right corner.
![image](https://www-cdn.nebula-graph.io/pic-upload/docs_pencil.png)
- Step 3:  Write the statement comments and start the comment with the symbol `#`.
![image](https://www-cdn.nebula-graph.io/pic-upload/add_comments.png)
- Step 4: After modifying a single statement, provide a summary of the changes and submit your PR.

The next step is to wait for the nebula-docs maintainers to review and merge your PR.

### Claim Your PR Rewards
#### Contributor SWAG pack
If you're a first-time PR submitter to NebulaGraph and your comment PR has been merged, you automatically become a NebulaGraph contributor. As a contributor, you'll receive a  certificate with your unique contributor number, a commemorative contributor mug and a limited edition Nebula Rabbit!

![image](https://discuss.nebula-graph.com.cn/uploads/default/original/3X/5/2/52dfa98cfa8f922ef7aeac47d92701097418cd91.jpeg)
![image](https://discuss.nebula-graph.com.cn/uploads/default/original/3X/d/a/da74c6c5e1b11e13211a3f3a3d57d9b708402430.jpeg)

#### Special SWAGs for Top 3 Commenters
The top 3 participants who contribute the most comments (with corresponding merged PRs) will also receive an nStar hoodie and a backpack!
![image](https://discuss.nebula-graph.com.cn/uploads/default/original/3X/5/7/57e4539e4339e1427abf9ef5c0e25dd9838b22aa.jpeg)

![image](https://www-cdn.nebula-graph.io/pic-upload/nebula_hoodie.jpeg)
Get started now!



We're excited to launch the community program, NebulaGraph Query Statements Commentary, with the aim of making nebula-docs more accessible with the assistance of our community members.

NebulaGraph Query Statements Commentary: to Enhance nGQL's Usability

Happy Thanksgiving! We know it's a bit early to kick off the festivities, but we can't wait to share our heartfelt gratitude and blessings with you!

![image](https://www-cdn.nebula-graph.io/pic-upload/Banner-Thanksgiving05.jpg)

This year marks 5th anniversary of NebulaGraph. With your support and contribution, NebulaGraph has made fantastic growth on its maturity and performance. More than ever, we've seen our community flourish with new members exploring the capabilities of NebulaGraph, sharing their unique use cases and best practices. And even better, many have even contributed codes to NebulaGraph, driven by passion and dedication. We can't be more grateful to all your support, contribution and commitment. As a token of gratitude, we are excited to launch the program "Celebrating Thanksgiving with NebulaGraph", inviting all community members to celebrate our collective achievements and blessings from our journey so far.

![image](https://www-cdn.nebula-graph.io/pic-upload/github_contributor.png)

The program will last until Nov 30 and below are the instructions of the program. Remember, what we are thankful the most is always **YOU**!

- **Claim Your NebulaGraph Graph Pioneer Badge**

Complete the [NebulaGraph Thanksgiving Quiz](https://forms.gle/L9Ud7CzHDXvhyXVp6) (10 questions). Anyone who gets 60 points will receive the NebulaGraph Graph Pioneer Badge.

![image](https://www-cdn.nebula-graph.io/pic-upload/Badge-NebulaGraph-pioneer.png)

⭐️ A tip: Adding NebulaGraph to your LinkedIn skills, or sharing the badge on social media, will earn you an additional set of Digital Stickers! Don't forget to **@NebulaGraph** when you're posting.

- **Tell Us What We Can Optimize**

Fill out the [survey](https://forms.gle/zSezFKLiApvRYDZ58) to rate NebulaGraph features and performance! Shouting out where NebulaGraph can improve will award you a NebulaGraph Product Champion Badge!

⭐️ A tip: Sharing your unique experience with NebulaGraph will stand you a chance to win a $50 Amazon gift card!

![image](https://www-cdn.nebula-graph.io/pic-upload/Badge-NebulaGraph-champion.png)

The Story Acceptance Criteria
- Theme: The article must be factual and related to the NebulaGraph database, and contains no unrelated content.
- Type: We welcome best practices, selection journey, performance tuning, and similar topics.
- Content: The story should be well-structured, logically clear, and well-written. The inclusion of diagrams and charts is encouraged where appropriate.
- Word count: Over 800 words.
Shoot an email with the subject of "Celebrating Thanksgiving with NebulaGraph" to devrel@vesoft.com; we will surely get back to you soon!

*Note: NebulaGraph reserves the right to use all stories submitted through this program and may share them across public accounts and other content channels. However, the original author will retain the copyright of the story.*

- **A Special SWAG Pack for Contributors**

If you're already a NebulaGraph contributor and have had a Pull Request (PR) merged, you're eligible to receive a contributor badge and a physical SWAG pack! Please paste the link to your personal GitHub profile page or the link to the PR merged [here](https://forms.gle/Lsf4PrUpxHCocvNJ9), we will reach out to you soon!

Are you excited about the program? Join us to celebrate! 🎉


We're excited to launch the program Celebrating Thanksgiving with NebulaGraph, inviting all community members to celebrate our collective achievements and blessings from our journey so far.

Celebrating Thanksgiving with NebulaGraph

Author: Aqi, a developer at Arch team of [SMY Cloud](https://www.smycloud.com/)

Aqi is a community member of NebulaGraph who has done system refactoring many times. According to Aqi, migrating from OrientDB to NebulaGraph might be the most difficult one and below he shares the journey of the migration.

# The Reason for Migration

OrientDB was plagued by performance bottlenecks and single-point issues. In addition, the legacy system's tech stack couldn't support elastic scaling, and its monitoring and alerting facilities were inadequate. Thus, upgrading to NebulaGraph became a necessity.

*I will detail the specific pain points we encountered in a subsequent article, so I won't elaborate further here.*

## Migration Challenges Identified

* Complexity and contextual vagueness: the system was developed on OrientDB back in 2016, which is quite dated. Plus, we have no clue of the historical backgrounds of the system building.
* An uncharted territory of business: the requests from the Big Data team were passed onto us in a sudden, and we hadn't been involved in this aspect of the business before.
* Unfamiliar technology stack: it was our first touch with graph databases: a concept foreign to the entire team. We had no previous experience with both OrientDB and NebulaGraph, and most of the legacy system was written in Scala. Additionally, it used HBase, Spark, Kafka, all of which were relatively unknown to us.
* Time urgency: we were asked to complete the refactoring within 2 months  ;apparently, we were racing against time.

All the challenges above tell that we were in unfamiliar waters with both the business and the technology stack.
# The Technical Blueprint

## Research Undertaken

Given our unfamiliarity with the business, what research we had done to step in the situation?

* External Interface Review: We examined all external interfaces of the system, which included the interface name, its use, request volume QPS, average consumption time, and caller (services and IP).
* Core Workflow Review: We created an architectural diagram of the legacy system, and flowcharts for the important interfaces (approximately 10).
* Environment Review: We identified the projects that needed modifications, application deployments, MySQL, Redis, HBase cluster IPs, and sorted out the current online deployment branches.
* Trigger Scenarios: We determined how the interfaces were triggered by which business scenario, ensuring each interface was covered by at least one scenario. This would further support future functionality verification.
* Transformation Plan: We carried out feasibility analyses for each interface, planning how to transform them (changing OrientDB statements into NebulaGraph query statements), and how to revamp the graphing (writing process).
* New System Design: We created an architectural diagram and core process diagram for the new system.
## Project Target Aligned

Our target was to transition the data source of the [graph database](https://www.nebula-graph.io) from OrientDB to NebulaGraph, refactor the legacy system to a unified Java tech stack, and support horizontal service scalability.

# Overall Solution Confirmed

We adopted a fairly aggressive approach as the solution was designed to be a 'once and for all' fix to facilitate future maintenance:

* Rewrite the underlying legacy system (starting at the interface entry point), ensuring the impact was manageable.
* Unify the Java tech stack and integrate with the company's unified service framework to enhance monitoring and maintenance.
* Make clear boundaries of the basic graph database application to simplify future integrations with the graph database for upper-layer applications.

*Note: The diagram was created during the research phase; the detailed one won’t be illustrated as it pertains to business specifics.*

# Project Phase Plan

Manpower invested: 4 developers, 1 QA developer

The main items and their duration are as follows:

![image](https://www-cdn.nebula-graph.io/pic-upload/project_plan.png)


# Grayscale Plan Designed

![image](https://github.com/vesoft-inc/nebula/assets/38887077/b8ecf799-de0b-4262-a9eb-05cb0d99b83e)

## Overall Strategy

* Write Requests: We employed synchronous dual writing.
* Read Requests: We gradually migrated traffic from smaller to larger volumes, ensuring a smooth transition.

## Grayscale Phases

|Phase|1|2|3|4|5|6|7|
|:----|:----|:----|:----|:----|:----|:----|:----|
|Volume|0%|1‰|1%|10%|20%|50%|100%|
|Number of grayscale days|2|2|2|5|2|2|-|
|Important node description|Synchronous dual writing, traffic playback sampling and comparison until 100% passed; |    |    |Pressure test required in this phase |    |    |    |

Notes:

* We used a configuration center switch for control, allowing us to switch back at any moment if issues arose, with recovery in seconds.
* Missed read interfaces had no impact on the project, only changes would have an effect.
* We used parameter hash values as keys to ensure consistency in results for multiple requests with the same parameters. A hit in grayscale was confirmed if abs(key) % 1000 < X (0< X < 1000, X is dynamically configured).

A side note: When refactoring, the most crucial part is the grayscale plan. Our grayscale plan this time could be regarded as a well-designed one: before the volume increase in grayscale phase, we used real-time online traffic to asynchronously compare data. Only after the comparison passed successfully did we proceed with the volume. This comparison phase took much longer than expected (in reality, it took 2 weeks and we discovered many issues).

# Data Comparison Plan Settled

## Missed grayscale data

The process for missing grayscale is as follows:

![image](https://github.com/vesoft-inc/nebula/assets/38887077/95fa106b-dd38-4807-83e1-6123d65690f7)

We started with the old system to see whether the sample was hit (sample ratio configuration 0% ~ 100%). If the sample was hit, the message queue (MQ) would be sent and dealt with within the new system. The new system interface would be requested and the data returned by the old system would be compared in JSON format. If the data matches, then the comparison would succeed. On the contrary, if the comparison is inconsistent, a notification would be sent in real time.

The same is true in reverse!!

# Data Migration Plan Designed

* Full data (historical data): We wrote scripts for full migration: if inconsistency happens during the launch period, the data for the past 3 days which was stored in MQ would be consumed 
* Incremental: Synchronous dual-write (there are few write interfaces, and the write request QPS is not high)
## Transformation - Taking Subgraph Query as an Example

Before the transformation:

```plain
@Override
    public MSubGraphReceive getSubGraph(MSubGraphSend subGraphSend) {
        logger.info("-----start getSubGraph------(" + subGraphSend.toString() + ")");
        MSubGraphReceive r = (MSubGraphReceive) akkaClient.sendMessage(subGraphSend, 30);
        logger.info("-----end getSubGraph:");
        return r;
    }
```
After the transformation:

Define the gray service module interface

```plain
public interface IGrayService {
    /**
     * Whether to hit the gray service configuration value 0 ~ 1000; true: hit, false: miss
     * @param hashCode
     * @return
     */
    public boolean hit(Integer hashCode);

    /**
     * Whether to sample; configuration value 0 ~ 100
     *
     * @return
     */
    public boolean hitSample();

    /**
     * Send request-response data
     * @param requestDTO
     */
    public void sendReqMsg(MessageRequestDTO requestDTO);

    /**
     * @param methodKeyEnum
     * @return
     */
    public boolean hitSample(MethodKeyEnum methodKeyEnum);
}
```

The interface transformation is as follows, the kgpCoreService sends requests to the new system, the interface business logic remains consistent with old system, and the underlying graph database is changed to query NebulaGraph:

```plain
@Override
    public MSubGraphReceive getSubGraph(MSubGraphSend subGraphSend) {
        logger.info("-----start getSubGraph------(" + subGraphSend.toString() + ")");
        long start = System.currentTimeMillis();
        //1. Request grayscale
        boolean hit = grayService.hit(HashUtils.getHashCode(subGraphSend));
        MSubGraphReceive r;
        if (hit) {
            //2、Hit Grayscale and go through the new process
            r = kgpCoreService.getSubGraph(subGraphSend); // Use Dubbo to call new services
        } else {
            //Here is the original process using akka communication
            r = (MSubGraphReceive) akkaClient.sendMessage(subGraphSend, 30);
        }
        long requestTime = System.currentTimeMillis() - start;

        //3.Sampling hits Sending data compared to MQ
        if (grayService.hitSample(MethodKeyEnum.getSubGraph_subGraphSend)) {
            MessageRequestDTO requestDTO = new MessageRequestDTO.Builder()
                    .req(JSON.toJSONString(subGraphSend))
                    .res(JSON.toJSONString(r))
                    .requestTime(requestTime)
                    .methodKey(MethodKeyEnum.getSubGraph_subGraphSend)
                    .isGray(hit).build();
            grayService.sendReqMsg(requestDTO);
        }
        logger.info("-----end getSubGraph: {} ms", requestTime);
        return r;
    }
```

# Benefits of Refactoring

After two months of hard work by the team, the grayscale plan has been successfully completed, with the following benefits:

* NebulaGraph itself supports distributed expansion; the new system service supports elastic scaling, and the overall performance supports horizontal expansion;
* From the pressure test results, the performance of the interface has improved significantly, and it can support requests far beyond expectations;
* It was integrated with the company's unified monitoring and alarm system, which is more conducive to later maintenance.

# Conclusion

The refactoring was successfully completed, thanks to the partners who participated in this project, as well as the support from the big data and risk control teams. At the same time, we also thank the [NebulaGraph community](https://github.com/vesoft-inc/nebula/discussions) because they quickly helped troubleshoot some of the issues we encountered.


Aqi, a NebulaGraph community member shares his journey of refactoring the graph database from OrientDB to NebulaGraph. 

The Journey of Refactoring Graph Database: Migrating from OrientDB to NebulaGraph


![NebulaGraph v2.0 GA Overview](https://user-images.githubusercontent.com/57335825/112122642-74f1fc00-8bfb-11eb-977f-557baf66990f.png)

We have seen more and more users trying to adopt the graph technology since the general availability of NebulaGraph 1.0 in June 2020. The development of NebulaGraph 2.0 was brought to the table not long after the initial release as the Nebula team have collected many problems and feature requests from our developers’ community. Following hard work for nearly one year and several beta versions, NebulaGraph 2.0 is now generally available and can be used in production as a stable version.

# Version Planning

The Nebula team has taken into consideration the following factors when planning what should be included in version 2.0:

- Suggestions and feature requests from current adopters
- Trends in the graph database and big data industry
- Feedback from the community

Finally, the team has made the decision that the development of NebulaGraph 2.0 should focus on the following aspects:

**Better query performance**. High throughput and low latency in handling large data volume is the natural architectural advantage of NebulaGraph. Most users turned to NebulaGraph because other products cannot meet the challenges brought by the growth of their data volume. Therefore, NebulaGraph 2.0 continues to maintain its advantage in large data volume query scenarios.

**Stability is guaranteed**. As more and more users use NebulaGraph in production, any slight system jitter will have a huge impact on their businesses. NebulaGraph always ensures users’ clusters in stable operations as their businesses evolve and data volume increases.

**Enhanced system openness**. NebulaGraph 2.0 added several important features and its underlying logic was optimized to make the system more open. NebulaGraph is now compatible with openCypher so that Neo4j users can use NebulaGraph with a flat learning curve. It can also integrate with more graph analysis algorithms to meet users' needs for offline analysis and graph computing.

**Easier operation and maintenance**. The complexity of operation and maintenance of distributed databases is incomparable to that of standalone ones. NebulaGraph 2.0 now provides users with more operation and maintenance tools to simplify deployment, upgrade, backup, and enable them to monitor the system and locate errors more accurately and faster.

Based on the above-mentioned principles, the team restructured and optimized NebulaGraph, trying to make it a reliable and user-friendly graph database. While some of the changes are visible to users such as better performance and easier operation, some are under the hood and are the building blocks of a more reliable and performant distributed system.

# Performance Improvement

In NebulaGraph 2.0, the data type has been unified across all subsystems such as Storage, Graph, and Client, which can significantly reduce the data type conversion between subsystems or submodules, as well as serialization and deserialization.

In the meantime, the query engine of NebulaGraph 2.0 has been restructured to introduce multiple modules such as syntax analysis, statement optimization and resource scheduling. With syntax analysis, illegal statements can be ended before being passed for further processing, which reduces unnecessary resource consumption and provides users with more readable error information. In NebulaGraph 1.0, the query statements are processed by an independent executor, which significantly limits us from optimizing query execution in the system. Therefore, in NebulaGraph 2.0, we made reasonable abstraction to computation actions in query execution and designed multiple operators. In this way, a query statement can be split into an execution plan consisting of multiple operators and can be optimized via RBO (Rule Based Optimization).  We will continue optimizing the operators and the execution plan in the future for better performance.

We have also redesigned the Scheduler to better allocate resources for execution plans.

# Stability Enhancement

We have done a huge amount of work to guarantee the stability of NebulaGraph 2.0. We have built a new testing framework at the query engine level, including unit testing, integration testing, and performance test. The integration testing framework based on BDD helps us verify integration use cases fast and significantly reduces the difficulty of use case writing. The performance testing framework based on Jmeter is now functioning. The current version can help us verify performance issues quickly. A sound testing framework ensures the stability of the entire system. We have enhanced the chaos testing framework in NebulaGraph 2.0  to ensure the reliability and stability of the storage engine.

# System Openness

In NebulaGraph 2.0, the previous Executor module has been split into multiple independent modules for better encapsulation and testing. The current query engine consists of Parser, Validator, Optimizer, Executor, and Scheduler. The new architecture not only makes NebulaGraph easier for maintenance, but also allows more openness to external feature requests.

In the past year, we have re-written most of the query engine code, making it compatible with both nGQL 1.0 and openCypher. At the same time, we are trying our best to reuse the execution mechanism and code for both nGQL and openCypher compatibility. In Validator, we have enhanced syntax verification so that errors that are captured during execution can be caught during compiling. The Optimizer has partially realized RBO, which makes adding rules to the existing framework easier. Besides, we have re-written the Executor based on asynchronous calling mechanism so that it can focus on computing and aggregating. Tasks like error handling, status saving and task scheduling are all transferred to the execution framework. The query engine is more module based and more open to extension, further reducing the threshold of community participation.

In NebulaGraph 2.0, we also added some built-in algorithms such as shortest path, full path and subgraph. We have also added a lot of scalar functions, aggregate functions, and tabulated functions. NebulaGraph now supports the “string” type vertex ID and NULL, which allow users to express more conveniently. Besides, we have implemented lots of modification and optimization at the storage engine level. The full-text indexing feature has been realized by connecting Elasticsearch with the learner role in RAFT. The multi-site high availability feature has been realized by abstracting Zone and Group in partition. Redesigning the index implementation has significantly improved data import performance with indexes. The above work has laid a solid foundation for continuous improvement of NebulaGraph for the goal of "More stable, Faster, Stronger" in the next year.

# Easy Operation & Maintenance

In terms of operation & maintenance, NebulaGraph 2.0 supports the deployment of Helm Charts. In this way, users can deploy a NebulaGraph cluster with a few simple Helm commands. Meanwhile, since inner components are able to communicate with each other via domain addresses, configuration can be simplified and users only need to provide enough nodes according to their business needs. We have provided a tool for automatic upgrade to help existing users easily migrate from other versions to NebulaGraph 2.0. We are also intensively developing Backup & Restore tools, and the Dashboard feature.

For a detailed release note, please check: [https://nebula-graph.io/posts/nebula-graph-v2.0-ga-release-note/](https://nebula-graph.io/posts/nebula-graph-v2.0-ga-release-note/)

Here is the GitHub repo for NebulaGraph 2.0: [https://github.com/vesoft-inc/nebula-graph](https://github.com/vesoft-inc/nebula-graph). Give it a try! And here is the comprehensive documentation for your reference: [https://docs.nebula-graph.io/2.0/](https://docs.nebula-graph.io/2.0/). 

If you encounter any problem, head to our discussions for help: [discussions](https://github.com/vesoft-inc/nebula/discussions). Or you can join the [Slack](https://community-chat.nebula-graph.io/) channel for discussion.


Following hard work for nearly one year and several beta versions, NebulaGraph 2.0 is now generally available and can be used in production as a stable version.

NebulaGraph v2.0 GA Overview


![Pick of the Week](https://user-images.githubusercontent.com/57335825/87520320-a4e20c00-c637-11ea-8053-7222b9c4f00a.png)

Normally the weekly issue covers NebulaGraph Updates and Community Q&As. If something major happens, it will also be covered in the additional Events of the Week section.

# Events of the Week

1. NebulaGraph v2.0.0-beta release note

NebulaGraph V2.0.0-beta has been released. This release supports full-text indexing, data statistics, and other new features. Also, NebulaGraph Studio and Go Importer now support NebulaGraph 2.x versions.

![NebulaGraph v2.0.0-beta release note](https://user-images.githubusercontent.com/57335825/102967835-c2dc6280-452d-11eb-80a1-ddf18b73308a.png)

To get more information, please read the [release note](https://discuss.nebula-graph.io/t/nebula-graph-v2-0-0-beta-release-note/793).

2. DB-Engines Ranking Has Been Updated

NebulaGraph has risen 3 places and jumped to #15 in the latest DB-Engines ranking.

![DB-Engines Ranking](https://user-images.githubusercontent.com/57335825/102968155-544bd480-452e-11eb-9d42-edc33955b78e.png)

# NebulaGraph Updates

The updates of Nebula in the last week:

- Supports the DeleteRange operation in RocksDB to greatly improves the efficiency of edge deletion. Tags: `Version 1.x`, `Optimization`. For more information, see [PR#2404](https://github.com/vesoft-inc/nebula/pull/2404).

- Fixed the issue where using `FETCH PROP ON` on timestamp properties outputs int64 results. Tags: `Version 1.x`, `bug fix`. For more information, see [PR#2389](https://github.com/vesoft-inc/nebula/pull/2332).

# Community Q&A

This week's topic is from community user @panda about schema design in NebulaGraph.

## Spark Writer Configuration Suggestions

Before using Spark Write to import data, we need to configure `application.conf`.

**@panda**: I am not familiar with graph databases. I used to use MySQL and MongoDB. Now I am having some trouble designing schemas in NebulaGraph.
Suppose we have the following schema (written in GraphQL for convenience):

```shell
// User list
type User {
    name: String,
    followings: [User],
    followers: [User],
    posts: [Post],
    topics: [Topic]
}
// Topic list
type Topic {
    name: String,
    description: String,
    user: User,
    members: [Member]
    posts: [User]
}
// Post list
type Post {
    text: String,
    member: Member,
    topic: Topic
}
// Topic member list
type Member {
    user: User,
    topic: Topic,
    name: String,
    level: Int,
    join_date: DateTime,
    posts: [Post],
}
```

If we design a schema in NebulaGraph based on the preceding data, since there is no concept of table association and we cannot set the associated fields, what is the right way to do this?

Can we retrieve the required scalar and associated fields all at once? Please advise.

Now we are using NebulaGraph v2.x.

**NebulaGraph**: You can set associated fields as edges in NebulaGraph. For example, the `followings` field indicates that a user follows another user, i.e., `User—following—>User`. So you can set the `following` field as an edge type, and insert edges (relationships) of this type to connect the vertices representing the users.

**@panda**: I know these concepts, but this is not what I'm asking. Here are what really puzzle me:

1. Tags and edges are separated and have no strong correlation, then how should we query them? Take the preceding data for example, if we want to find all the data in the post list, shall we search for the tags first, and then search for the edges one by one? Do we need to do this for all the queries?
And so does writing data? It feels super troublesome.
2. Some edges are shared by multiple tags, for example, the `user: User` edge mentioned earlier is used by both Topic and Member. Wouldn't this mess up the data? And how to distinguish them? We don't want to use other names to create new edges.
3. Associated fields usually have a one-to-one association, such as the `user: User` edge mentioned earlier, one-to-many association, such as the followings: [User] edge, and many-to-many association. How are these associations represented in NebulaGraph?
4. For associated lists, we usually need to count the quantity, normally by aggregating the queries or setting a count field alone to hold the quantity. In NebulaGraph,  is there a proper way to handle this? Do we set a count property on edges? For example `CREATE EDGE followings(count int default 0);`?

The official documents are too term-based. They are not based on actual scenes and cases, and many things are not explained in detail, which makes them difficult to understand.

If possible, please make a best practice document based on the preceding schema and introduce how to query and write data in such a case.
 
**NebulaGraph**: First of all, thank you for the scenario you provided. You can require the document from our technical writers.

Let's summarize your scenario as follows:

![schema design](https://user-images.githubusercontent.com/57335825/102968684-4b0f3780-452f-11eb-87bc-045f24fa3b95.png)

> Tags and edges are separated and have no strong correlation, then how should we query them? Take the preceding data for example, if we want to find all the data in the post list, shall we search for the tags first, and then search for the edges one by one? Do we need to do this for all the queries?

And so does writing data? It feels super troublesome.

For now, the scanning by tag feature is not ready, but it will be in the future in MATCH. For example, `MATCH(p:post) RETURN p`. Scanning by tag relies on indexes and will be quite memory-consuming. If the data volume is large, OOM may happen frequently.

To write data, simply set the properties according to the post, and no other operation is needed.

> Some edges are shared by multiple tags, for example, the `user: User` edge mentioned earlier is used by both Topic and Member. Wouldn't this mess up the data? And how to distinguish them? We don't want to use other names to create new edges.

You might have confused tags with vertices. I suggest that you read [Nebula Concepts](https://docs.nebula-graph.io) first. In fact, there is no such thing as an edge shared by different vertices. Edge IDs consist of the source vertex ID and destination vertex ID. An edge is unique if the vertices on both ends of it, its edge type, and its rank are distinct. Any difference in these attributes generates different edges. Different edges may have the same edge type, but their vertices are usually different. Even if their vertices are the same, if their ranks are different, they are different edges.
 
For example, the edge type between `user` and `topic` may be `focus`, and that between `user` and `member` may be `is`.

> Associated fields usually have a one-to-one association, such as the `user: User` edge mentioned earlier, one-to-many association, such as the `followings: [User]` edge, and many-to-many association. How are these associations represented in NebulaGraph?

Please refer to the preceding reply. In NebulaGraph tags and edges don't have direct relationships, but vertices and edges do. Tags are attached on vertices, and vertices are connected with edges. So no matter it is a one-to-one association or an N-to-N one, it is represented by edges.

> For associated lists, we usually need to count the quantity, normally by aggregating the queries or setting a count field alone to hold the quantity. In NebulaGraph, is there a proper way to handle this? Do we set a `count` property on edges? For example `CREATE EDGE followings(count int default 0);`?

nGQL supports [](https://docs.nebula-graph.io) such as `COUNT` and you don't need to set a count property for counting.

# Previous Pick of the Week

1. [Compiling NebulaGraph with ARM64](https://nebula-graph.io/posts/nebula-graph-pick-of-the-week-nov-27-2020/)
2. [NebulaGraph Studio V1.2.1-beta Has Been Released](https://nebula-graph.io/posts/nebula-graph-pick-of-the-week-nov-6-2020/)

In this weekly issue, we will share the release note of NebulaGraph v2.0.0-beta, the latest DB-Engines ranking for graph DBMS, and the best practice to design schema in NebulaGraph.

Pick of the Week at NebulaGraph - Schema design in NebulaGraph


![Pick of the Week](https://user-images.githubusercontent.com/57335825/87520320-a4e20c00-c637-11ea-8053-7222b9c4f00a.png)

Normally the weekly issue covers NebulaGraph Updates and Community Q&As. If something major happens, it will also be covered in the additional Events of the Week section.

The 48th Friday of 2020 is passing soon. Let's see what's new with NebulaGraph.

# Events of the week

- [NebulaGraph Studio v2.0.0-alpha Release Note](https://discuss.nebula-graph.io/t/nebula-graph-studio-v2-0-0-alpha-release-note/787).

NebulaGraph Studio v2.0.0-alpha supports querying and exploring data with NebulaGraph v2.0.0 alpha.
At the time, data importing and schema indexing is not compatible. We will support these functions in the follow-up releases soon. Please go to the [nebula-web-docker v2](https://github.com/vesoft-inc/nebula-web-docker) directory to try NebulaGraph Studio v2.0.0-alpha.

![NebulaGraph Studio v2.0.0-alpha](https://user-images.githubusercontent.com/57335825/100973399-57cfdb00-34ef-11eb-9c12-262e4922cac1.png)

# NebulaGraph Updates

- `FIND PATH` supports finding the outgoing, incoming, and bi-direct paths. It also supports removing the ring path. Tag: `nGQL`. PR: [https://github.com/vesoft-inc/nebula/pull/2398](https://github.com/vesoft-inc/nebula/pull/2398)
- Supports compiling NebulaGraph on ARM64. Tag: `Compiling`. PR: [https://github.com/vesoft-inc/nebula/pull/2392](https://github.com/vesoft-inc/nebula/pull/2392)

# Community Q&A

This week's topic is from community user @xrfinbj  about the relationship between Exchange and Spark Writer.

**Question:** What is the relationship between Exchange and Spark Writer?

> The code for Spark Writer is held in `nebula/src/tools/spark-sstfile-generator`. Spark Writer is a distributed data importing tool for NebulaGraph based on Spark. It converts data from various data warehouses into graph data, i.e. vertices and edges, then imports them into graph databases in batches.

> The code for Exchange is held in `nebula-java/tools/exchange`. NebulaGraph Exchange (Exchange for short) is an Apache Spark™ application used to migrate data in a cluster to NebulaGraph in a distributed environment. It supports migrating various batch data and streaming data.

> For more information, see [Import Data to NebulaGraph with Spark](https://nebula-graph.io/posts/best-practices-import-data-spark-nebula-graph/).

**NebulaGraph:** Exchange is migrated from Spark Writer and provides richer data sources based on Spark Writer, such as MySQL, Neo4j, Hive, HBase, Kafka, and Pulsar.

Fixed some problems of Exchange. For example, by default Exchange reads source data from HDFS as strings, which may be different from your graph schema defined in NebulaGraph. Exchange supports automatically matching and converting data types. With it, when a non-string data type is defined in NebulaGraph, Exchange converts the strings into data of the required data type. We will put main efforts on Exchange in the future. If you're using Spark, we suggest you using Exchange to import data.

One thing to add, the TODOs in document means the document is not done but Exchange actually provides the functions. If you're migrating data from other data sources with Exchange, refer to the [Neo4j](https://nebula-graph.io/posts/how-to-import-data-from-neo4j-to-nebula-graph/) example.

# Recommendations for You

[Import Data to NebulaGraph with Spark](https://nebula-graph.io/posts/best-practices-import-data-spark-nebula-graph/)
Starting from Spark, the writer shares some practice on indexes, cluster conflict packages.

## Previous Pick of the Week

- [Pick of the Week at NebulaGraph - NebulaGraph Studio V1.2.1-beta Has Been Released](https://nebula-graph.io/posts/nebula-graph-pick-of-the-week-nov-6-2020/)
- [Pick of the Week at NebulaGraph - vesoft Inc. Named one of the 20 Fastest-Growing OSS Startups](https://nebula-graph.io/posts/nebula-graph-pick-of-the-week-oct-23-2020/)

In this weekly issue, we are covering that NebulaGraph Studio v2.0.0-alpha supports querying and exploring data with NebulaGraph v2.0.0 alpha, compiling NebulaGraph on ARM64, and what is the difference between Nebula Exchange and Spark Writer.

Pick of the Week at NebulaGraph - Compiling NebulaGraph with ARM64


![Pick of the Week](https://user-images.githubusercontent.com/57335825/87520320-a4e20c00-c637-11ea-8053-7222b9c4f00a.png)

Normally the weekly issue covers NebulaGraph Updates and Community Q&As. If something major happens, it will also be covered in the additional Events of the Week section.

The 45th Friday of 2020 is passing soon. Let's see what's new with Graph Databases and NebulaGraph.

# Events of the week

- [NebulaGraph v2.0.0-alpha has been released](https://discuss.nebula-graph.com.cn/t/topic/1631).

This release provides more data types and enhances the expression ability of nGQL. NebulaGraph 2.x will gradually become openCypher compatible.

![NebulaGraph v2.0.0-alpha has been released](https://user-images.githubusercontent.com/57335825/100068343-3fbfd380-2dec-11eb-8eea-5e93d445c21a.png)

- [DB-Engines Ranking of Graph DBMS](https://db-engines.com/en/ranking/graph+dbms)

![DB-Engines Ranking of Graph DBMS](https://user-images.githubusercontent.com/57335825/100068211-143ce900-2dec-11eb-9470-50cb96cfb442.png)

NebulaGraph remains unchanged in the November ranking, but the score is getting pretty close to the previous two databases.

# NebulaGraph Updates

[NebulaGraph Studio V1.2.1-beta has been released](https://discuss.nebula-graph.io/t/nebula-graph-v2-0-0-alpha-release-note/754).

1. Now you can import edge types and use aliases to specify edges with the **Open in Explore** function.
1. Studio can now visualize the query results of `Find Path` statements.

 
# Community Q&A

This week's topic is from community user @85278161 about using NebulaGraph as the independent database of an online B2C mall.

**Question:** Online B2C malls use ACID databases such as MySQL and TiDB for the recommendation system, but multi-table queries can be very slow.

1. Can we use NebulaGraph independently as the database of an online B2C mall?
1. How can we use NebulaGraph together with TiDB or MySQL, while NebulaGraph functions as a database for querying relationship graphs?

**NebulaGraph:** Using relational databases and graph databases together in recommendation systems is a common technology stack. For example, you can link order numbers and phone numbers with edges in NebulaGraph and make associated queries. Whenever an order is stored in the relational database, the related vertices and edges in NebulaGraph are updated accordingly.

As for the details, it depends on what you want to recommend. Data modeling is always the key.

**Follow-up question:** Thank you. How to synchronize operations such as insertion, modification, and deletion from relational databases to NebulaGraph? Shall we perform the operations on both databases simultaneously from the server, or use some functions of the relational databases, such as logs or subscription in MySQL?

**NebulaGraph**: From the system design perspective, using subscriptions are certainly better than inserting data directly in the business layer. The former method decouples the modules from each other more, and the system can be more stable. Even if the recommendation has a problem, it will not affect the transaction. This may slightly affect the real-time performance of the data recommendation, but it should be acceptable.

# Recommendations for You

[Benchmarking the Mainstream Open Source Distributed Graph Databases](https://nebula-graph.io/posts/benchmarking-mainstraim-graph-databases-dgraph-nebula-graph-janusgraph/)
The Meituan team must select a graph database solution that can meet the business requirements and to use the solution as the basis of Meituan's graph storage and graph learning platform. In this post, the Meituan NLP team evaluated several mainstream graph databases on data import, data writing, and data query.

## Previous Pick of the Week

- [Pick of the Week at NebulaGraph - vesoft Inc. named one of the 20 Fastest-Growing OSS Startups](https://nebula-graph.io/posts/nebula-graph-pick-of-the-week-oct-23-2020/)
- [Pick of the Week at NebulaGraph - Configuration recommendations for data import](https://nebula-graph.io/posts/nebula-graph-pick-of-the-week-sept-18-2020/)

In this weekly issue, we are the release note of the NebulaGraph v2.0.0-alpha, the DB-Engines graph database ranking update in November, the question of using NebulaGraph as the independent database of an online B2C mall.

Pick of the Week at NebulaGraph - NebulaGraph Studio V1.2.1-beta Has Been Released


![Pick of the Week](https://user-images.githubusercontent.com/57335825/87520320-a4e20c00-c637-11ea-8053-7222b9c4f00a.png)

Normally the weekly issue covers NebulaGraph Updates and Community Q&As. If something major happens, it will also be covered in the additional Events of the Week section.

# Events of the Week

1. Runa Capital, an early-stage investor of Nginx and MariaDB, released the Top 20 fastest-growing open-source startups in Q3 2020

![OSS Rankings from Runa Capital](https://user-images.githubusercontent.com/57335825/97271396-bc5f9200-17ed-11eb-8baa-4108bdd9188a.png)

This list measures the GitHub star growth of each open-source project in Q3, 2020. And vesoft Inc., the creator of the NebulaGraph database, ranked the eighth with 4.5K stars (total stars of the NebulaGraph repository on GitHub as of 22/10/2020) and 351% AGR (Annualised Growth Rate in Q3, 2020). For more information, please read the Medium report: [https://medium.com/runacapital/open-source-growth-benchmarks-extention-the-ross-index-and-the-fastest-growing-startups-in-q3-2020-7aee7fa7eed7](https://medium.com/runacapital/open-source-growth-benchmarks-extention-the-ross-index-and-the-fastest-growing-startups-in-q3-2020-7aee7fa7eed7)

2. October: DB-Engines Ranking for Graph DBMS

During the last month, no big changes happened to the Top 10 ranking of Graph DBMS. However, NebulaGraph is still advancing, now ranking at the 18th.

![DB-Engines Ranking - October](https://user-images.githubusercontent.com/57335825/97271582-faf54c80-17ed-11eb-8e3f-5565d99bdda9.png)

# NebulaGraph Updates

## NebulaGraph Studio v1.2.0-beta was released

In this update, NebulaGraph Studio is furnished with a new feature: visualized schema operations. From now on, you can create graph schemas for NebulaGraph without memorizing the nGQL syntaxes, which is more convenient and less stressful for users. NebulaGraph Studio is available here: [https://github.com/vesoft-inc/nebula-web-docker](https://github.com/vesoft-inc/nebula-web-docker)

![NebulaGraph Studio - Schema 01](https://user-images.githubusercontent.com/57335825/97271722-2841fa80-17ee-11eb-82f8-c1e66827584f.png)

![NebulaGraph Studio - Schema 02](https://user-images.githubusercontent.com/57335825/97271794-43146f00-17ee-11eb-9b34-1bf68dcaf446.png)

# Community Q&A

This week's topic is about how to restore cluster data from a snapshot in NebulaGraph.

Q: How to restore the data from a snapshot on a new cluster? Which directory in the cluster should I put the snapshot file in?

NebulaGraph: After a snapshot is created, you will find that the file structure in the snapshot is the same as that in the original data directory. Therefore, you can consider that the snapshot is a backup of the original data files. If you want to use the checkpoint you created to restore data on a NebulaGraph cluster, you can write a shell script to replace the original data with the checkpoint data. If you need to repeat the data corruption problem on the cluster, keep the original data.

Further push: Thank you very much. I have another question. If I have an active/standby cluster, and the structure of the standby cluster is different from that of the active cluster. For example, the active cluster has five machines for the storage service, and the standby cluster has only four. In this case, can I use the data snapshot of the active cluster to replicate data in the standby cluster?

NebulaGraph: Generally speaking, this is not possible. The structure of the standby cluster must be the same as that of the active cluster. Data loss may be caused by inconsistent structures of active and standby clusters. For example, for an active cluster, a graph space is divided into five partitions with one replica. If the standby cluster has only four machines, the data of one partition will surely be lost, and other adaptation problems may occur. Therefore, we recommend consistent structures of the active and standby clusters during the recovery process.

Further push: OK, thank you. We originally wanted to create a graph offline and create a snapshot of it, and then copy the snapshot data on online machines. We didn't want the offline machines to be completely consistent with the online ones. However, according to your replies, the offline cluster structure must be the same as the online one.

NebulaGraph: Keeping the structures consistent is recommended. I think you may want to load online data efficiently by doing this, right? If the number of nodes in the standby cluster is less than that in the active cluster, even if there is no adaptation problem, a partition balance operation will be performed between storage nodes after the snapshot is switched, which will also consume system resources and reduce the efficiency of the entire checkpoint handover. In my opinion, the gain is not worth the loss.

Further push: One more question. Can I just copy all the files under the `/data` directory of each machine in the active cluster to the corresponding directories in the slave cluster, instead of using the snapshot to restore the data, to migrate the data?

NebulaGraph: Yes, you can. In fact, the implementation mechanism of the checkpoint is to create a hard link for data files. The advantage of this hard link is that it will not occupy too much storage space under the same file system. Therefore, if the checkpoint is created by using the hard link mechanism on the local system, it has great advantages in both storage space and backup performance. In your business, the checkpoint is actually copied to another system, which is no big difference from copying data files directly. In addition, if you want to directly copy data files, you must avoid write operations in the source cluster during the copy process.

# Recommended for You

## [Benchmarking the Mainstream Open Source Distributed Graph Databases at Meituan: NebulaGraph vs Dgraph vs JanusGraph](https://discuss.nebula-graph.io/t/benchmarking-the-mainstream-open-source-distributed-graph-databases-at-meituan-nebula-graph-vs-dgraph-vs-hugegraph/715)

Selecting a graph database solution that can meet the Meituan's business requirements is the basis of building their graph storage and graph learning platform. In this article, the NLP team at Meituan benchmarked the mainstream open-source distributed graph databases in data import, data write, and data queries.

## Previous Pick of the Week

1. [Configuration recommendations for data import](https://nebula-graph.io/posts/nebula-graph-pick-of-the-week-sept-18-2020/)
2. [DB-Engines Graph DBMS Ranking Update in September](https://nebula-graph.io/posts/nebula-graph-pick-of-the-week-sept-4-2020/)
3. [Import data from Neo4J or JanusGraph to NebulaGraph](https://nebula-graph.io/posts/nebula-graph-pick-of-the-week-aug-28-2020/)

In this weekly issue, we are sharing NebulaGraph Studio feature updates and how to restore data from a cluster snapshot in NebulaGraph.