System design suggestions¶

QPS or low-latency first¶

NebulaGraph 3.2.0 is good at handling small requests with high concurrency. In such scenarios, the whole graph is huge, containing maybe trillions of vertices or edges, but the subgraphs accessed by each request are not large (containing millions of vertices or edges), and the latency of a single request is low. The concurrent number of such requests, i.e., the QPS, can be huge.

On the other hand, in interactive analysis scenarios, the request concurrency is usually not high, but the subgraphs accessed by each request are large, with thousands of millions of vertices or edges. To lower the latency of big requests in such scenarios, you can split big requests into multiple small requests in the application, and concurrently send them to multiple graphd processes. This can decrease the memory used by each graphd process as well. Besides, you can use NebulaGraph Algorithm for such scenarios.

Read/write balance. NebulaGraph fits into OLTP scenarios with balanced read/write, i.e., concurrent write and read. It is not suitable for OLAP scenarios that usually need to write once and read many times.
Select different write methods. For large batches of data writing, use SST files. For small batches of data writing, use INSERT.
Run COMPACTION and BALANCE jobs to optimize data format and storage distribution at the right time.
NebulaGraph 3.2.0 does not support transactions and isolation in the relational database and is closer to NoSQL.

Preheat on the application side:

The Grapd process does not support pre-compiling queries and generating corresponding query plans, nor can it cache previous query results.
The Storagd process does not support preheating data. Only the LSM-Tree and BloomFilter of RocksDB are loaded into memory at startup.
Once accessed, vertices and edges are cached respectively in two types of LRU cache of the Storage Service.

Last update: February 19, 2024