Imagine a world where your data isn’t trapped in silos but connected like constellations, revealing hidden patterns that drive smarter decisions. Welcome to graph computing —the secret sauce powering today’s most innovative applications, from fraud detection to personalized recommendations. Let’s explore this transformative technology and how organizations are using it to turn complexity into competitive advantage.

# Decoding Graph Computing vs. Graph Databases
While often used interchangeably, these terms represent distinct concepts. Graph computing is the process of analyzing relationships to solve complex problems, like finding the quickest delivery route or detecting fraud rings. It’s the "brain" that applies graph theory to uncover insights.

Graph databases , on the other hand, are the "memory" that stores data as nodes (people, products) and edges (connections like "purchased" or "viewed"). They’re optimized to retrieve and manage these relationships efficiently. For example, a graph database might store billions of social media interactions, while graph computing algorithms analyze those connections to recommend new friends.

Think of it like cooking: the database holds the ingredients, and graph computing is the recipe that turns them into a meal.

# Why Graph Computing Matters Now More Than Ever
Traditional databases struggle with connected data. Relational systems require costly JOIN operations for relationship queries, while NoSQL solutions lack native support for multi-hop traversals. Graph computing solves this by:

- Speed : Analyzing millions of relationships in milliseconds.
- Flexibility : Adapting to evolving connections, like social networks or supply chains.
- Scalability : Handling billions of nodes and edges without slowdowns.

This capability is critical in modern applications. For example, Netflix uses graph computing to analyze viewing habits and suggest content that keeps users engaged. PayPal maps transaction patterns to stop fraud rings in real time.

# How Graph Databases Enable Graph Computing
Graph databases are the foundation for efficient graph computing. Leading solutions offer unique strengths:

[NebulaGraph](https://www.nebula-graph.io/) excels in real-time transaction processing at massive scale. It handles 10 billion+ edges natively, making it ideal for applications like ride-sharing route optimization or real-time fraud detection. Its SQL-like query language (nGQL) simplifies adoption, while open-source flexibility reduces vendor lock-in.

[Neo4j](https://neo4j.com/) focuses on deep analytical workloads, with a rich library of graph algorithms for tasks like community detection. However, its performance declines with datasets exceeding 1 billion nodes.

[TigerGraph](https://www.tigergraph.com/) targets enterprise-scale pattern matching, offering 35+ built-in algorithms and strong integration with machine learning tools. Its GSQL language appeals to SQL-proficient teams but requires more resource-intensive infrastructure.

[Amazon Neptune](https://aws.amazon.com/neptune/) simplifies cloud deployments for AWS-centric teams but lacks the hybrid flexibility of self-hosted solutions like NebulaGraph.

# Final Thoughts: From Complexity to Clarity
Graph computing isn’t about replacing your current systems—it’s about connecting them in ways that create exponential value. Whether you’re building a fintech startup or optimizing a manufacturing empire, the right solution turns data into discoveries.

Ready to Begin?
- Explore [NebulaGraph’s playground](https://explorer.nebula-graph.io/login) for hands-on learning
- Dive into the [Graph Database Community](https://join.slack.com/t/nebulagraph/shared_invite/zt-33nxrfan4-N_nhHDKOY1~C5YpHrJ3AiA) for peer insights
- Test your use case with the 14-day free trial offered by [NebulaGraph Cloud](https://www.nebula-graph.io/cloud-2025)


Let’s explore this transformative technology and how organizations are using it to turn complexity into competitive advantage.

Scaling Connections: How Graph Computing Solves Modern Data Complexity

Over the past few weeks, the Model Context Protocol (MCP) has sparked widespread discussion and attention within the technical community. Inspired by this momentum, I have contributed to several related open-source projects, including [implementing McpToolSpec for the official LlamaIndex repository](https://github.com/run-llama/llama_index/pull/17795) and collaborating with Xuanwo and FrostMing to develop [a Model Context Protocol Server for Apache OpenDAL™](https://github.com/Xuanwo/mcp-server-opendal).

As the only protocol currently offering a significant ecosystem advantage, MCP presents an exciting opportunity. In this context, [we have implemented a simple NebulaGraph MCP Server based on NebulaGraph 3.x](https://github.com/PsiACE/nebulagraph-mcp-server). This marks the first foundational component in the NebulaGraph X MCP ecosystem, opening up new avenues for exploring the potential of combining AI with graph databases. 

# What is Model Context Protocol (MCP)?

MCP, introduced by the Anthropic team, is an open protocol designed to provide AI systems with a unified and efficient way to access diverse data resources. By adopting a client-server architecture, MCP standardizes data access, addressing the fragmentation issues that traditional AI systems face when interacting with various data sources.

Key Features of MCP:

* **Standardized Communication**: MCP enables AI assistants to seamlessly access a wide range of data sources, including local data, remote services, and enterprise tools.
* **Openness and Ecosystem Advantage**: The MCP community already boasts nearly 1,000 MCP Server implementations, spanning search engines, weather services, databases, and more, facilitating rapid tool integration.
* **Flexible Architecture**: By defining clear interaction protocols between clients and servers, MCP empowers developers to build scalable and reusable systems.

While challenges around security and reliability remain, these issues are expected to be addressed as the protocol evolves and matures with improved development practices.


# Features of NebulaGraph MCP Server

Given my recent focus on Graph RAG and Agentic Workflow, leveraging large language models (LLMs) and intelligent agents to uncover insights from graph data has become a critical area of exploration. To facilitate this, I quickly developed the [NebulaGraph MCP Server](https://github.com/PsiACE/nebulagraph-mcp-server), enabling NebulaGraph 3.x to integrate into the MCP ecosystem as a tool for LLMs like Claude and GPT to invoke and utilize.

Built on FastMCP , the NebulaGraph MCP Server adheres to the core specifications of MCP, providing a lightweight and efficient connection service for graph databases. By exposing NebulaGraph's capabilities through standardized tool interfaces, this server allows LLMs to effortlessly interact with NebulaGraph data for basic graph exploration tasks.

### Multiple Transmission Modes:

* Supports both stdio and SSE (Server-Sent Events) transmission modes, catering to diverse development and deployment scenarios.

### Basic Graph Exploration Capabilities:

* Graph Space Listing: Enables models to query available graph spaces.
* Schema Querying: Supports querying schema definitions for specified graph spaces.
* Query Execution: Facilitates executing NebulaGraph queries via the MCP Server.

### Built-in Operator Templates:

* Includes templates for common operations like pathfinding and neighbor discovery, allowing LLMs to quickly retrieve preliminary insights from graph data.

To demonstrate its functionality, I built a simple example using McpToolSpec from LlamaIndex and ReActAgent. Below is a screenshot showcasing its capabilities:

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

# Conclusion
The NebulaGraph MCP Server represents an initial step in contributing to the MCP ecosystem, aiming to bridge the gap between language models and graph databases. As the protocol matures and its ecosystem expands, we hope it can play a vital role in real-world applications. If you're interested in this direction, we invite you to explore, experiment, and collaborate with us!

Together, let’s unlock the full potential of AI-powered graph databases!

The NebulaGraph MCP Server based on NebulaGraph 3.x is now open source. This marks the first foundational component in the NebulaGraph X MCP ecosystem, opening up new avenues for exploring the potential of combining AI with graph databases. 

Announcing the Open-Source Release of NebulaGraph MCP Server: Exploring the Infinite Possibilities of AI + Graph Databases

Storaged, the core storage component of NebulaGraph, is responsible for ensuring durability, availability, and scalability. It plays a critical role in handling reads and writes efficiently. This article explores the architecture of Storaged from the perspective of its underlying storage engine, RocksDB [1], and shares insights from real production use cases on diagnosing and resolving performance bottlenecks. 

One notable production example is Snapchat, which uses NebulaGraph to enhance its friend recommendation system at scale. (Read more [here](https://www.nebula-graph.io/posts/snapchat_enhances_friend_recommendations_with_nebulagraph).)

# How is data read and written in NebulaGraph

In NebulaGraph, both vertices and edges are stored as key-value pairs using RocksDB as the storage engine. In version 3.x, we use RocksDB 3.7.3. The data is partitioned and replicated, with each partition replica backed by a separate RocksDB instance.

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

To distribute data across multiple storage nodes, we use hash function:
- **Vertices** are partitioned based on their vertex ID.
- **Edges** are partitioned based on the source vertex ID.

This design ensures that a vertex and all its outgoing edges reside in the same partition, improving query performance. However, **super nodes** (e.g., highly connected entities such as celebrities or popular websites) can cause load imbalances. Hashing helps distribute these nodes more evenly across Storaged instances.

# Consistency and Replication via Raft

To maintain consistency between replicas, NebulaGraph employs the **Raft consensus algorithm** [2], which elects a **Leader** among the replicas. The Leader handles most read and write requests, while **Followers** serve as backups. If a Leader fails due to network issues or maintenance, a new Leader is elected.

The data write and replication process follows these steps:

1. The Leader writes data to the **Write-Ahead Log (WAL)**.
2. The write is replicated to all Followers, who also write to their own WAL.
3. Followers asynchronously persist the data to RocksDB and acknowledge the Leader.
4. Once the Leader receives acknowledgments from all Followers, it commits the write to RocksDB.

The diagram below illustrates this process.
![image](https://www-cdn.nebula-graph.io/blogs/storage_process.png)

# High Availability with Zones

For environments requiring high availability, we recommend distributing partition replicas across different zones. A zone refers to a distinct logical or physical grouping of infrastructure. In cloud environments, zones typically correspond to availability zones (AZs) [3] - geographically separate data centers within a region. These zones are close enough to support low-latency connections but far enough apart to minimize the risk of simultaneous failures due to localized disruptions (e.g., power outages or extreme weather). In this setup:

* Writes are always handled by the Leader, regardless of zone placement.
* Reads can be optimized with **zone affinity**, where queries prioritize a Storaged instance within the same zone as the compute node (Graphd) handling the query. 
* With zone affinity enabled, both Leaders and Followers can serve read requests, improving efficiency and reducing cross-zone data transfer costs. (E.g., In AWS, intra-zone data transfer is free.)

# Diagnosing High Storaged Latency: Common Causes and Solutions

In production environments, high P90 query latency and increased query failures often signal performance issues. While some problems originate from Graphd (our compute nodes) or Metad (our meta service nodes), when the root cause lies in Storaged, it always manifests as high storage latency. This section covers the most common causes of high storage latency and how to mitigate them.

## 1. Low Resource Utilization

If Storaged latency is high, but CPU usage, disk I/O, and disk throughput remain low, the software may not be fully utilizing available hardware resources. A key area to check is thread allocation for the Thrift server and RocksDB. 

Storaged relies on three main thread pools:
- Thrift IO thread pool – Handles incoming connections in an event loop. 
- Thrift worker thread pool – Handles service requests, including writes.
- Read handler thread pool – Manages disk reads via RocksDB.

The Thrift IO threads process the connections very fast and rarely cause latency issues. If latency persists, focus on the worker and read handler pools. In production, setting these pools to match the number of CPU cores on the machine or pod running Storaged typically yields optimal performance.

## 2. High CPU usage

If high CPU usage is observed across all Storaged instances, the root cause likely falls into one of the following categories.

### (1) CPU Spikes During Data Ingestion

If high CPU usage occurs primarily during data ingestion, the most likely cause is RocksDB compaction [4]. Compaction is an essential process that merges and reorganizes data in RocksDB’s Log-Structured Merge Tree (LSM tree) to optimize read performance. However, it can be resource-intensive.

To mitigate excessive CPU usage during compaction, consider the following optimizations:

* **Reduce compaction concurrency:**
    * Lower `max_subcompactions` and `max_background_jobs` to slow down compaction and distribute CPU load more efficiently.
* **Optimize custom compaction filtering**:
    * In NebulaGraph, expired data is garbage-collected using a **custom compaction filter** [5] when TTL is enabled [6]. This filter scans affected vertices and edges during compaction and verifies whether their TTL has expired. This additional check incurs CPU overhead.
    * The config `min_level_for_custom_filter` determines at which LSM level the custom compaction filter starts processing data.
    * A lower value of `min_level_for_custom_filter` will scan more levels of data and thus increase CPU load.
    * A higher value of `min_level_for_custom_filter` postpones TTL filtering to later stages, which reduces CPU usage but increases the temporary retention of expired data.

Since an excessively high value of `min_level_for_custom_filter` can result in bloated storage and potential availability issues, careful fine-tuning is necessary. The goal is to determine an optimal value that balances CPU efficiency with the retention of expired data. We will explore the impact of accumulated expired data later in this article.

### (2) Persistent High CPU Usage, Regardless of Writes

If high CPU usage persists even when there are no active writes, the cause is likely related to RocksDB read operations or thread contention within Storaged. To diagnose the issue more precisely, we recommend running `perf top` on a high-CPU Storaged instance.

* On physical or virtual machines, running `perf top` is straightforward.
* On Kubernetes deployments, additional privilege changes are required. Our Nebula Operator [7] includes the necessary configurations and can enable `perf top` with a single setting.

If `perf top` shows excessive thread context switching and preemption occurring within Thrift’s internal queues, this indicates over-threading - too many active threads competing for CPU resources. Reducing the number of worker and read handler threads can improve CPU efficiency.

## 3. High Disk I/O Utilization

If IOPS or I/O throughput reaches the disk's limits, query latency can degrade significantly. Identifying the underlying cause is crucial for maintaining performance.

### (1) High I/O During Data Ingestion

If excessive disk I/O occurs only during data ingestion, the likely causes are:
* High data ingestion speed
* High compaction concurrency

To alleviate this, consider:
* Reducing ingestion speed or adjusting the batch size
* Lowering the values of `max_subcompactions` and `max_background_jobs` to limit compaction concurrency

### (2) Constantly High I/O with Storage Errors

If disk I/O remains persistently high and approaches the disk's limit, and error logs such as `RPC failure in StorageClient` with `timeout` or `loadshedding` appear in Graphd, this likely indicates excessive amount of expired data..

In this case, Storaged is scanning the disk excessively to filter out expired data, which significantly increases I/O load. To verify this, check the statistics by running:

```
SUBMIT JOB STATS;
SHOW STATS;
```
If the amount of stale data is twice the normal level or higher, trigger a full compaction to clean up expired data:

```
SUBMIT JOB COMPACT;
```
# Conclusion

Storaged is a critical component of NebulaGraph, and its performance directly impacts query latency and system stability. This article provided insights into how data is stored, partitioned, replicated, and accessed in Storaged, along with best practices for diagnosing and resolving high storage latency.

#Reference

[1] Rocksdb. https://github.com/facebook/rocksdb 

[2] Raft. Ongaro, Diego, and John Ousterhout. "In search of an understandable consensus algorithm." 2014 USENIX annual technical conference (USENIX ATC 14). 2014.

[3] Availability Zone. https://learn.microsoft.com/en-us/azure/reliability/availability-zones-overview?tabs=azure-cli 

[4] Rocksdb Compaction. https://github.com/facebook/rocksdb/wiki/Compaction 

[5] Compaction Filter. https://github.com/facebook/rocksdb/wiki/Compaction-Filter 

[6] TTL in NebulaGraph. https://docs.nebula-graph.io/3.8.0/3.ngql-guide/8.clauses-and-options/ttl-options/

[7] Nebula Operator. https://github.com/vesoft-inc/nebula-operator 





This article explores the architecture of Storaged from the perspective of its underlying storage engine, RocksDB, and shares insights from real production use cases on diagnosing and resolving performance bottlenecks.

When NebulaGraph Slows Down: Diagnosing Storage-Related Performance Issues

Imagine asking ChatGPT, “How did the 2023 global chip shortage impact Tesla’s suppliers in Shenzhen through three degrees of separation?” Despite its eloquence, the LLM would likely falter—not because it lacks data, but because it lacks a way to map hidden, dynamic relationships. This is where graph databases like NebulaGraph become essential for the next generation of AI and LLMs.

As AI shifts from statistical pattern recognition to knowledge-driven reasoning, traditional databases (SQL, NoSQL) hit a wall. Their rigid tables and documents can’t model the interconnectedness of real-world data—supply chains, fraud networks, or molecular interactions. This blog explores how graph technology is rewriting the rules of intelligent systems.

# LLM Hallucinations: When “Confidently Wrong” Becomes Dangerous
LLMs hallucinate because they infer answers from patterns, not facts. Without grounding in verified knowledge, they risk generating plausible but dangerous outputs. Hallucinations aren’t just errors—they’re liabilities because they lack access to verified, structured knowledge. A medical chatbot might invent a drug interaction that doesn’t exist, risking patient safety.

# The Limitations of Traditional Databases
One of the biggest limitations of traditional databases is that they treat data points as isolated entities. Relational databases force data into tables, losing nuanced connections. For example, mapping a 10-layer corporate ownership structure requires 50+ JOINs in SQL, slowing queries to minutes. Vector databases retrieve semantically similar data but miss contextual relationships.

AI often struggles with the isolated data because so much of its power comes from understanding relationships. Graph databases, by contrast, are designed to store and manage data as interconnected entities, allowing AI to make sense of the links between seemingly disparate elements.

# Knowledge Graphs for Intelligent AI Systems
Graph databases are the backbone of such knowledge graphs, providing a powerful means of organizing and traversing complex webs of information. They allow AI systems to dynamically explore and connect various pieces of data, enhancing both the depth and the accuracy of the answers provided. Knowledge graphs are already being used in domains such as finance, healthcare, and education, where the complexity of the data requires more than a surface-level understanding.

Consider a fraud detection system for a major bank. Instead of treating each transaction as an isolated data point, a graph-powered AI can look at an entire network of transactions—cross-referencing user relationships, transaction frequency, locations, and any outliers that indicate something suspicious. It’s this networked understanding that enables real-time decision-making, stopping fraud as it happens rather than analyzing it after the damage is done.

# Graph RAG: Minimize Hallucinations of Traditional RAG
Graph RAG (Retrieval-Augmented Generation) is an advanced evolution of traditional RAG that integrates knowledge graphs into the retrieval process, significantly enhancing contextual understanding and multi-hop reasoning capabilities. Graph RAG addresses hallucinations of traditional RAG by leveraging the structured relationships in knowledge graphs, enabling more precise and contextually rich information retrieval. This structured approach minimizes hallucinations by grounding responses in factual, interconnected data, leading to more accurate and reliable answers.

# Two Major Methods to Implement Graph RAG

- **Build Your Graph RAG with NebulaGraph**: This method requires some coding work and solid AI knowledge. By leveraging NebulaGraph’s powerful graph database capabilities, you can construct a knowledge graph that integrates with your existing data sources. The approach of [Implementing Graph RAG with NebulaGraph](https://www.nebula-graph.io/posts/implement_graph_rag_with_nebulagraph) allows for customization and fine-tuning of the graph structure and retrieval algorithms, providing a robust solution for complex enterprise applications. It involves steps such as data ingestion, graph construction, and integration with large language models (LLMs) to enable sophisticated query handling and response generation.

- **Choose NebulaGraph RAG**: For those without coding experience, [NebulaGraph RAG](https://www.nebula-graph.io/posts/announcing_nebulagraph_RAG) offers an intelligent app-building platform that simplifies the process. This platform abstracts away the technical complexities, allowing users to build and deploy graph-powered AI applications with minimal effort. It provides a user-friendly interface for creating knowledge graphs, configuring retrieval parameters, and generating responses, making it accessible to a wider range of users within the organization.

# Build Tomorrow’s AI with NebulaGraph Today
The next AI breakthrough won’t come from bigger LLMs—it’ll come from smarter data infrastructure. NebulaGraph bridges the gap between LLMs’ linguistic brilliance and the structured intelligence of real-world knowledge. In the race to AGI, graph databases aren’t optional—they’re the bedrock. As OpenAI’s CTO once mused, “The future of AI isn’t just neural networks; it’s neural networks married to knowledge.”

Discover how graph databases like NebulaGraph are powering the future of AI and LLMs by enabling complex reasoning, reducing hallucinations, and unlocking scalable knowledge-driven applications.

Why Graph Databases Like NebulaGraph Are Essential for the Next Generation of AI and LLMs

**Author Introduction**

Hong Hailan specializes in leveraging large language models (LLMs) to automate the extraction of knowledge from unstructured medical records, construct knowledge graphs in traditional Chinese medicine, and uncover the experiences of renowned TCM practitioners.


# Background


Building knowledge graphs presents dual challenges: improving the efficiency of knowledge extraction and reducing human labor costs. To effectively address these issues, this paper builds on the schema layer and explores methods for automated knowledge extraction. The following sections detail the process of constructing a knowledge graph for the treatment of rhinitis by Master Gan Zuwang, a renowned traditional Chinese medicine practitioner.
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/%E9%BC%BB%E7%82%8E%E7%9F%A5%E8%AF%86%E5%9B%BE%E8%B0%B1/1.png)
The data for this study comes from clinical records of rhinitis patients, with a total of 1,081 detailed records selected for analysis. These valuable records contain various basic patient information, such as name, workplace, gender, age, diagnosis time, disease type, symptom details, diagnostic results, observations of tongue and pulse, treatment records, prescription content, and medication guidance.






# Knowledge Graph Construction Process Diagram





## Step 1: Prepare Sample Data

Utilize the 1,081 preprocessed medical records as sample data.


## Step 2: Define Extraction Targets

Based on the ontology-defined schema layer, establish extraction targets like diseases, related diseases, symptoms, examinations, tongue appearance, pulse appearance, and compatibility. Define extraction rules for each target type.




## Step 3: Automated Knowledge Extraction



Create a prompt template based on the defined extraction targets, using a "demonstration case + relationship list" format to guide large language models in automatically extracting medical record data and generating triples.



**The following is a specific Prompt example:**

Imagine you are a large language model designed to extract relationships in Traditional Chinese Medicine. Your task is to extract the relationships between symptoms and related diseases for rhinitis patients. Here's an example medical case:

"Rhinitis has been severe for three days, the condition naturally flares up, with excessive nasal discharge, difficulty blowing the nose. Headache. Nasal congestion. Nasal mucosal edema, with secretions. Thin white tongue coating, floating and tight pulse. Prescription: mulberry leaf 6g, peppermint 6g, platycodon root 6g, calamus 6g, spatholobus stem 10g, schizonepeta 6g, angelica dahurica 6g, xanthium fruit 10g, fagopyrum 10g, vitex 10g."

The output format is:[(“rhinitis”, “symptom”, “excessive nasal discharge”), (‘rhinitis’, ‘symptom’, ‘difficulty blowing the nose’), (‘rhinitis’, ‘symptom’, ‘headache’), (‘rhinitis’, ‘symptom’, ‘nasal congestion’), (‘rhinitis’, ‘examination’, ‘nasal mucosal edema’), (‘rhinitis’, ‘examination’, ‘secretions’), (‘rhinitis’, ‘tongue appearance’, ‘thin white tongue coating’), (‘rhinitis’, ‘pulse appearance’, ‘floating and tight pulse’), (‘rhinitis’, ‘combination’, ‘calamus 6g’), (‘rhinitis’, ‘combination’, ‘spatholobus stem 10g’), (‘rhinitis’, ‘combination’, ‘schizonepeta 6g’), (‘rhinitis’, ‘combination’, ‘angelica dahurica 6g’), (‘rhinitis’, ‘combination’, ‘xanthium fruit 10g’), (‘rhinitis’, ‘combination’, ‘fagopyrum 10g’), (‘rhinitis’, ‘combination’, ‘vitex 10g’)]. Follow this format to extract the following medical case in triplet format. The given sentence is: ‘***’. Given the relationship list: [‘symptom’, ‘related disease’, ‘combination’, ‘tongue appearance’, ‘examination’, ‘pulse appearance’], provide the relationships in the list. If they do not exist, output: none.


## Step 4: Clean the Extracted Results

Use regular expressions to clean the automatically generated triplet data by removing errors, redundancies, irrelevant, and incomplete triplets. This process ensures the accuracy and reliability of the data.


## Step 5: Store the Triplets

Store the final extracted triplet data in the NebulaGraph database.

This paper directly extracts diseases and Chinese herbs into corresponding triplets to ensure the reliability of the knowledge extraction process using large language models. During the writing process, these triplets are further decomposed to ensure the rationality of the knowledge graph. Additionally, the entities and attributes of Chinese herbs are jointly extracted during the knowledge extraction. For example, the dosage of Fagopyrum 10g in a rhinitis patient’s prescription is extracted as ('rhinitis', 'combination', 'fagopyrum 10g').

Before storing the triplets, this paper uses regular expressions to extract the entities and their corresponding attributes. For instance, ('rhinitis', 'combination', 'fagopyrum 10g') is decomposed into ('rhinitis', 'combination', 'Fagopyrum') and ('fagopyrum', 'dosage', '10g'), as demonstrated in the constructed knowledge graph.




# Using NebulaGraph to build a knowledge graph




**Why NebulaGraph**？NebulaGraph is a high-performance and user-friendly graph database that offers researchers a new way to explore and analyze data thanks to its outstanding features and broad applications. It comes with a graph query language called **nGQL**, which provides users with a rich set of graph operation functions. Whether for basic CRUD operations on nodes and edges or complex graph algorithms and path queries, nGQL handles them effortlessly. This **flexibility and robust functionality make NebulaGraph an excellent choice for handling complex network structures and maximizing the value of medical case data**.

**Specific steps:**

* Algorithm pseudocode

* Construct prompt templates, related cases, and relationship lists

* Write functions to connect to **NebulaGraph**

* for i := 0 to N do // traverse medical case data

* Generate questions by combining data and templates

* Pass the questions to the LLM to get answers

* Clean the answers and remove unnecessary triples

* Build the IDs for patients, examinations, symptoms, and prescriptions in the current case

* for j := 0 to M do // iterate through the triple list


```
if relation'=="combination”:       
      Determine whether the Chinese herb in the triplet contains a dosage unit attribute. If it does, extract the attribute and store the extracted result in the knowledge graph. 
Else: Directly write the extracted results into the knowledge graph.
end for
```





# Experiment



This study utilizes a dataset of 353 pre-prepared medical cases as the foundation for knowledge extraction experiments using large language models (LLMs). In the experiment, other LLMs are employed for data annotation, followed by manual verification and correction to ensure the accuracy and reliability of the annotated data. This process serves to evaluate the knowledge extraction performance of each model. The Bert-BiLSTM-CRF model is selected as the baseline for joint entity and relationship extraction, and the results of automatic extraction using the Bert-BiLSTM-CRF model are compared with those obtained from large language models, primarily GLM3, GLM4, and ChatGPT-4. The evaluation metrics include F1 score, precision, and recall, with the experimental results presented in the table.
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/%E9%BC%BB%E7%82%8E%E7%9F%A5%E8%AF%86%E5%9B%BE%E8%B0%B1/2.png)



# Knowledge Graph Display


This study leverages the constructed knowledge graph to analyze and mine medication patterns used by a master physician in treating rhinitis, such as identifying the top 10 drugs most frequently prescribed for severe sneezing symptoms. The following Cypher query is executed to achieve this:

```
MATCH (v:Patient)-[:HAS_SYMPTOM]->()-[:SPECIFIC_SYMPTOM]->(v1) 
WHERE id(v1) = 'severe sneezing' 
MATCH (v:Patient)-[:PRESCRIBED]->(v3)-[e2:COMPONENT_OF]->(v4) 
RETURN v4, count(v4) AS cnt 
ORDER BY cnt DESC 
LIMIT 10;
```



This query identifies patients exhibiting severe sneezing symptoms, retrieves their treatment prescriptions, and sorts the drugs by frequency of occurrence, returning the top 10 most frequently prescribed drugs. The top 10 drugs are: Cicada Skin, Windproof, Ink Plant, Licorice, Earthworm, Black Soybean Coat, Chebulic Myrobalan, White Atractylodes, Rubia Root, and Astragalus.
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/%E9%BC%BB%E7%82%8E%E7%9F%A5%E8%AF%86%E5%9B%BE%E8%B0%B1/3.png)


This paper introduces how to build a knowledge graph for the treatment of rhinitis with traditional Chinese medicine using NebulaGraph.

Rhinitis Knowledge Graph in Traditional Medicine Using NebulaGraph

We are thrilled to announce the General Availability of the NebulaGraph Cloud Standard Tier with 14-day free trial! [NebulaGraph Cloud](https://www.nebula-graph.io/cloud-2025) is a fully-managed graph database service designed to support and enhance Graph RAG projects. It offers native support for ISO-GQL, the industry's first standardized graph query language, ensuring seamless integration with various AI models and tools. This support for ISO-GQL enables efficient querying and retrieval of data from the graph database, providing the necessary context for AI models to generate high-quality content.

# The Ideal Choice for Various Users

Graph databases excel at handling complex, interconnected data by modeling it as nodes and edges, which represent entities and their relationships, respectively. This structure enables efficient querying and analysis of data connections, making it ideal for applications where understanding relationships is crucial. The Standard Tier of NebulaGraph Cloud is tailored to meet the needs of different user groups:

- **Individual Developers**: For those looking to expand their skill set or build innovative projects, such as Graph RAG, the Standard Tier offers an affordable and accessible tool for learning and experimentation. It allows them to focus on developing their Graph RAG models without worrying about the underlying infrastructure complexities.

- **Data Scientists and Researchers**: The platform provides a robust environment for academic research and experimentation with Graph RAG. Researchers can leverage NebulaGraph Cloud to analyze complex datasets, develop novel Graph RAG algorithms, and gain valuable insights into the intersection of graph databases and generative AI.

- **Startup Founders and Small Teams**: For startups and small teams, the Standard Tier offers quick setup and minimal maintenance, allowing them to rapidly prototype and scale their AI projects. It helps them bring their innovative ideas to life without the need for extensive resources or expertise in managing graph databases.

# Key Features of NebulaGraph Cloud:

- **ISO-GQL Support**: NebulaGraph Cloud is the first to support the ISO-GQL standard graph query language on the cloud, allowing users to experience this powerful querying capability firsthand.

- **Beginner-Friendly**: Features no-code graph creation and interactive visual analysis, along with built-in demo datasets, making it accessible for beginners.

- **Flexible Data Modeling**: Supports multiple data types and complex relationship modeling, making it versatile for a variety of applications.

- **Observability**: Includes a monitoring dashboard with visual charts and continuous performance and resource utilization reporting.

# Special Launch Pricing:
**For the first 14 days after creating an instance, NebulaGraph Cloud Standard Tier will be available for free.** After the trial period, if the instance is not deleted, it will automatically start charging at a special discounted rate, with the benefit of this discounted pricing extending for the first six months.

Don’t miss this opportunity to innovate with NebulaGraph Cloud. **[Sign up for the 14-day free trial](https://cloud.nebula-graph.io/login) and experience the future of graph databases with native ISO-GQL support now!**

We are thrilled to announce the General Availability of the NebulaGraph Cloud Standard Tier with 14-day free trial!

Unlock the Power of Graphs: NebulaGraph Cloud Standard Tier Launches with 14 Day Free Trial!

SQL (Structured Query Language) has been the standard language for managing and querying relational databases for decades. Relational databases store data in tables and use structured schemas to define relationships between these tables. However, with the increasing complexity of data relationships in modern applications, there has been a growing need to model and query data in ways that go beyond traditional tabular structures.

Graph databases, such as Neo4j, Amazon Neptune, and NebulaGraph, have emerged to address these needs by storing data as nodes (entities) and edges (relationships). They are optimized for traversing and querying complex relationships, making them ideal for applications like social networks, recommendation engines, fraud detection, and network analysis.

In response to the rising popularity of graph databases and the demand for more flexible data modeling, several major SQL database systems have introduced support for graph queries. This includes the ability to create, manage, and query graph structures directly within a SQL database, leveraging the familiar syntax and capabilities of SQL. 

This introduction does bring benefits to organizations looking for unified data management as both relational and graph data can be managed within the same database system, simplifying their data architecture and reducing the need for multiple specialized databases. However, it does not necessarily mean that graph databases will no longer be needed or that they will be replaced. 
Here are several key points to consider regarding the impact of this development on graph databases:

# Data Model Complexity and Flexibility
The graph database is a natural fit for graph data. If the data inherently represents complex relationships and networks (e.g., social networks, knowledge graphs), a graph database provides a more natural and intuitive way to model and query the data. What’s more, graph databases offer more flexibility in evolving the data model. In relational databases, schema changes can be complex and disruptive, whereas graph databases allow for more dynamic and flexible schema evolution.

# Query Language and Usability
Graph databases often provide specialized query languages (e.g., Cypher for Neo4j, Gremlin for TinkerPop) that are designed specifically for graph traversal and pattern matching, making it easier to express complex queries. Since the ISO-GQL was officially released in April this year, the graph database industry is expecting this standard graph query language to provide a unified and standard experience for developers familiar with graph concepts, as using a standard graph-specific query language, can be more intuitive and efficient compared to using SQL extensions for graph queries.

# Real-Time Analytics and Insights
For applications requiring real-time insights and analytics, such as fraud detection or recommendation engines, graph databases are optimized for low-latency query execution and can handle real-time data updates and queries more effectively. Some graph databases are designed to integrate seamlessly with streaming data sources, enabling real-time graph updates and analytics. Apparently, under situations requiring real-time analytics and insights, even though relational databases can perform graph queries, they may not be ideal options.

# Scalability and Distributed Processing
In terms of scalability and distributed processing, relational databases with graph query support might not be competitive to dedicated graph databases. Many graph databases are designed to scale horizontally, distributing data and queries across multiple nodes in a cluster, for instance NebulaGraph. This can be particularly important for large-scale graph applications where the data volume and query complexity require distributed processing. Besides, dedicated graph databases often come with built-in, optimized graph algorithms (e.g., shortest path, centrality, community detection) that can be executed efficiently at scale. 

# Complementary Use Cases
Graph databases are optimized specifically for graph data and queries, offering advanced features such as efficient graph traversals, pattern matching, and handling of complex relationships. While SQL databases with graph query support can handle basic graph operations, dedicated graph databases are likely to remain superior for use cases that require high performance and scalability in graph processing. Therefore, SQL databases with graph capabilities and dedicated graph databases can coexist, each serving different needs and use cases.

# Performance Considerations
While SQL databases with graph query support can handle graph data, they might not match the performance and efficiency of dedicated graph databases, especially for large-scale graph processing and real-time analytics. Graph databases are designed with specific optimizations for graph workloads, such as index-free adjacency, which can significantly improve query performance for certain types of graph operations.

# Conclusion
In summary, while the support for graph queries in SQL databases enhances their capabilities and provides more flexibility, it does not render dedicated graph databases obsolete. Each type of database has its strengths and is suited for different use cases. Organizations will continue to choose the best tool for their specific requirements, and dedicated graph databases will remain crucial for applications that demand high-performance graph processing and advanced graph analytics. The coexistence of these technologies provides organizations with a broader range of tools to meet their diverse data management needs.

While the support for graph queries in SQL databases enhances their capabilities and provides more flexibility, it does not render dedicated graph databases obsolete.

Graph Databases vs. SQL with Graph Queries: Friends or Foes?

GQL, a property graph query language newly released this year by the ISO, is the second international standard database query language since SQL's debut over 40 years ago. It integrates the strengths of Cypher, SQL, and various general programming languages, making it a powerful tool for analyzing complex graph data.

# Building on Cypher: How GQL Enhances Graph Queries

## Enhanced Graph Pattern Matching

### Powerful Label Matching Syntax

One of the standout features of GQL is its advanced label matching syntax. This allows for more complex queries using logical operators such as `&`, `|`, and `!`.

In Cypher, a typical query might look like this:

```
MATCH (n:Person)
WHERE n.age > 30
RETURN n
```

With GQL, you can perform more sophisticated queries:

```
MATCH (n:Manager & FullTime | !Intern)
WHERE n.age > 30
RETURN n.name AS managerName, n.department AS dept
```

This GQL query finds nodes that are both `Manager` and `FullTime`, or not `Intern`, and have an age greater than 30.

### Regex-like Variable-Length Path Pattern

GQL introduces a regex-like syntax for variable-length patterns, enhancing flexibility in path matching. Examples include `-[e]->{1,3}`, `-[e]->+`, `-[e]->*`, and` -[e]->?`. This allows for more complex path pattern matching compared to Cypher’s syntax.

### Path Restrictors

GQL provides four path restrictors—`WALK`,`TRAIL`,`ACYCLIC`, and `SIMPLE`—to control whether paths can have repeated nodes or edges.

### Path Selectors

GQL offers versatile shortest path queries, including options for finding all shortest paths, any shortest path, and the top k shortest paths. This flexibility allows for detailed and efficient path retrieval in various scenarios.

## Modern Variable Definition

### Local Variable Definition

GQL introduces a dedicated syntax for defining local variables at the beginning of a procedure, similar to early C language practices. These variables are visible throughout the entire procedure scope. The introduction of local variables allows GQL to express nonlinear data flows, enabling data to be reused multiple times.

For instance, when users need to perform multiple analyses on the same dataset, GQL's local variables provide an efficient way to store and reuse intermediate results. This is particularly useful for complex calculations or when the same base data needs to be processed in different ways.

Consider a scenario where we want to analyze user interactions in a social network:

```
TABLE userActivity = {
    MATCH (u:User)-[a:ACTION]->()
    RETURN u.id AS userId, a.timestamp AS actionTime, a.type AS actionType
}
 
VALUE activeUsers = VALUE {
    FOR i IN userActivity
    WHERE i.actionTime > datetime('2024-01-01')
    RETURN collect_list(DISTINCT i. userId)
}
 ​
VALUE uniqueActionTypes = VALUE {
    FOR i IN userActivity
    WHERE i.userId IN activeUsers
    RETURN count(DISTINCT i.actionType) AS uniqueActionTypes
}
```

In this example,` userActivity` captures the base dataset of user actions, which is then reused to identify active users and calculate action statistics. This demonstrates how GQL's local variables enable efficient data reuse and modular query construction.

### The LET Statement: Another Way to Define Variables

The LET statement in GQL defines variables by adding a new column to the current output table, unlike VALUE, which creates procedure-scope visible variables. LET is non-blocking, allowing you to define new variables without interrupting the flow of existing ones, unlike Cypher’s WITH, which requires manual inclusion.

In Cypher, you must explicitly pass all existing variables when defining a new one:

```
MATCH (v)-[e]->(v2)
WITH v, e, v2, 1 AS a
```

Or use `WITH *` to retain all:

```
MATCH (v)-[e]->(v2)
WITH *, 1 AS a
```

In GQL, `LET` simplifies this process:

```
MATCH (v)-[e]->(v2)
LET a = 1
```

Here, `v`, `e`, and `v2` remain accessible, and `a` is seamlessly added. This makes `LET` a more efficient and intuitive choice for variable definition.

## Complex Nested Queries

GQL's `CALL` statement allows you to encapsulate a set of statements into a subquery block, treating them as a single unit that can be referenced by outer statements. This is particularly useful when you need to apply operations on the combined results of multiple queries.

For example, to sort the combined results of two different queries:

```
CALL {
    MATCH (v:Person) RETURN v.name AS name
    UNION
    MATCH (v:City) RETURN v.name AS name
}
ORDER BY name
```

The `CALL` block enables the `ORDER BY` to be applied to the unioned results, rather than just the last query.

# Comparison between GQL and SQL/PGQ

SQL/PGQ extends its graph query capabilities based on SQL, and it shares a read-only graph pattern matching syntax with GQL. However, compared to SQL/PGQ, GQL provides a complete set of read-write syntax, which can better meet the various operation requirements of graph databases.

In addition, although SQL is powerful, its syntax design has some well-known issues. For example, the clause order of SQL is not intuitive and difficult to combine, and users often need to use workarounds to achieve complex requirements. Google recently published an article titled "SQL Has Problems. We Can Fix Them: Pipe Syntax In SQL," pointing out these syntax design issues of SQL and proposing a special pipeline operator aimed at making clauses more linear and combinable, thereby enhancing the flexibility and intuitiveness of SQL.

GQL, on the other hand, is inherently linear and composable. It features orthogonal statements like `MATCH` for graph pattern matching, `FILTER ` for filtering results, `FOR ` for iterating over lists, `LET` for variable definitions, and CALL for complex nested queries.

In addition, GQL includes `INSERT`, `SET` and other DML statements, which can be also elegantly combined in a linear manner with DQL statements.

For example, you can match nodes and then insert an edge between them:

```
MATCH (a:player{id:1, name:"Tim"}(b:player{id:2, name:"Jerry"})
INSERT (a)-[:follow{followness:90}]->(b)
```

The following two figures intuitively demonstrate the differences in syntax between SQL and GQL.

**Figure 1: SQL's Rigid Clause Structure**

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/74ac57c6f7a292190fc6b1ff2b10139f.png)

**Figure 2: GQL's Linear Statement Composition**

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/c5ab0435a24e95b58f87f65bde9d2103.png)

# Looking Forward: The Road Ahead for GQL

The first version of GQL has already included numerous features, showcasing the outstanding contributions of the standard committee members. Personally, I look forward to the possibility of future developments such as subgraph extraction, diverse table construction methods, window functions, and advanced programming constructs like conditional statements, loop statements, and lambda expressions. These enhancements will further solidify GQL's role as a powerful and user-friendly query language。

As a modern, advanced data query language, GQL excels in functionality and ease of use, making it essential for industries managing vast networks, such as telecommunications and social media. Its capability for real-time analytics provides immediate insights, which is crucial for decision-making in dynamic environments. Looking ahead, GQL's ongoing development promises to shape how we interact with data, paving the way for innovations in AI, healthcare, logistics, and beyond.

In conclusion, GQL is set to transform data management, and we eagerly anticipate its future advancements.


GQL, ISO's new graph query language, boosts complex data analysis with advanced pattern matching and versatile queries, vital for network-intensive industries.

Unveiling ISO-GQL: The Future of Graph Query Languages

In today's rapidly evolving business landscape, modern enterprises are constantly seeking innovative solutions to stay competitive and drive success. One of the most significant advancements in data management and analytics this year has been the release of [the first ISO-GQL standard on April 12](https://www.nebula-graph.io/posts/nebulagraph_enterprise_5.0_gql_support). This groundbreaking development in the graph database industry introduces a standardized graph query language, unifying the querying of graph databases and offering immense potential for enterprises.

# Why ISO-GQL is Important to Modern Enterprises

ISO-GQL's release is particularly relevant as it directly addresses several critical factors that underpin the success of modern enterprises. By providing a universal querying language, ISO-GQL ensures consistency and interoperability across different graph database platforms, which is crucial for data-driven decision-making. The efficiency of ISO-GQL in traversing and querying complex networks supports agility and innovation, allowing businesses to quickly adapt to market changes and innovate continuously.

ISO-GQL provides a standardized graph query language that unifies the querying of graph databases, which is crucial for several reasons:

- Standardization: ISO-GQL offers a universal querying language that ensures consistency and interoperability across different graph database platforms.
- Efficiency: Designed specifically for graph data, ISO-GQL enables efficient traversal and querying of complex networks, which is essential for applications requiring deep link analysis.
- Flexibility: ISO-GQL supports flexible data modeling, allowing enterprises to represent and query intricate relationships without the constraints of traditional relational databases.
- Scalability: Graph databases using ISO-GQL can scale horizontally, handling large volumes of interconnected data with ease.
Future-Proofing: Adopting ISO-GQL positions enterprises to stay ahead of technological advancements and industry standards, ensuring long-term compatibility and support.

# Top 10 Use Cases for GQL in Modern Enterprises
## 1. Property Graph Model
ISO-GQL defines a property graph model where nodes (vertices) and edges (relationships) can have properties (key-value pairs) associated with them. In social network analysis, platforms use property graphs to represent users (nodes) and their interactions (edges), with properties like user demographics and interaction types, facilitating detailed analysis of user behavior and network dynamics. LinkedIn uses property graphs to model its professional network, representing users as nodes and connections as edges with properties like job titles, companies, and skills. This allows LinkedIn to efficiently manage and query vast amounts of user data, providing personalized job recommendations and networking suggestions. This capability enables detailed and scalable modeling of complex relationships, enhancing data-driven decision-making and personalized user experiences.

## 2. Graph Pattern Matching (GPM)
ISO-GQL supports complex graph pattern matching, enabling users to specify intricate patterns to search within the graph data. In fraud detection, financial institutions can use GPM to identify suspicious transaction patterns, such as circular payment schemes or unusual connections between accounts, helping to uncover fraudulent activities. For example, JPMorgan Chase uses graph pattern matching to detect fraud by identifying suspicious transaction patterns and relationships between accounts. By analyzing these patterns, the bank can proactively prevent fraudulent activities. This enhances security and compliance by enabling the detection of complex fraud patterns and anomalies in real-time.
## 3. Query Performance and Optimization (QPP)

ISO-GQL includes mechanisms for query performance and optimization, ensuring efficient execution of complex queries. In e-commerce, platforms can optimize recommendation queries to provide real-time, personalized product suggestions to users, enhancing the shopping experience and increasing sales. Amazon optimizes product recommendation queries to provide real-time, personalized suggestions to users based on their browsing and purchase history. This improves customer satisfaction and drives sales by delivering fast, relevant recommendations and insights.

## 4. Data Manipulation

ISO-GQL allows for the creation, updating, and deletion of graph data, enabling dynamic and real-time data management. In IT infrastructure management, companies use data manipulation capabilities to continuously update the status and relationships of IT components, ensuring an accurate and current view of the infrastructure. Netflix uses data manipulation to continuously update its content library and user preferences, ensuring that recommendations are always current and relevant. This supports dynamic and agile data management, allowing enterprises to respond quickly to changing data and user needs.
## 5. Multi-Graph Joint Query
ISO-GQL supports querying across multiple graphs, allowing for the integration and analysis of data from different sources. In healthcare data integration, providers can perform joint queries across patient records, treatment data, and research databases to derive comprehensive insights for personalized patient care. Pfizer performs joint queries across clinical trial data, patient records, and research databases to derive comprehensive insights for drug development and personalized medicine. This facilitates comprehensive data integration and analysis, leading to better-informed decisions and innovative solutions.
## 6. Undirected Graph Support
ISO-GQL supports undirected graphs, which are useful for scenarios where the direction of relationships is not significant. In telecommunications network optimization, undirected graphs can represent symmetrical relationships between network nodes, helping to optimize network performance and reliability. This enhances network optimization and reliability, ensuring robust and efficient communication infrastructures.
## 7. Path Queries
ISO-GQL allows querying for paths between nodes, including shortest paths, all paths, and paths with specific constraints. In supply chain management, companies, such as DHL, use path queries to find the most efficient routes for transporting goods, considering factors like distance, cost, and time, thereby optimizing logistics and reducing costs.
## 8. Schema Flexibility
ISO-GQL supports flexible schema definitions, allowing for dynamic and evolving data models without rigid schemas. In enterprise search, organizations can continuously update and integrate new types of data from various sources, ensuring a comprehensive and up-to-date information retrieval system. Google uses schema flexibility to continuously update and integrate new types of data from various sources into its knowledge graph, enhancing search accuracy and relevance. This supports agile and adaptive data management, enabling enterprises to evolve their data models as needed.
## 9. Declarative Syntax
ISO-GQL provides a declarative query language, making it easier for users to specify what they want to retrieve without detailing how to retrieve it. In enterprise search, employees can use simple and intuitive queries to search across integrated knowledge graphs, retrieving relevant information quickly and accurately without needing deep technical knowledge. Salesforce uses declarative syntax to allow users to easily query customer relationship data, generating insights and reports without needing deep technical expertise. This empowers business users to access and analyze data independently, improving productivity and decision-making.
## 10. ACID Compliance
ISO-GQL ensures ACID (Atomicity, Consistency, Isolation, Durability) compliance, providing reliable transaction processing. In financial services, banks rely on ACID compliance to ensure the integrity and consistency of transactions, even in the event of system failures, thus maintaining trust and reliability in their operations.

# Conclusion
The technical characteristics of ISO-GQL, such as the Property Graph Model, Graph Pattern Matching, Query Performance and Optimization, and others, provide powerful capabilities for managing and querying graph data. These features enable modern enterprises to address complex data challenges across various domains, from fraud detection and social network analysis to supply chain management and IT infrastructure monitoring. By adopting ISO-GQL, enterprises can leverage the full potential of their graph databases, driving innovation, efficiency, and competitive advantage.

[NebulaGraph, as the first distributed graph database with native GQL support, empowers enterprises to unlock the full potential of their data and stay ahead in a competitive landscape.](https://www.nebula-graph.io/posts/enterprise_5.0_GA_announcement) If you’re interested in taking a trial, feel free to [contact us](https://www.nebula-graph.io/contact).


The ISO-GQL release introduces a standardized graph query language, unifying the querying of graph databases and offering immense potential for enterprises.

Top 10 Use Cases for GQL in Modern Enterprises


# What is GQL?

Graph Query Language (GQL) is a specialized language designed for graph databases, paralleling the role that SQL plays in relational databases. 



## Background 

GQL is the second language in the entire database field, having undergone approximately five years from the initial establishment of the project to its final release. Initially, scholar Alastair Green found that the graph database field was fragmented, with various query languages such as  Cypher, GSQL and PGQL. Recognizing the redundancy and need for standardization, Green advocated for a unified, standardized language for querying graph databases. His proposal garnered widespread support, with over 4,000 organizations and individuals participating in a vote, resulting in a 95% approval rate for the creation of a standard language for graph database queries.In May 2024, ISO officially released ISO/IEC GQL.


## Comprehensiveness 

GQL is a comprehensive language that includes Data Manipulation Language (DML), Data Definition Language (DDL), and Data Query Language (DQL), effectively covering all necessary aspects of database operations. This capability allows GQL to support the creation, deletion, modification, and querying of graph data, as well as the definition and modification of the structure of graph databases. GQL aims to provide a unified standard for querying and managing graph databases, thereby enhancing interoperability and reducing dependency on specific graph database vendors.


# What impact will GQL have?



### Enhancing the Importance of Graph Database Technology

The establishment of GQL as a standard underscores the significance of graph database technology. Since 2013, graph databases have been at the forefront of database technology trends.According to Gartner, 80% of data and analytics innovations will use graph technologies by 2025.


### Reducing Learning and Migration Costs

The market is replete with graph database vendors, each with their own query language, leading to high learning and migration costs. GQL standardization mitigates these costs by providing a unified language, facilitating easier transitions and switches between different graph database products.


### Promoting the Application and Development of Graph Databases

Graph databases have evolved through various stages, from initial confusion about the concept to widespread recognition of their problem-solving capabilities. Today, they have proven their value in applications such as public security, recommendation systems, data selection, and supply chain manufacturing. The standardization of GQL is expected to further promote their application and development.


### Encouraging "Thinking in Graph" 

Nowadays, graph databases have passed the capability verification phase and have arrived at a critical time where they are used to think about and solve problems. GQL standardization is crucial for promoting the concept of "Thinking in Graph" , enhancing efficiency and enthusiasm for new database products and languages.


### Active Engagement from Education and Academia

Currently, numerous universities both domestically and internationally are looking to collaborate with NebulaGraph to offer courses related to GQL, preparing students who are about to enter the workforce to understand and utilize this new database language.


# What challenges will GQL face?


Despite its potential, the promotion and application of GQL will face several key challenges:



### Adaptability Challenge for Database Vendors


Database vendors each have their own unique languages and architectural systems. Faced with the implementation of the new GQL language, how will these vendors respond? Some may choose to directly adapt, converting GQL into their own proprietary languages and implementing a conversion mechanism. However, this approach could lead to a significant decrease in performance, and as GQL continues to evolve, this adaptation method may gradually fail to meet new demands. Therefore, for database vendors, aligning their graph database products with GQL is an extremely challenging task. 

But for NebulaGraph, this is merely following a trend of technological integration, as NebulaGraph has been fully committed to supporting GQL for two years. From the very beginning of GQL's proposal and formulation, NebulaGraph has been deeply involved, frequently obtaining the latest information and continuously optimizing its underlying data architecture to ensure outstanding performance when executing GQL.


### Transformation Challenge at the Application Layer

For the application layer, retrofitting existing database products to accommodate GQL presents a challenge. Graph databases are typically used in online applications that require handling a large number of real-time queries, thus demanding extremely high stability. The design logic of most application vendors is to make as few changes as possible to the existing system. Consequently, asking them to replace all query languages with GQL involves a substantial amount of work.


### Talent Reserve Issue

GQL was just released on April 12th of this year, and currently, most people have limited understanding of GQL. Learning a new language and applying it in a real-world work environment requires a considerable amount of time. Therefore, building a talent pool becomes another challenge in promoting GQL.


### Inadequacies within GQL Itself

The V1 version of GQL still has room for improvement in areas such as modifying graph types, indexes, and primary keys, and it is anticipated that future versions will address these issues. We need to allow GQL ample time to become more refined and robust, and in the meantime, we also gain more time to adapt to the requirements of GQL.


# Conclusion


In summary, GQL as the standardized language for graph databases will not only enhance the importance of graph database technology and reduce learning and migration costs but also promote the application and development of graph databases, encourage "Thinking in Graph" and gain active participation from the education and academic sectors. 

Despite the many challenges GQL will face, overall, the future of GQL is full of hope and excitement. Because when we embrace GQL, we are not just adopting a new standard; we are stepping into a future where the possibilities are as vast as the connections within a graph. We must rise to challenges and harness the collective power of innovation to unleash the full potential of GQL.

GQL is setting a new standard for graph databases, unifying query languages and simplifying operations. It promotes "Thinking in Graph," enhancing efficiency and fostering innovation. Despite challenges, GQL's future is bright, offering a dynamic path for data management.

Graph Databases Revolutionized: Why GQL is the New Standard

We are excited to announce the General Availability of NebulaGraph Enterprise v5.0, a groundbreaking release that establishes [NebulaGraph as the first distributed graph database to offer native support for the Graph Query Language (GQL)](https://www.nebula-graph.io/posts/nebulagraph_enterprise_5.0_gql_support).This milestone represents the pinnacle of three years of focused research and development, showcasing our commitment to innovation and excellence in the graph database industry.

Recognizing the importance of GQL early on, we embarked on this ambitious project in November 2021. The initial phase involved a thorough analysis of the GQL standards, followed by extensive design discussions. Over the next few years, we engaged in multiple development iterations and nearly a year of rigorous validation, continuously refining our implementation as the standards evolved. Today, we are proud to unveil NebulaGraph Enterprise v5.0.

# Why Native GQL Support Matters More Than GQL Compatibility

Implementing GQL at the architecture level is a complex and challenging endeavor, requiring a well-designed architecture and significant enhancements across the metadata, computation, and storage layers of the database. You could refer to the enhanced kernel engine in [Announcing NebulaGraph Enterprise v5.0 RC release: Delivering Full-Fledged GQL Support](https://www.nebula-graph.io/posts/rc_release_of_nebulagraph_enterprise_v5.0).

Some might assume that implementing a new query language is as simple as syntactic translation or adaptation. However, our experience tells us otherwise. Pure syntactic adaptation is fraught with challenges. Existing graph languages, such as Gremlin and Cypher, performing syntax translation to GQL might be in lack of catalog and schema management, which are fundamental to GQL as it draws heavily from SQL standards.

Historical attempts to translate query languages have not been successful. For example, some graph database vendors that have dedicated effort to convert Cypher to its own query languages have seen little progress. This underscores the necessity of native GQL support at the architecture level for achieving optimal performance and full compliance with the standards.

# Key Enhancements in NebulaGraph Enterprise v5.0
## Performance Boosts Up to 3x Faster with 90% Less Memory Overhead

[NebulaGraph Enterprise v5.0 delivers a significant performance boost, achieving up to 3x faster query execution while reducing memory overhead by nearly 90%](https://www.nebula-graph.io/posts/technical_preview_nebulagraph_enterprise_v5.0#post-performance). This is evidenced by the results from the LDBC SNB Interactive benchmark, where the Enterprise v5.0 demonstrated an average speedup of 3.01 times compared to the previous version.

## Graph Projection: Efficient Subgraph Analysis

NebulaGraph Enterprise v5.0 introduces support for graph projection, a powerful feature that allows users to create subgraphs based on existing graphs or MATCH queries. This capability enables users to isolate and focus on specific portions of their graph data, making it more efficient to perform complex graph computations and queries. By working with subgraphs, users can significantly reduce the computational overhead and improve query performance, leading to faster insights and more responsive applications. 

## Multi-Level Permission Management
Security and compliance are paramount in modern data management. NebulaGraph Enterprise v5.0 supports multi-level permission management, offering fine-grained access control down to the property level. This hierarchical permission system spans service groups, schema, graphtype/graph, nodetype/edgetype, and property, ensuring that only authorized users can access sensitive data. This feature not only enhances security and compliance with data privacy regulations but also improves administrative efficiency by reducing the risk of human error.
## Query Optimization and Isolation
NebulaGraph Enterprise v5.0 introduces substantial advancements in query optimization and isolation, including query-level resource limits and index hints. The query-level resource limits allow each query statement to utilize a specified amount of CPU and memory resources, and users can individually set the response time for each query. The major benefit of this capability is that it prevents a few resource-intensive queries from monopolizing system resources and potentially bringing down the entire cluster. This granular control ensures that the system remains stable and responsive, even under heavy workloads. The index hints give users more control over query execution. By specifying which indexes to use, users can optimize query performance and ensure that the most efficient execution path is taken. These improvements are crucial for enterprises handling complex relational data where efficiency, consistency, and security are paramount.

## Upgraded UI Experience for Analysts and DBAs
The new UI experience of visualization tools in NebulaGraph Enterprise v5.0 offers significant improvements for both business analysts and DBAs:
- Explorer: Redesigned for better interaction and focus on analysis, the new Explorer interface allows users to save and load historical analysis results, making it easier to track and revisit previous analyses.
- Dashboard: The Dashboard will integrate alert monitoring and diagnostics, enabling quick root cause analysis. It will also support multi-tenant management and resource allocation, providing DBAs with powerful tools to manage and optimize their database environments.

# Conclusion

NebulaGraph Enterprise v5.0 represents a significant advancement in graph database technology, offering native GQL support to meet the growing demands of complex data environments. We invite you to explore the capabilities of NebulaGraph Enterprise v5.0 and join us in advancing the frontiers of graph database technology. [Reach out to us today!](https://www.nebula-graph.io/contact)


We are thrilled to announce that NebulaGraph Enterprise v5.0 is now GA! This groundbreaking release establishes NebulaGraph as the first distributed graph database to offer native support for GQL.

Announcing the General Availability of NebulaGraph Enterprise v5.0: The First Distributed GQL Database

In the digital age, recommendation systems have become an integral part of online experience, driving better user experience and engagement. A recommendation system, often integrated with ad serving systems, is designed to suggest highly relevant content or advertisements to users based on users’ profile and engagement history. However, the complexity of user interactions and preferences demands robust data management solutions. Enter graph databases—an innovative approach that enhances the efficiency and accuracy of recommendation systems. This blog explores how recommendation systems work and how graph databases empower recommendation systems, providing real-life examples and architectural insights.

# What are Recommendation Systems and How They Work
## Key Components of Recommendation Systems:
- User Data: Information about users, including their demographics, behavior, preferences, and past interactions. This data is crucial for understanding user interests and making personalized recommendations.
- Content Data: Information about the content or ads available for recommendation. This includes metadata, categories, keywords, and performance metrics.
- Recommendation Algorithms: The core of the system, these algorithms analyze user and content data to generate personalized recommendations. Common types include collaborative filtering, content-based filtering, and hybrid methods.
- Real-Time Processing: The ability to process data and generate recommendations in real-time, ensuring that suggestions are timely and relevant.
- Feedback Loop: Mechanisms to collect user feedback on recommendations (e.g., clicks, likes, shares) to continuously improve the accuracy and relevance of the system.

## Types of Recommendation Systems
Recommendation systems are powerful tools designed to analyze user behavior and preferences to deliver personalized content and suggestions. These systems operate by collecting extensive data on user interactions, such as browsing history, ratings, and purchase activities. Using this data, recommendation systems employ sophisticated algorithms to identify patterns and relationships within the data. 

Two common approaches are collaborative filtering and content-based filtering. Collaborative filtering analyzes the behavior and preferences of similar users to make recommendations; for example, if two users have a history of liking similar movies, the system might suggest a movie liked by one user to the other. Content-based filtering, on the other hand, focuses on the attributes of items and recommends items that are similar to those a user has previously enjoyed. By combining these methods, recommendation systems can generate highly personalized suggestions that cater to individual tastes and preferences. This tailored approach not only enhances the user experience by presenting relevant content but also drives higher engagement and satisfaction, ultimately benefiting both users and businesses.

# What are Graph Databases
## Definition and Structure
Graph databases are a type of NoSQL database designed to handle and represent complex relationships between data entities. Unlike traditional relational databases that use tables to store data, graph databases use nodes, edges, and properties to create a flexible and highly interconnected data structure. Nodes represent data entities, edges denote the relationships between these entities, and properties provide additional information about the nodes and edges. This structure allows graph databases to efficiently model, store, and query intricate relationships and dependencies within data. Graph databases are quite young compared with relational databases and well-known graph databases include Neo4j, NebulaGraph, Amazon Neptune, and TigerGraph.

They excel at managing complex relationships because their inherent design closely mirrors real-world networks, such as social connections, organizational hierarchies, and financial transactions. This enables rapid traversal and querying of relationships, providing powerful insights and enabling applications like fraud detection, recommendation systems, and network analysis to operate with high performance and scalability.

## Architectural Insights

1. Data Modeling:
    * Nodes: Represent users, items, categories, etc.
    * Edges: Capture interactions such as likes, views, purchases, etc.
    * Example: In a movie recommendation system, nodes could represent users and movies, while edges represent viewing history and ratings.
2. Querying:
    * Graph Traversal Queries: Efficiently find relevant items by traversing the graph.
    * Example: To recommend books, a query might traverse from a user node to books they’ve rated highly, then to other users who rated those books highly, and finally to other books those users have rated highly.
3. Performance Optimization:
    * Indexing and Caching: Improve query performance by indexing frequently accessed nodes and caching results.
    * Example: Caching the results of common recommendation queries can reduce latency and improve user experience.

# How Graph Databases Support Better Recommendation Efficiency and Accuracy

Graph databases, such as [NebulaGraph](https://www.nebula-graph.io/), are particularly well-suited for handling the complex relationships and interconnected data involved in both ad serving and recommendation systems. Here’s how they support efficiency:

1. Complex Relationships and Connections:
    * Graph Structure: Graph databases store data in nodes (entities) and edges (relationships), making it easy to model and query complex relationships.
    * Example: Users, ads, and their interactions can be represented as nodes, with edges capturing relationships like views, clicks, and purchases. [LinkedIn](https://www.linkedin.com/) uses graph databases to model professional connections, endorsements, and job recommendations. By understanding the intricate relationships between users, companies, and skills, LinkedIn can provide highly relevant job suggestions and networking opportunities.
2. Real-Time Recommendations:
    * Fast Traversal: Graph databases excel at traversing relationships quickly, enabling real-time generation of recommendations based on user behavior and preferences.
    * Example: Quickly finding similar users or content based on shared attributes or interactions. [Pinterest](https://www.pinterest.com/) leverages graph databases to recommend pins based on user interactions and the connections between pins, boards, and users. This allows Pinterest to deliver personalized content in real-time, enhancing user engagement.
3. Personalization and Targeting:
    * Rich User Profiles: Graph databases can store and query detailed user profiles, including their connections, behaviors, and preferences, allowing for highly personalized ad targeting.
    * Example: Identifying users with similar browsing patterns and recommending ads that performed well with similar users. [eBay](https://www.ebay.com/) uses graph databases to improve its recommendation engine by analyzing user behavior, purchase history, and item relationships. This enables eBay to provide personalized product suggestions, increasing the likelihood of purchases.
4. Scalability:
    * Handling Large Datasets: Graph databases are designed to handle large volumes of interconnected data, making them suitable for high-traffic environments.
    * Example: Managing millions of users and ads, and their interactions, without performance degradation. [Facebook](https://www.facebook.com/)’s social graph, which models the relationships between billions of users, posts, and interactions, relies on graph databases to provide scalable and efficient recommendations. This ensures that users receive timely and relevant content, even as the platform grows.
5. Data Integration and Enrichment:
    * Combining Data Sources: Graph databases can integrate data from various sources, enriching user profiles and improving recommendation accuracy.
    * Example: Combining browsing history, social media activity, and purchase history to create a comprehensive user profile.
6. Feedback Loop and Continuous Learning:
    * Adaptive Algorithms: Graph databases facilitate the continuous updating of user profiles and recommendation algorithms based on real-time feedback.
    * Example: Adjusting recommendations based on recent user interactions to improve relevance.

# Conclusion
In summary, graph databases enhance the efficiency of ad serving and recommendation systems by providing a powerful way to model, store, and query complex relationships. They enable real-time personalization, effective targeting, and scalability, ultimately leading to better user engagement and optimized ad performance. As demonstrated by industry leaders like LinkedIn, Pinterest, eBay, and Facebook, leveraging graph databases can significantly improve user engagement and satisfaction.


This blog explores how recommendation systems work and how graph databases empower recommendation systems, providing real-life examples and architectural insights.

Posts

Tag