最新

你好 HN 在对 SQL 感到厌倦后，我在 Dgraph、Typedb 和 SurrealDB 中提交了 120 多个 issue，寻找完美的图数据库。但它们都不是为代理而设计的，也不是我们想要实现的目标的完美契合：完全抛弃 SQL 遗留，以正确地模拟现实。因此，我们决定构建 BlitzGraph。 在 BlitzGraph 中，记录（单元）可以属于多种类型（种类），并随时间演变。此外，多态关系是第一类公民，多种种类可以扮演相同的角色。这种设计有助于摆脱旧的表范式，并在不进行笨拙的自连接（在其他表中将实体与自身连接，但使用不同的 ID）的情况下，跟踪实体在其整个生命周期中的状态。 例如： ``` { "$id": "amazn", "$kinds": ["Company", "Prospect"], deal: ... } // Day 1 { "$id": "amazn", "$kinds": ["Company", "Customer"], contract: .. } // Day 7 { "$id": "amazn", "$kinds": ["Company", "Churned"], churnCause: "..." }, ... // Day 86 ``` BlitzGraph 的不同之处： ``` - 类似 GraphQL 的嵌套查询和变更 https://blitzgraph.com/docs - 多态记录和关系 - 双向 O(1) 关系 - 具有原生基数验证的引用完整性 - JSON 查询/变更语言，专为 AI 代理能够以编程方式构建而设计 - 批量查询/变更，无 N+1 问题 - 内置前端引擎，用于快速仪表板和 MVP - 原生全文搜索、文件存储、计算字段、临时子空间、单元历史记录... ``` 诚实的比较： - 对比 TypeDB：一个很棒的数据库，但并非理想的应用开发选择。另一方面，我们喜欢并借鉴了他们的推理思想以及变更如何智能地执行，而不是逐行执行。 - 对比 SurrealDB：存在多个核心差异，其中一个关键是我们在拓扑顺序中执行验证和转换，并且我们的边是第一类公民。 - 对比 Dgraph：他们很酷的功能，如提交后钩子，是附加在 GraphQL 层上的，而在 BG 中，它是基础性的。 - 对比 Neo4j：如果你尝试过，你就知道。 - 对比 Supabase/PG：BG 在扁平查询方面较慢，但在嵌套查询方面较快。但使用 BG，你主要可以摆脱表范式，进入图世界，同时能够构建应用程序。 尚未完成： - 虽然 BlitzGraph 已经是 AI 代理出色的内存后端，但我们仍需完成语义搜索引擎。 - 查询规划器尚未优化。 - 云前端目前还没有原生身份验证引擎。 Beta 版本已上线，请尽情测试！ - 公共 Playground：https://blitzgraph.com/#playground - MCP：https://blitzgraph.com/mcp