python对象模型映射_我为neo4j做的Python对象映射是否太天真了？

我正在寻找一些关于如何重写应用程序代码的一般性建议，或者是放弃neo4j而使用另一种数据存储模型。这不仅仅是“主观的”，因为它与Python中neo4j驱动程序的特定、正确用法以及它为什么会以我的代码执行的方式来执行，有着重大的关系。在

背景：

我和我的团队一直在使用neo4j存储图形友好型数据，这些数据最初存储在Python对象中。最初，本地/内部专家建议我们使用neo4j，因为它似乎适合我们的数据存储和操作/查询需求。数据总是一组精心构建的本体的具体实例。例如(伪数据)：Superclass1 -contains-> SubclassA

Superclass1 -implements->SubclassB

Superclass1 -isAssociatedWith-> Superclass2

SubclassB -hasColor-> Color1

Color1 -hasLabel-> string::"Red"

…等等，以创建一些相当复杂和冗长的层次结构。在

对于原型，我们使用RDFLib将这些数据存储为语法三元组(subject-&gt；verb/predicate-&gt；object)的序列，并使用RDFLib的图形生成器来构造一个图。在

现在，由于这些信息只是一个复杂的层次结构，我们只需将其存储在一些定制的Python对象中。我们这样做也是为了向其他需要与我们核心服务接口的开发人员提供一个简单的API。我们给他们一个Python库，这个库是我们的对象模型，让他们用数据填充它，或者，我们填充它并把它交给他们以便于阅读，他们用它做他们想做的事情。在

为了永久地存储这些对象，并希望能够加速这些数据的写入和读取(查询/过滤)，我们构建了定制的对象映射代码，该代码利用官方的neo4jpython驱动程序将这些python对象递归地写入和读取到neo4j数据库中。在

问题是：

对于大型和复杂的数据集(例如15k+节点和15k+关系)，我们代码中的对象关系映射(ORM)部分太慢，并且伸缩性较差。但我和我的同事都不是数据库或neo4j方面的专家，我认为我们对于如何完成这个ORM是幼稚的。我们开始怀疑使用neo4j是否有意义，因为更传统的ORMs(例如SQL炼金术)可能是更好的选择。在

例如，我们现在拥有的ORM commit算法是一个递归函数，它可以提交如下对象(伪代码)：

^{pr2}$

这样做太天真了吗？像Py2neo's OGM这样的OGM库会更好吗，尽管我们的库是定制的？我见过this和类似的问题，它们推荐这种或那种OGM方法，但在this文章中，它说根本不要使用OGM。在

我们真的必须实现每个方法和性能基准吗？似乎必须有一些最佳实践(除了使用batch IMPORT，这不适合我们的用例)。我们已经通读了类似链接的文章，并看到了编写更好查询的各种技巧，但是在尝试逐行优化代码之前，最好退一步，更全面地研究一下这种情况。虽然我们可以在一定程度上改进ORM算法。在

使用这样的递归策略在neo4j中写入和读取大型、深层层次的对象是否有意义？Cypher或neo4j驱动程序中有什么东西我们遗漏了吗？还是使用Py2neo的OGM更好？完全放弃neo4j是不是最好？neo4j和Cypher的优点很难忽视，我们的数据似乎很适合图表。谢谢。在