图形数据库在关系数据库中解决困难的是什么？

我有一位客户，他明白他的数据模型是一个有向无环图。我们一直在处理节点集合和边缘中间表，并且性能非常好。在目前的实施中，我们有不到10万个数据节点，尽管这可能会增长一到两个数量级。他最近确信，由于我们有一张图表，图形数据库（如Neo4J或Titan）会更好。图形数据库在关系数据库中解决困难的是什么？

面向图的数据库实际上解决了哪些问题无法用SQL解决，还是需要从SQL客户端进行更多的繁重工作？从我所看到的路径发现似乎是它，但这不可能是整个故事。

来源

2012-11-20 Elf Sternberg

我相信这不是“节点数量”，而是各种查询所需的“遍历深度”。当然，像Nested Set和Hierarchical IDs和Connects这样的关系数据库方法，通常都是为了与树协同工作而设计的，不一定限制较少[DAGs]（http://en.wikipedia.org/wiki/Directed_acyclic_graph）。当然，由于帖子提示单独的节点/边缘表，我怀疑DAG已经被使用 - 然后又回溯到遍历深度。 – 2012-11-20 21:30:43

在关系数据库中，节点和边将通过它们具有的某些值相关联。搜索节点或边缘通常涉及查询此值的索引。

在图形数据库中，节点和边直接与同一类内部数据库结构相关，关系数据库用它来维护索引的内部结构。因此，从节点或边缘找到边缘更像是在关系索引中深入一层，而不考虑节点的数量;而如果关系数据库中有数百万个节点，则索引将会有几个级别的深度。

来源

2012-11-20 21:35:41 antlersoft

实际上它是真实的，就像mongo具有内置的“地理空间”数据库功能一样，所以它不需要像使用mysql那样处理。你提到的两个数据库（与泰坦一起工作）只是更好的图形，它不会对你的php或db语句如此苛刻。

来源

2012-11-20 21:28:55 Dnaso

总之，如果没有损坏，不要修复它。如果您或您的客户的优势不明确，那么只需将迁移成本与图表数据库的这种不明确的优势相比较即可。

没有上述图形数据库的经验，我只能假设你可以从这样的数据库中获得更快的开发，因为你的数据库将更适合你所拥有的数据类型。我一直在使用MongoDB，因为查询/写入数据库非常简单，后面就是更丰富的文档结构，而无需定义任何模式，因此对我来说，蛋糕上的樱桃已经成为开发速度。您还可以获得一些令人惊叹的功能，如超级简单复制，自动故障转移，自动分片等，但就您的情况而言，只有10万份文档，您很快就不会考虑这类问题。所有的主流关系数据库都可以在小型服务器上运行，并且可以使用大量的文档运行良好。

来源

2012-11-20 23:14:20 snez

图形数据库在关系数据库中解决困难的是什么？

回答

相关问题