图存储，简单说就是专门存图数据的“仓库”，全称叫作“图数据库存储引擎”。它负责将图数据——节点、关系、属性等，以适合图结构的数据格式，存储在磁盘或内存中，并确保数据的一致性、完整性和可访问性，要用的时候能方便取出来。

图存储的基础概念

目前传统数据库存储引擎中最主流的有两大类：基于 B-Tree 的存储引擎和基于 LSM-Tree 的存储引擎。除了这两类，还有许多其他存储方式，比如：

基于文件的，可分为有序和无序两种；

基于堆的（这也是一种文件）；

基于哈希桶（hash buckets）的；

基于索引顺序存储（ISAM）文件系统的。

若按照数据存储的排列方式，还能分为行存储、列存储、KV 存储、关联存储等类型，这些不同的存储方式在图存储中也可能根据具体需求被采用。

图1：通用数据库存储引擎示意图

图存储引擎是图数据库的 “数据基石”，核心职责是高效存储图的核心元素（顶点和边），并与计算引擎、数据管理等组件协同，确保数据的持久化与事务正确性（ACID）。其原理可从 “存什么”、“怎么存”、“不同场景下的存储逻辑” 三方面拆解：

第一方面：核心存储对象：顶点和边

图的本质是由 “顶点” 和 “边” 构成的关系网络，存储引擎首先要精准捕捉这两类元素的结构特点：

• 顶点：每个顶点可以看作内部元素有着某种规则排列的数组，多个顶点的组合就是一个二维数组。如果考虑到顶点的动态变化（增删改查等涉及读、更新、插入等操作）的需求，向量数组是一种可能的方式。
• 边：比顶点更复杂的 “关系载体”，除了唯一 ID，还需记录起点 ID、终点 ID（明确连接对象）、方向（有向 / 无向）和属性（如权重、时间戳）。用二维数组可存储边的基础信息，但实际中更关注效率：如何少占空间、快速查询（比如 “某顶点的所有邻接边”）、高效维护索引。

第二方面：存储方式：静态与动态场景的分野

存储引擎的设计需适配数据是否变化，两种场景的逻辑大不相同：

• 静态图（数据不变）：若顶点和边的数量、属性完全固定（如历史关系图谱），无需复杂设计——可直接复用传统存储方式，比如用磁盘文件按固定格式存储顶点数组和边的三元组（起点、终点、属性），或借助 MySQL 的 InnoDB、MyISAM 等传统引擎，用表结构映射图元素。此时 “存” 的逻辑简单，能满足基本需求即可。
• 动态图（数据常变）：商业场景中，数据几乎都在动态更新（新增用户、删除关系等），这就要求存储引擎支持高效的增删改查。此时出现两种核心架构：
  非原生图：用传统数据库（如 MySQL、HBase、Cassandra）的表结构存储 ——顶点放 “顶点表”，边放 “边表”。但查询关系时需多表关联，效率极低。比如查 “007 号员工所属部门”，需先查员工表定位 007，再查 “员工 - 部门对照表” 找部门 ID，最后查部门表取名称，多步关联耗时高。

第三方面：与系统组件的协同：不止 “存”，更要 “好用”

图存储引擎不是孤立的，需与计算引擎、数据管理等组件配合，支撑整个图数据库的运转：

· 计算引擎所需的临时数据、索引结构（如加速查询的索引），都基于存储引擎中的顶点和边衍生而来；

· 需保证与计算引擎的数据一致性，比如计算时读取的数据必须是存储引擎中最新的，且操作需满足 ACID（比如 “添加一条关系” 要么完全成功，要么完全失败，避免数据混乱）。