アプリケーションコードを単純なものに書き直す方法、または別のデータストレージモデルのためにneo4jを放棄する方法についての一般的なアドバイスを探しています。これは「主観的」なだけではありません。Python での neo4j ドライバーの特定の正しい使用法と、私のコードで実行する方法に大きく関係しているからです。
バックグラウンド：
私のチームと私は、neo4j を使用して、最初は Python オブジェクトに格納されていたグラフに適したデータを格納しています。当初、地元/社内の専門家から、neo4j を使用するようにアドバイスされました。これは、データ ストレージと操作/クエリの要件に適しているように思われたからです。データは常に、慎重に構築された一連のオントロジーの特定のインスタンスです。例 (疑似データ):
Superclass1 -contains-> SubclassA
Superclass1 -implements->SubclassB
Superclass1 -isAssociatedWith-> Superclass2
SubclassB -hasColor-> Color1
Color1 -hasLabel-> string::"Red"
...など、かなり複雑で冗長な階層を作成します。
プロトタイピングでは、RDFLib を使用してこれらのデータを文法のトリプル (主語->動詞/述語->目的語) のシーケンスとして格納し、RDFLib のグラフ ジェネレーターを使用してグラフを作成しました。
さて、この情報は単なる複雑な階層であるため、いくつかのカスタム Python オブジェクトに格納するだけです。また、コア サービスとのインターフェイスが必要な他の開発者に簡単な API を提供するためにもこれを行います。オブジェクト モデルである Python ライブラリを渡して、データを入力させます。または、読みやすいようにデータを入力して渡すと、彼らはそれを使ってやりたいことを実行します。
これらのオブジェクトを永続的に保存し、できればこれらのデータの書き込みと読み取り (クエリ/フィルタリング) を高速化するために、公式の neo4j python ドライバーを利用してこれらの Python オブジェクトを再帰的に書き込み、読み取るカスタム オブジェクト マッピング コードを作成しました。 /neo4j データベースから。
問題：
大規模で複雑なデータ セット (例: 15k 以上のノードと 15k 以上のリレーション) の場合、コードのオブジェクト リレーショナル マッピング (ORM) 部分は遅すぎ、スケーリングも不十分です。しかし、私も同僚も、データベースや neo4j の専門家ではありません。この ORM を達成する方法について、私たちは単純だと思います。より伝統的な ORM (SQL Alchemy など) の方が良い選択かもしれないのに、neo4j を使用することに意味があるのだろうかと考え始めました。
たとえば、現在の ORM コミット アルゴリズムは、次のようなオブジェクトをコミットする再帰関数です (疑似コード)。
def commit(object):
for childstr in object: # For each child object
child = getattr(object, childstr) # Get the actual object
if attribute is <our object base type): # Open transaction, make nodes and relationship
with session.begin_transaction() as tx:
<construct Cypher query with:
MERGE object (make object node)
MERGE child (make its child node)
MERGE object-[]->child (create relation)
>
tx.run(<All 3 merges>)
commit(child) # Recursively write the child and its children to neo4j
このようにするのは素朴ですか？私たちのライブラリはカスタマイズされていますが、 Py2neo の OGM のような OGM ライブラリの方が優れているでしょうか? これまたはその OGM メソッドを推奨するthisおよび同様の質問を見てきましたが、この記事では、OGM をまったく使用しないように述べています。
パフォーマンスのためにすべてのメソッドとベンチマークを本当に実装する必要がありますか? いくつかのベストプラクティスが必要なようです (ユースケースに合わないバッチ IMPORTを使用する以外に)。また、リンクされているような記事を読み、より良いクエリを作成するためのさまざまなヒントを見てきましたが、コードを行ごとに最適化する前に、一歩下がってケースをより一般的に検討することをお勧めします. ただし、ORM アルゴリズムをある程度改善できることは明らかです。
このような再帰的な戦略を使用して、neo4j との間で大きくて深い階層オブジェクトを読み書きすることは理にかなっていますか? Cypher または neo4j ドライバーに欠けているものはありますか? それとも、Py2neo の OGM のようなものを使用する方がよいでしょうか? neo4jを完全に放棄するのが最善ですか? neo4j と Cypher の利点は無視するのが難しく、私たちのデータはグラフにうまく適合しているようです. ありがとう。