【发布时间】:2013-10-14 20:09:51
【问题描述】:
尽管我在这里阅读了另一个建议不要同时使用 neo4j 和 mysql (neo4j - graph database along with a relational database?) 的问题,但我想知道哪种方法最适合具有可以像图形一样建模的数据的数据集,其余看起来相关的。由于某些原因,我无法发布我正在使用的数据类型。
我可以将关系部分硬塞到 neo4j 中,但它看起来既丑陋又复杂,这是我想避免的。
另一方面,如果我同时使用两者,我将不得不进行双倍的查询才能获得结果,从而降低性能(假设数据库位于不同机器上的云中)。
我不能单独使用 mysql,因为其中一个查询需要大约 20-30 的深度,我认为 mysql 无法处理。
你们有没有遇到过这样的情况?如果有,你是怎么解决的?
【问题讨论】:
-
两个 dbs 听起来像是一场噩梦。你能重构关系僵硬以类似 neo4j 的方式工作吗?我不是在说图形,我说的是像其他 nosql 数据库一样以文档为中心,例如 mongo。 Neo4j 的工作方式几乎相同,但最重要的是图形功能。
-
好消息是我还没有开始,所以不需要任何重构:)。 mongo 在图形功能方面与 neo4j 相比如何?具体来说,它是否非常适合 30 个节点的 DFS?
-
Mongo 没有任何图形功能。我想说的是,如果这是您需要做的,您可以在 neo4j 的 mongo 中做所有可以做的事情。 (存储文档并索引它们的字段)。我的意思是,如果您可以将关系存储重构为文档存储,那您就可以了。您可以在文档存储中建立关系。
-
这涉及在 mongo 中建模一对多关系,但同样适用于 neo4j。 docs.mongodb.org/manual/tutorial/…(那里有其他关系类型的文章)
-
很好,但性能是该项目的重中之重,同时易于编程/使用。从你所说的,听起来我必须自己构建“图形功能”部分,不是吗?