<h2 id="post-background-introduction">Background Introduction</h2>
<p> As a performance-leading native distributed <a href="https://www.nebula-graph.io/">graph database</a>, NebulaGraph has now implemented the integration of large language models and graph query language application framework. Users can now achieve schema acquisition, Prompt for Cypher statement generation, invocation of various large language models (LLM), and result processing purely with natural language, without the need for any coding. This greatly reduces the learning and usage costs.</p>
<h2 id="post-demo-experience">Demo Experience</h2>
<iframe src="https://graph-rag.streamlit.app/?embed=true" height="900" style="width:100%;border:none;"></iframe>
<h2 id="post-usage-instructions">Usage Instructions</h2>
<p>Using information from "Guardians of the Galaxy Vol.3" on Wikipedia as an example, this demo demonstrates how NebulaGraph uses large language models (LLM) to help users extract knowledge triplets from different types of information sources purely with natural language, and store them in NebulaGraph database.</p>
<p>You can click on other tabs to experience the visualization of NebulaGraph, Cypher query, natural language query (Text2Cypher), and other features. For more information, please refer to "<a href="https://www.nebula-graph.io/posts/knowledge-graphs-via-natural-language">Graph + LLM Practical Guide | Building and Querying Knowledge Graph using Natural Language</a>".</p>
<p>Without further ado, let's experience the fun of building and querying knowledge graphs using natural language with NebulaGraph!</p>

Experience the simplicity and convenience of building and querying knowledge graphs via natural language with NebulaGraph.

features

system-testing

dev-log

performance

use-cases

community

Deployment

tools

query-language

graph-computing

tech-talk

release-notes

architecture

news

source-code

user-review

knowledge-graph

Demo｜Building and Querying Knowledge Graph using Natural Language with NebulaGraph

Benchmarking the Mainstream Open Source Distributed Graph Databases at Meituan: NebulaGraph vs Dgraph vs JanusGraph

Graph Database vs Relational Database: What to Choose?

Difference Between Relational and Non Relational Database

Use cases of graph databases in real-time recommendation

The Linked Data Benchmark Council (LDBC) Social Network Benchmark, commonly known as LDBC SNB, is a benchmark test specifically designed to evaluate the performance of graph databases in the context of social networking scenarios.

# An Introduction to LDBC
Apart from the Social Network Benchmark, LDBC offers several other benchmark tests, including the Graphalytics Benchmark, Financial Benchmark, and Semantic Publish Benchmark, respectively tailored for graph analysis, finance, and RDF scenarios. The Social Network Benchmark was the first benchmark test proposed by LDBC and has since become the most popular graph database benchmark test worldwide. Notably, as a non-profit organization, LDBC merely provides official audits. The performance of different graph databases may vary due to the operating environment and relevant benchmark parameters. 

This article delves into the main components of LDBC SNB: the testing benchmark process, and the preparatory stage of SNB, namely Schema and data generation.

LDBC SNB primarily consists of three main components:
1. Data Generator: This is a tool for generating large-scale complex data with social network characteristics. The data includes typical social network entities and relationships such as people, posts, comments, geographical locations, organizations, and more.

2. Interactive Workload: This primarily caters to OLTP, simulating everyday user activities on social networks, such as posting, adding friends, liking, etc. Read requests mainly involve one-to-two-hop queries, possibly accompanied by some write requests.

3. Business Intelligence Workload: This is primarily for OLAP, simulating in-depth analysis of social network data with whole-graph queries. For example, it analyzes user social behavior, community formation and evolution, and other tasks requiring complex analyses and substantial data processing.

The LDBC SNB paper also refers to an SNB Algorithms component, which as the name suggests, primarily runs graph algorithms like PageRank, community discovery, breadth-first search, etc. However, since the paper was published in 2015 when the scenario was still in its drafting phase at the time, this component has now been moved to the Graphalytics Benchmark.

Furthermore, to run the LDBC SNB test, an official Driver provided by LDBC is required. Different databases need to implement the corresponding Connector based on the Driver's interface to connect the Driver and the database. Subsequently, the Driver generates a Workload, which can be understood as a series of query statements, based on the Benchmark's relevant parameters. It then drives the database under test to execute these query statements, ultimately yielding performance test results.

The entire LDBC SNB benchmark testing process is divided into three main stages: the preparation, the benchmark test, and the result output.

During the preparation stage, data generation takes place, which includes the initial import of full data, as well as subsequent real-time updates. In official audits, validation is also required on the SF10 Dataset, which is explained at the end of this article, so this stage also generates data for validation.

The benchmark testing phase begins with validation on the SF10 Dataset, followed by performance testing on the SF30 or SF100 Dataset. The validation process commences after data import, where the Driver, based on a series of queries and expected results prepared in the previous stage, verifies the database's query results to ensure their accuracy. There is no specific time requirement for this validation process. The subsequent performance testing is divided into import, warm-up, and performance testing. The database is allowed a 30-minute warm-up time, while the performance testing must last at least two hours. The test results are then compiled and output.

![image](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/2024-04-23-2.jpg)

# Generation of LDBC SNB Schema
The data in SNB simulates a social network similar to Facebook, with all data built around the Person entity. A person joins a network. Each Person might have several Forums, within which they can post several Posts. Other people may like some of these Messages.
The volume of these elements is mainly influenced by the number of Persons and time:
- A Person with more friends will post more comments or likes.
- Over time, as one makes more friends, the number of comments or likes will also increase.

Some data does not change with the number of the Persons, mainly including some Organizations (mainly schools in this context) and Places (mainly residential cities, countries, and other geographical information). This data plays a role during data generation. For instance, people who attend the same school during the same period are more likely to become friends.

The complete SNB Schema is illustrated in the following diagram:
![image](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/2024-04-23-3.jpg)

Most graph databases model entities as points and different relationships as edges during testing. However, this is just a convention; the SNB data modeling and the actual database Schema can differ, provided the database can perform the corresponding Workload queries.

## Data Generation for LDBC SNB
SNB is the Data Generator (referred to as DataGen), used to generate data that meets the above Schema. The data generated by the Generator is determined by the following three parameters:

- Number of Persons
- Number of years of data to simulate
- The year from which the simulation begins

According to the official documentation, the data generated by DataGen has the following properties:

- Reality: The generated data simulates a real social network. On one hand, the attributes, cardinalities, data correlations, and distributions in the generated data are carefully set to simulate real social networks like Facebook. On the other hand, its original data comes from DBpedia, ensuring the attribute values in the data are authentic and relevant.
- Scalability: DataGen can generate different sizes of datasets (from GB to TB level) for systems of various scales and budgets. Furthermore, DataGen can complete data generation on a single machine or within a cluster.
- Determinism: Regardless of the number of machines used to generate data or the machine configuration, the data generated by DataGen is deterministic and consistent. This essential function ensures that any data system can use the same dataset, guaranteeing fair comparisons between different system environments and repeatable benchmark test results.
- Usability: DataGen is designed to be as easy to use as possible.

The entire data generation process is illustrated in the following flowchart, which we will break down into several sections for explanation:

![image](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/2024-04-23-4.jpg)

## Distribution of Attribute Generated

The first step is initialization. The original data used by DataGen comes from DBpedia. For each attribute, DataGen decides the attribute's distribution based on:
- How many possible attribute values there are
- Probability of occurrence of each attribute value

The final distribution of attributes is saved as resource files and DataGen parameters.

## Generating Persons and Friendships
As mentioned earlier, the core of the SNB Schema is the Person, which is also reflected in the data generation process. DataGen generates all Persons, and some of the information needed for subsequent operations in Person, such as how many Friendships each Person has (this value is crucial, its distribution follows a Power law), the university attended by the Person, the company where the Person works, etc.

Then, DataGen creates the Friendship relationships, i.e., the 'knows' in the flowchart, for each Person. Just like in real social networks, people with the same interests or behaviors are likely to connect. To simulate such a social network, SNB considers the following three dimensions when generating Friendships:

- The university attended by the Person, the time of attendance, and the city where the university is located
- The Person's interests
- Each Person generates a random value, and the closer the random values, the more similar they are (this is to simulate that not all friends are made through university and interests)

These three dimensions account for 45%, 45%, and 10% of the weight of each Person's Friendship relationships, respectively. This divides the process of building edges between Persons into three sub-steps.

DataGen sorts all Persons according to three dimensions (sorted by one dimension at a time) and then divides the sorted Persons into multiple disjoint parts, distributed to different Worker processes. Even after division, the Persons a Worker thread is responsible for might exceed the memory size. Therefore, the Worker thread maintains a sliding window, where the probability of establishing Friendship relationships between Persons within the sliding window follows a geometric distribution.

As shown in the figure below.

![image](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/2024-04-23-5.jpg)

Suppose we've sorted by the university attendance dimension, resulting in an ordered sequence of Persons. The Worker then maintains a sliding window, generating Friendship relations each time for the person at the far left of the sliding window (P2 in the figure). The proportion of other people in the window establishing Friendship with the first person follows a geometric distribution. Once the first person in the sliding window has established enough Friendships, the starting point of the sliding window moves to the next person.

*Note: The specifics of the sliding window size, geometric distribution parameters, and even random generator parameters are not delved into here. It's unclear how DataGen handles situations where it's impossible to generate enough Friendships within the sliding window.*

After sorting, distributing, and establishing edges by the sliding window for all three dimensions, DataGen moves to the next stage.

## Generating Social Activities
After generating Persons and Friendships, DataGen starts to generate each Person's social activities, including Forums, Posts, and Comments. Some correlations exist in this data:
- Persons with more Friendships are more active on social networks.
- Each Person is more likely to Post or Comment in Forums related to their interests or the university they attended.
- Social activities are related to time; for example, discussions related to football surge near the World Cup.

## Final Output
After the above steps, DataGen completes data generation. The simulated social network graph is in two parts:
- Dataset: 90% of the data is for initial import.
- Update Streams: 10% of the data is for subsequent real-time updates.

In addition, it generates parameters (mainly starting points) for subsequent Workload requests. We'll explain parameter generation in detail in the next article, but here we'll briefly describe the SNB read request Workload. Interactive Workload queries primarily aim to get results within one second. All read queries start from a point in the graph, obtaining a small part of the subgraph information. Also, as different starting points have different degrees of input and output, this essentially determines the data volume accessed by this read request.

To test different systems and scenarios, SNB defines a scale factor (SF) to control the final data volume size. For instance, the original data size of SF1 is 1 GB, while the sizes of SF0.1 and SF300 are 100 MB and 300 GB, respectively. The amount of vertex-edge data of different scale factors is shown in the table below.

![image](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/2024-04-23-6.jpg)

The final generated Dataset is divided into two main categories: Static and Dynamic, both formatted in CSV. Depending on the number of threads configured in DataGen, the final generated data will also be divided into multiple fragments. Static includes Organizations, Places, Tags, etc., all of which are static data generated based on DBpedia. The number of these does not change with the scale factor. In other words, this data is independent of the number of Persons. The Dynamic part mainly includes Persons, knows (the Friendship described in the data generation section), Forums, Posts, and Comments, etc.

Update Streams contain all update operations, mainly simulating real-time actions such as registering new users, commenting, liking, adding friends, and more.

# Reference

We have now roughly completed the introduction to the preparation stage. We will elaborate on the parameters generated at the end of the preparation stage in the next article when we discuss Workload.
For further reading and detailed understanding, refer to 

- the LDBC Social Network Benchmark Specification
- ldbc-snb-interactive-sigmod-2015.pdf (ldbcouncil.org)







The Linked Data Benchmark Council (LDBC) Social Network Benchmark, commonly known as LDBC SNB, is a benchmark test specifically designed to evaluate the performance of graph databases in the context of social networking scenarios. This article delves into the main components of LDBC SNB: the testing benchmark process, and the preparatory stage of SNB, namely Schema and data generation.

A Brief Analysis of Schema Generation and Data Generation of LDBC SNB

Graph RAG has been revolutionizing the industry since its [joint introduction](https://www.nebula-graph.io/posts/graph-RAG) with NebulaGraph and LlamaIndex in August 2023, capitalizing on the momentum of LLM and RAG (Retrieval-augmented Generation). In this blog post, we will walk you through what Graph RAG is, why it is revolutionizing, and how to build your Graph RAG that draws on data context to answer complex, multi-part questions with NebulaGraph.

# Understanding Graph RAG and Its Rising Popularity

This cutting-edge technology has garnered widespread interest due to its capability to harness knowledge graphs alongside LLMs, thereby offering a more comprehensive contextual understanding for search engines. This results in more cost-efficient, intelligent, and precise search outcomes. Beyond providing more accurate responses to build user trust, this technology has surmounted the primary obstacles of traditional search augmentation techniques: the absence of context comprehension and data training. Consequently, these advanced retrieval enhancement techniques are poised to expand their reach into various industries, such as medical diagnosis assistance, content creation and recommendation, interactive gaming, and knowledge graph construction.

Microsoft underscored the importance of Graph RAG in the blog post [GraphRAG: Unlocking LLM Discovery on Narrative Private Data](https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/), authored by Jonathan Larson, Senior Principal Data Architect, and Steven Truitt, Principal Program Manager. They illustrated the effectiveness of Graph RAG by contrasting it with a baseline RAG system, concluding that the Graph RAG approach enables the LLM to anchor itself in the graph, resulting in a superior answer that includes provenance through original supporting text. Meanwhile, the baseline RAG struggles with queries that necessitate aggregation of information across the dataset to formulate an answer.

# Building Your Graph RAG with NebulaGraph

NebulaGraph database has integrated with LLM frameworks such as [LlamaIndex](https://www.llamaindex.ai/) and [LangChain](https://www.langchain.com/); you could simply focus on LLM orchestration logic and pipeline design without worrying about complex implementation. You could take a trial to check whether the Graph RAG performs as awesome as it is said with simply 4 steps before exploring further to integrate it into applications or other scenarios. 

***Note:*** 

*As LlamaIndex evolves rapidly, the recent refactor/break change has led to some of the Graph RAG tutorials becoming non-runnable. This blog is here for the updated tutorials of Graph RAG so that you can hands on it without errors.*

*We have been exploring so many in-house approaches before we upstream them later. We believe the basic concept of Graph + RAG in LlamaIndex is worth exploring, so we put the original workshop and notebooks in the reference chapter.*

## Set up your NebulaGraph cluster

You could start with any one of the three methods below to quickly set up a NebulaGraph cluster:

- start the NebulaGraph cluster via [NebulaGraph Lite](https://github.com/nebula-contrib/nebulagraph-lite) in Google Colab
- [deploy the cluster with Docker extension](https://www.nebula-graph.io/posts/nebulagraph-database-on-docker-desktop)
- instantiate a [NebulaGraphStore](https://docs.llamaindex.ai/en/stable/examples/index_structs/knowledge_graph/NebulaGraphKGIndexDemo/)

```
import os
from llama_index.core import KnowledgeGraphIndex, SimpleDirectoryReader
from llama_index.core import StorageContext
from llama_index.graph_stores.nebula import NebulaGraphStore

os.environ["NEBULA_USER"] = "root"
os.environ["NEBULA_PASSWORD"] = "nebula"
os.environ["NEBULA_ADDRESS"] = "127.0.0.1:9669"


space_name = "paul_graham_essay"
edge_types, rel_prop_names = ["relationship"], ["relationship"]  # default, could be omit if create from an empty kg
tags = ["entity"]  # default, could be omit if create from an empty kg

graph_store = NebulaGraphStore(
    space_name=space_name,
    edge_types=edge_types,
    rel_prop_names=rel_prop_names,
    tags=tags)

storage_context = StorageContext.from_defaults(graph_store=graph_store)
```

Now, with your NebulaGraph cluster set up, you could hands on the knowledge graph building section. **Please make sure to run all the steps below in the Jupyter environment.**

## Dependencies
The implementation of Graph RAG requires the below dependencies.

```
pip install llama-index
pip install llama-index-llms-ollama
pip install llama-index-graph-stores-nebula
pip install ipython-ngql
pip install llama-index-embeddings-huggingface
```

## Create a LlamaIndex Knowledge Graph Index

`KnowledgeGraphIndex` handles automated knowledge graph construction from unstructured text as well as entity-based querying. You need to set up a LlamaIndex Knowledge Graph Index Before creating a Graph RAG query engine. In this example, we 
will demonstrate how to build KG from textual data by creating a document object before moving on to create an index.

```
from llama_index.core import (
    VectorStoreIndex,
    SimpleDirectoryReader,
    KnowledgeGraphIndex,
)

graph_store.query("SHOW HOSTS")

Settings.chunk_size = 512

documents = SimpleDirectoryReader(
    "data"
).load_data()
```

```
kg_index = KnowledgeGraphIndex.from_documents(
    documents,
    storage_context=storage_context,
    max_triplets_per_chunk=10,
    space_name=space_name,
    edge_types=edge_types,
    rel_prop_names=rel_prop_names,
    tags=tags,
    max_knowledge_sequence=15,
)
```

## Create A Naive Graph RAG Retriever
The last step comes to creating a Graph RAG retriever, on top of which the query engine will be built so that you could query with natural language questions.

```
from llama_index.core.query_engine import RetrieverQueryEngine
from llama_index.core.retrievers import KnowledgeGraphRAGRetriever

graph_rag_retriever = KnowledgeGraphRAGRetriever(
    storage_context=storage_context,
    verbose=True,
)

query_engine = RetrieverQueryEngine.from_args(
    graph_rag_retriever,
)
response = query_engine.query("What's the relationship between Bob and Alice")
```

Now, you’ve tried Graph RAG and if you’d like to explore more on how to retrieve via both GraphStore and VectorStore, you could find more demo examples here: [https://www.siwei.io/tutors/GraphRAG/101.html](https://www.siwei.io/tutors/GraphRAG/101.html).

Join our RAG discussion and let us know how your Graph RAG goes in our [Slack channel](https://join.slack.com/t/nebulagraph/shared_invite/zt-2h51ct4t0-IlXFaU01mpb3t2WgQ8qqNA).

Reference:

- [https://bit.ly/graph-rag-workshop](https://bit.ly/graph-rag-workshop)
- [https://siwei.io/graph-enabled-llama-index/kg_and_vector_RAG.html](https://siwei.io/graph-enabled-llama-index/kg_and_vector_RAG.html)
- [https://siwei.io/demo-dumps/graph-rag/GraphRAG.html](https://siwei.io/demo-dumps/graph-rag/GraphRAG.html)






This blog will walk you through what Graph RAG is, why it is revolutionizing, and how to build your Graph RAG that draws on data context to answer complex, multi-part questions with NebulaGraph.

Implementing Graph RAG with NebulaGraph

ISO/IEC released the [international standard of Graph Query Language (GQL)](https://www.iso.org/standard/76120.html) on April 12th, 2024. This publication establishes the foundations for property graphs, covering their creation, maintenance, and control, along with the data they comprise. It also standardizes the data management language for outlining and modifying the structure of these graphs and their collections.

# Why the International Standard of GQL Matters
The standardization of a language plays an instrumental role in its adoption and application. The standardization of SQL in the 1980s led to its global acceptance by relational databases, thereby propelling the growth of relational databases.

Similarly, the standardization of GQL will have far-reaching impacts on the industry. GQL standards will ensure data portability and manipulation across GQL implementations, and compatibility with programming languages and database tools. It will foster a dynamic graph database ecosystem and lower the entry barrier for this technology, enabling more enterprises to effectively utilize graph databases for complex relational data.

# NebulaGraph Enterprise v5.0 Now Offers Native GQL Support
As a member of Linked Data Benchmark Council, Vesoft (NebulaGraph) actively participates in the formulation and promotion of GQL standards and announces its GQL native support in NebulaGraph Enterprise v5.0.

In addition to the outperforming horizontal scalability, high availability and HPA capability, NebulaGraph Enterprise v5.0 stands as the first distributed graph database to natively support GQL. Unlike systems that are just compatible or adapted to GQL, NebulaGraph Enterprise v5.0 has been redesigned to support GQL at the overall architecture level: it is built on and designed for GQL. This enhancement offers superior data compatibility and interoperability, thereby amplifying the business value of graph databases across various scenarios.

# Why Enterprises Should Adopt the Graph Database with Native Support for GQL

Choosing a graph database with native support for GQL means that enterprises can directly take the following advantages of GQL benefits.

- Enhanced Interoperability

Adopting a graph database with native support for GQL enables seamless data migration between different systems and platforms. This freedom reduces dependence on a single database provider, making it easy to switch between solutions and enabling simultaneous use of multiple data systems.

- Improved Stability

Enterprises embracing GQL will no longer rely on independent tools or software layers to be compatible with GQL statements. Therefore, they can enjoy the simplified system with less likelihood of errors and ease of operation and maintenance.

- Enhanced Security

GQL has a robust security framework that offers mature security control. Systems that do not natively support GQL may require additional development to achieve similar security features, potentially leading to risks such as data leaks and non-compliance with regulations.

- Cost-Efficient Maintenance

Adopting graph databases with native support for GQL enables companies to quickly adapt to market changes, which can directly reduce the complexity and expense of future system upgrades and maintenance for enterprises.

In conclusion, the release of GQL marks a significant milestone of graph database technology, fostering innovation and widespread adoption of graph databases as well as the overall growth of the industry. As the first distributed graph database that natively supports GQL, NebulaGraph Enterprise v5.0 aligns with GQL standards and will continue to refine its performance and stability to empower various industries, such as financial services, technology, e-commerce and manufacturing, to unlock the value of complex relational data.

If you’re interested in embracing GQL with NebulaGraph Enterprise v5.0, feel free to [reach out](https://www.nebula-graph.io/contact) for a free trial.

The release of GQL marks a significant milestone of graph database technology and  NebulaGraph Enterprise v5.0 announces native GQL support. 