我有一个客户知道他的数据模型是有向无环图。我们一直在使用节点集合和边的中间表，并且性能非常好。在当前的实现中，我们有不到 100,000 个数据节点，尽管这可能会增长一到两个数量级。他最近开始相信，既然我们有图，那么图数据库（如 Neo4J 或 Titan）会“更好”。
面向图的数据库实际上解决了哪些 SQL 无法解决的问题，或者需要 SQL 客户端进行更多繁重工作的问题？据我所知，路径发现似乎就是它，但这不可能是全部。
问问题
735 次
3 回答
1
在关系数据库中，节点和边将通过它们具有的一些共同值相关联。搜索节点或边通常会涉及查询该值的索引。
在图形数据库中，节点和边直接通过关系数据库用来维护索引内部结构的同一类内部数据库结构相关联。因此，从一个节点或从一个边找到一个节点更像是在关系索引中深入一层，而不考虑节点的数量；而如果您在关系数据库中有数百万个节点，则索引将是几个级别的深度。
于 2012-11-20T21:35:41.827 回答
0
简而言之，如果它没有损坏，请不要修复它。如果您或您的客户不清楚优势，只需权衡迁移成本与图形数据库的这种不明确的优势。
由于没有使用上述图形数据库的经验，我只能假设您可以从此类数据库中获得更快的开发，因为您的数据库将更适合您拥有的数据类型。我一直在使用 MongoDB，对我来说最重要的是开发速度，因为查询/写入数据库的简单性，其次是更丰富的文档结构，而无需定义任何模式。您还可以获得一些惊人的功能，例如超级简单的复制、自动故障转移、自动分片等，但在您只有 10 万个文档的情况下，您不太可能很快考虑此类问题。所有主流的关系数据库都可以在小型服务器上运行，并且可以很好地处理这么多的文档。
于 2012-11-20T23:14:20.887 回答
0
实际上它是真的，就像 mongo 具有内置的“地理空间”数据库功能，所以它不必像你想用 mysql 那样处理。您提到的两个数据库（我与 titan 合作过）更适合绘图，并且对您的 php 或 db 语句不会那么苛刻。
于 2012-11-20T21:28:55.367 回答