Graph Database Storage Techniques and Practices with Galaxybase

Introduction Chuanglin Technology, founded in 2016, focuses on distributed native graph technology and offers the Galaxybase graph database to customers in banking, power, public security, and internet sectors. The article shares knowledge‑graph storage techniques and practical experiences.

01 RDF and Property Graph The article explains that modern applications generate massive relational data requiring connectivity analysis rather than mere correlation. RDF uses triples (subject‑predicate‑object) and supports multi‑value attributes, while property graphs represent entities as vertices, relationships as edges, and store attributes as key‑value pairs on vertices or edges. Property graphs allow multiple edges of the same type between two vertices and support complex attribute types.

02 Core Goals of Graph Database Storage The primary goal is to enable index‑free adjacency, allowing fast neighbor iteration without external indexes. Graph databases store edges together with their source vertices, achieving high‑performance multi‑hop queries compared to relational databases.

03 Mainstream Storage Solutions Three categories are described:

Native graph storage that implements index‑free adjacency directly in the storage layer.

Non‑native storage using third‑party components that approximate index‑free adjacency.

Fully non‑native storage built on relational, document, or other databases, providing a graph‑like interface but relying on external indexes.

Specific implementations include:

Array‑based storage where vertices and edges are stored sequentially; challenges arise with variable‑length attributes, solved by using offsets or separate attribute files.

Linked‑list storage where IDs are stored for vertices, edges, and attributes, enabling O(1) neighbor iteration but causing random disk reads that require effective caching.

LSM‑Tree based storage that writes sequentially to SST files; designing edge keys to keep a vertex’s edges contiguous enables index‑free adjacency, though read performance depends on compaction.

Each method has trade‑offs between write speed, read latency, and complexity.

04 Galaxybase Practical Deployment Galaxybase is a high‑performance distributed native graph platform offering millisecond‑level deep‑chain analysis, dynamic online scaling, and support for trillion‑scale graphs. It includes built‑in distributed graph algorithms, a visual knowledge‑center, and APIs for Java, Python, Go, and REST. The system supports heterogeneous data sources, data compression, and has achieved record performance in LDBC SNB benchmarks.

05 Q&A

Q1: How to handle attribute values larger than 4 KB? A1: Large attributes should be stored outside the graph or in a separate area; the graph engine is optimized for neighbor lookups, not large text blobs.

Q2: How to handle path queries with super‑nodes? A2: Return all paths only when the result set is manageable; otherwise perform aggregations or write results to files.

Q3: Impact of data compression on performance? A3: Compression saves disk space but adds CPU overhead; choose based on whether read/write latency or storage cost is more critical.

Q4: How to achieve real‑time graph computation without ETL? A4: Galaxybase’s integrated storage and compute layers allow snapshot‑based graph processing without separate ETL, ensuring consistency.

Overall, the article provides a comprehensive overview of graph data models, storage architectures, and real‑world implementation details of a commercial graph database.