当前版本：v0.24.1 — 所有版本。在一句话中：Slater 提供不适合内存的图 — 数亿个节点和数十亿条边在低数百MB的RAM中 — 通过标准的Bolt通讯，因此任何neo4j驱动程序都能正常工作，磁盘原生向量搜索与图并列，并且在不放弃这个特性的情况下能够进行实时、持久的写入。驻内存大小由您选择的缓存预算决定，而不是图的大小。快捷方式 为什么Slater存在 读与写 您能获得什么 特性 工作原理 可写层 存储后端 挂载 ACL 健康检查 工作示例 开发 性能 许可 📖 完整手册 为什么Slater存在 一个图数据库将数据存储为节点（东西）及它们之间的关系（边），将关系作为一等公民。当您的问题是关于连接而不是行的时候 — “谁在这个账户三跳之内？”，“这个构建背后的完整依赖链是什么？”，“哪些账户共享一个设备、一个地址和一张卡？”— 这些查询在SQL中通常会变成递归连接的沼泽，但在图中自然出现。关于图数据库最常见的抱怨是它们的扩展性不超过您可以容纳在RAM中的数据。许多图数据库（例如neo4j、Memgraph、FalkorDB等）将整个图保留在内存中：一个40GB的图需要40GB的内存 — 每个实例。如果想要每个区域、每个租户或每个pod都有一个复制品？那账单就要乘以相应的倍数。在超过一定大小后，它们根本无法加载：例如，9000万个节点/ 15亿边的Wikidata图需要约64-128GiB的驻内存，因此内存引擎根本无法打开它。Slater就是对此的回应。它从几百MB的RAM服务同样的9000万节点图，因为它按需从磁盘图像分页图形，而不是保持在内存中 — 因此图的大小和内存费用是解耦的。Slater采取了相反的方式。您一次在离线状态下通过slater-build编译图，生成一个内容寻址的磁盘图像；然后任意数量的Slater服务器通过Bolt服务它（因此您现有的neo4j驱动程序可以正常工作），同时只在内存中保持固定的缓存预算。一个4GB的图和一个400GB的图服务所需的RAM是相同的 — 您可以分散大量便宜的无状态读副本，让存储而非堆来持有图。这使得它非常适合纵深知识图，推荐和身份图，依赖图 — 您想要以低成本频繁查询的任何大型且连接的内容。磁盘原生向量搜索直接与图形相邻，因此同一引擎也是嵌入的检索层。 读与写 Slater是一个读写图数据库。您不需要重建整个图像来更正一个属性、添加一个节点或撤回一条边 — 您可以直接通过Bolt写更改，并且这个更改是持久的。诀窍在于写入从不影响读取路径。写入在不可变核心之上的日志结构合并（LSM）层中累积：一个预写日志和一个内存表，溢出到不可变增量片段，并通过定期整合再折回到一个新的核心。这给您买来了什么：在未写入的图上读取的成本与以前完全相同。一个空的增量是一个单一可预测的分支，而不是合并 — 无论可写层是否开启，读取路径都是字节相同的。对写入的读取成本随增量的大小而变化，而不是图的大小。整个图的答案 — count(*)、标签和关系类型的边际 — 即使有未处理的写入，仍然是元数据读取：增量保持自己的计数器，因此在一个包含91.6M节点核心与50万待处理写入的情况下，count(*)仍然在几十毫秒内回答，而不需要触碰任何块。收到的请求意味着持久性。单个写入者在fsync覆盖写入后排空队列并返回成功。将您的写入分组，它们变得便宜 — 一个写入-UNWIND每批次仅提交一次fsync，而不是每行。业务关键写入，无论是在哪种方言中。MERGE / MATCH … SET / DELETE（以及CREATE / REMOVE、detach delete、关系写入），基于节点的身份属性 — 或等效的ISO GQL数据修改语句（INSERT / SET / REMOVE / DELETE），都将存放在同一路径上。正确的、插入、更新和撤回，基于节点和边，按照您的数据已经存在的方式进行寻址。可写层是可选的（delta.enabled）；如果关闭，Slater将提供纯不可变核心且拒绝写入。有关完整模型，请参见可写层。 关于名称。Slater的名字来自《Archer》中的CIA特工（一个精彩的节目），他坚持只用一个名字 — "Just… Slater" — 并且是我最喜欢的角色之一。参见角色维基页面。 您能获得什么 根据您的缓存预算设置的RAM，而不是图的大小 — 您可以任意分散多个读副本；图形从来不需要适应内存。一个图形的替代品 — 支持Bolt，因此任何标准的neo4j驱动程序（JS、Python、Go等）无需更改即可正常工作。它是Cypher（加上一片ISO GQL，用于读写）；无需学习新事物。实时、持久的写入。