返回首页
最新
你好,HN
在对SQL产生过敏后,我在Dgraph、Typedb和SurrealDB中打开了120多个问题,寻找完美的图数据库。然而,它们都不是为代理(agents)构建的,也无法完全满足我们想要实现的目标:彻底摆脱SQL的遗留,正确地建模现实。因此,我们决定构建BlitzGraph。
在BlitzGraph中,记录(单位)可以属于多种类型(种类),并随着时间的推移而演变。此外,多态关系是第一类公民,多个种类可以扮演相同的角色。这种设计有助于摆脱旧的表格范式,并在整个生命周期中跟踪实体,而无需通过不同表中不同ID的自连接来连接实体。
一个例子:
```json
{ "$id": "amazn", "$kinds": ["Company", "Prospect"], deal: ... } // 第一天
{ "$id": "amazn", "$kinds": ["Company", "Customer"], contract: .. } // 第七天
{ "$id": "amazn", "$kinds": ["Company", "Churned"], churnCause: "..." }, ... // 第八十六天
```
BlitzGraph的不同之处:
- 类似GraphQL的嵌套查询和变更 https://blitzgraph.com/docs
- 多态记录和关系
- 双向O(1)关系
- 具有原生基数验证的引用完整性
- 设计用于AI代理可以程序化构建的JSON查询/变更语言
- 批量查询/变更,无N+1问题
- 内置前端引擎,快速创建仪表板和MVP
- 原生全文搜索、文件存储、计算字段、短暂子空间、单位历史记录...
诚实的比较:
- 与Typedb相比:很棒的数据库,但不适合应用开发。另一方面,我们喜欢并引入了他们的推理理念,以及变更如何智能地执行,而不是逐行执行。
- 与SurrealDB相比:有几个核心差异,一个关键点是我们以拓扑顺序运行验证和转换,而我们的边是第一类公民。
- 与Dgraph相比:他们的一些酷功能,如提交后钩子,附属于GraphQL层,而在BG中它是基础性的。
- Neo4j:如果你尝试过,你就知道了。
- 与Supabase/PG相比:BG在平面查询上较慢,但在嵌套查询上更快。但使用BG,主要是摆脱了表格范式,跳入图形世界,同时能够构建应用。
尚未准备好:
- 虽然BlitzGraph已经是AI代理的优秀内存后端,但我们仍需完成语义搜索引擎。
- 查询规划器尚未优化。
- 云前端尚未具备原生认证引擎。
Beta版本已上线,请尽情测试!
- 公共游乐场:[https://blitzgraph.com/#playground](https://blitzgraph.com/#playground)
- MCP:[https://blitzgraph.com/mcp](https://blitzgraph.com/mcp)