Neomodel Python OGM: Neo4j モデリングの深掘り

ホーム » Python » Neomodel Python OGM: Neo4j モデリングの深掘り

Neomodel は、通常の Python コードを記述するのと同じくらい自然に Neo4j を操作できるように設計された Python オブジェクト グラフ マッパー (OGM) です。 Cypherクエリを常に手動で作成する代わりに、クラス、フィールド、リレーションシップを使用してグラフドメインを記述し、PythonオブジェクトとNeo4jノードおよびリレーションシップ間のマッピングをneomodelに任せます。neomodelは公式Neo4j Pythonドライバー上に構築されており、薄い抽象化レイヤーのみを備えているため、パフォーマンスをあまり犠牲にすることなく、高度な利便性を実現できます。

Neo4j Labs エコシステムの一部として、neomodel は積極的にメンテナンスされ、最新の Python および Neo4j バージョンを完全にサポートし、同期 API と非同期 API の両方を提供します。 Djangoのような使い慣れたモデル定義、豊富なクエリAPI、カーディナリティによるスキーマの強制、組み込みのトランザクション、そしてDjangoとの緊密な統合を実現します。 django_neomodel同時に、ハードウェアに近い状態を維持します。パフォーマンスやクエリの複雑さによって必要な場合は、いつでも生の Cypher に切り替えることができます。

ネオモデルとは何か、そしてなぜそれが重要なのか

Neomodel は、Python クラスとグラフ構造を橋渡しする、Neo4j グラフ データベース用のオブジェクト グラフ マッパーです。 Cypher文字列を使って手動でノードや関係を作成するのではなく、ドメインエンティティを表すPythonクラスを定義し、neomodelがそれらをNeo4jのインデックス付きプロパティと制約を持つラベル付きノードに変換します。これは公式の neo4j-python-driverなので、その動作はドライバーを直接使用する場合の動作と一致します。

このライブラリは、堅牢な継承、フック、検証を備えた使い慣れたクラスベースのモデリング スタイルに重点を置いています。 このアプローチは、Django ORMやその他のPython ORMに慣れている開発者にとって特に便利です。モデルクラスの属性はNeo4jのプロパティに対応し、特別なリレーションシップフィールドはグラフのエッジを捕捉します。この設定により、グラフのトラバーサルは、毎回冗長なCypherを書くのではなく、オブジェクトの属性をたどるだけで済みます。

内部的には、neomodel は、生の Cypher をすぐに強制することなく、一般的なグラフ アクセス パターンをカバーする強力なクエリ API を提供します。 Pythonインターフェースを通じて、フィルタリング、順序付け、関係のトラバース、ノードセットのスライス、そして高度な操作を実行できます。必要に応じて、 cypher_query カスタムクエリを実行し、返された結果を直接操作するためのヘルパー。

もう 1 つの中心的な機能は、関係とプロパティ制約のカーディナリティ ルールによるスキーマの適用です。 リレーションシップフィールドにカーディナリティ（例えば、0以上、1以上、1）を直接指定することで、グラフの構造的な期待値を強制し、neomodel を利用してデータの不整合を回避できます。インデックスと制約はモデル定義に基づいて自動的に作成され、それらをデータベースに適用または削除するための CLI ユーティリティも用意されています。

Neomodel はトランザクション作業も完全にサポートしており、マルチスレッド環境で安全に使用できます。 トランザクションは予測可能な方法でオープンおよびコミットでき、公式ドライバのラップは意図的に薄く設計されているため、パフォーマンスのオーバーヘッドは小さく抑えられています。Locustなどのツールを用いたベンチマークでは、neomodelの抽象化レイヤーによって、同時負荷時でもレイテンシが最小限に抑えられることが示されています。

バージョンサポート、SemVer、および構成

最新のネオモデル リリースは、従来の major.minor.patch パターンを使用したセマンティック バージョン管理 (SemVer) に従います。 つまり、互換性を損なう変更はメジャーバージョンアップ時にのみ導入され、動作に影響のない新機能はマイナーリリースで提供され、バグ修正はパッチバージョンとして提供されます。このバージョン管理戦略により、特に本番システムにおいて、アップグレードの計画が容易になります。

6.x シリーズでは、neomodel は、最も本格的なデプロイメントで実行されているものと一致するように、最新の Python および Neo4j バージョンをターゲットにしています。 具体的には、neomodel 6.x は Python 3.10 以降を必要とし、Neo4j 5.x、Neo4j 4.4 LTS、そしてより新しい Neo4j 2025.xx ラインをサポートしています。Neo4j Community、Neo4j Enterprise、そして Neo4j Aura（ホスト型サービス）の両方をサポートしているため、データベースのホスティング方法と場所を柔軟に選択できます。

古い環境の場合、以前の neomodel ブランチは、従来の Python と Neo4j の組み合わせを引き続きカバーします。 5.xラインはPython 3.8以降とNeo4j 5.xおよび4.4 (LTS) をサポートし、4.xラインはPython 3.7から3.10までとNeo4j 4.x（neomodel 4.0.10使用時は4.4 LTSを含む）をサポートします。この互換性により、既存の環境を維持しながら段階的な移行が可能になります。

neomodel 6 以降では、実行時検証と環境変数のサポートを備えた最新の型注釈付きデータクラスを介して構成が処理されます。 散在するアドホックな設定の代わりに、設定フィールドは更新時に型チェックや論理制約を含む検証が行われます。環境変数を使用して設定を簡単に上書きできるため、コンテナ化されたデプロイメントやクラウド環境と連携して動作します。

6.0 リリースでは、API をより予測可能にするために、明示的な重大な変更と動作の修正も導入されています。 例えば、Cypherのリスト解決は期待される深さを返すようになりました。次のようなクエリは RETURN collect(node) にマッピングされます results[0][0] 以前の直感的でない results[0][0][0] 構造。カーディナリティチェックはより厳格になり、デフォルトで有効になり、いくつかのスタンドアロンヘルパー関数が中央に移動されました。 Database() および AsyncDatabase() シングルトンクラス。

インストールとセットアップ

neomodel をインストールする推奨方法は、好みのパッケージ マネージャーを使用して PyPI から直接インストールすることです。 簡単なインストールコマンドで仮想環境に追加し、通常の依存関係管理ツールを使ってアップグレードを管理できます。最新の変更が必要な場合や、貢献したい場合は、GitHubリポジトリから直接インストールすることも可能です。

ネオモデル コードを実行する前に、ライブラリが Neo4j インスタンスに到達する方法を認識できるように接続 URL を構成する必要があります。 この設定には通常、スキーム（BoltまたはNeo4j）、ホスト、ポート、ユーザー名、パスワード、オプションのデータベース名が含まれます。Djangoプロジェクトの場合、この設定は通常、 settings.py そのため、アプリケーションの起動時にすぐに初期化されます。

Neo4j サーバーを新しくインストールした場合は、Neo4j ブラウザまたは管理パネルを使用してデフォルトのパスワードを変更する必要があります。 デフォルトでは、そのパネルは http://localhost:7474パスワードを更新して確認したら dbms.security.auth_enabled=true データベース構成では、neomodel から接続する準備が整いました。

開発とテストでは、別々の Neo4j データベースと専用の資格情報を使用するのが一般的です。 Neomodel独自のテストスイートはNeo4j 4+データベースを想定しており、接続には特定の環境変数に依存しています。新しいデータベースでテストを実行すると、テストスイートはパスワードを次のように設定します。 test デフォルトでは、既存のデータセットが検出されると、リセット フラグを明示的に渡さない限り続行が拒否され、偶発的なデータ損失を回避できます。

複数の Python および Neo4j バージョンにわたって neomodel をテストする場合、Docker と docker-compose を使用するとすべてを自動的に調整できます。 このプロジェクトでは、インタープリターのバージョンとNeo4jのリリースをマトリックスにして、統合テストを一貫して実行するための設定を提供しています。これは、複数のサポートバージョンで動作する必要がある機能を提供する場合に特に便利です。

コア機能: モデル、スキーマ、インデックス

Neomodel の中心は、Neo4j ノード ラベルとリレーションシップに直接マップされるクラスベースのモデル定義にあります。 通常、ノードクラスは以下から派生します。 StructuredNode、および関係クラス StructuredRelノード フィールドは、Neo4j でのデータの保存方法と検証方法を制御できる、ネオモデル固有のプロパティ タイプを使用して定義されます。

各モデル クラスは Neo4j のラベルになり、neomodel は定義に基づいてインデックスと制約を自動的に管理します。 つまり、一意性、必須プロパティ、インデックス付きフィールドはすべてPythonで指定でき、スキーマ作成用のCypherコマンドを手動で作成する必要はありません。neomodelは、モデルメタデータを適切なNeo4jスキーマ操作に変換します。

関係は、次のような特別な記述子を使用してノードクラスに添付されます。 RelationshipTo, RelationshipFrom, Relationship. これらの記述子は、関係の種類、カーディナリティ、およびトラバーサル方向を定義します。 RelationshipTo および RelationshipFrom Pythonの観点から一方向のナビゲーションを表現し、 Relationship Neo4j 自体は常に方向を指定して関係を保存しますが、コードから両方向にナビゲート可能な関係として扱いたい場合に使用します。

関係が論理的に双方向である場合、2つのミラーフィールドを作成せず、単一の Relationship を代わりにお使いください。 これにより、Pythonコード内で双方向のトラバースを可能にしながら、モデルをクリーンで一貫性のある状態に保つことができます。Neo4jは内部的に有向関係を保持しますが、neomodelの抽象化により、トラバース時にその詳細は隠されます。

ノード構造が事前に完全には分かっていないシナリオでは、neomodelは SemiStructuredNode 基本クラス。 この型から派生したクラスは、モデル内で明示的に定義されていない「アドホック」なプロパティを保持できます。これは、グラフスキーマが頻繁に変更される場合や、モデルを毎回リファクタリングすることなく、時折追加属性を追加する必要がある場合に特に便利です。

カーディナリティ ルールは、ノード間の許容される関係の数を強制するもので、ネオモデル 6 ではより厳格なチェックによってサポートされるようになりました。 ソフトカーディナリティチェックはすべてのリレーションシップカーディナリティで利用可能で、厳格なチェックはデフォルトで有効になっています。データが設定されたリレーションシップルールに違反している場合、neomodel は不整合な構造を黙って放置するのではなく、その問題を表面化させます。

自動スキーマ管理と検査

モデルを定義または更新したら、対応する制約とインデックスを Neo4j データベースに適用する必要があります。 Neomodelには、 neomodel_install_labels モデルをスキャンし、必要なインデックスと制約を作成または更新します。スキーマを変更した後は、このスクリプトを実行し、処理されたクラスの数を確認して、すべてが同期されていることを確認してください。

ネオモデルによって管理されている制約とインデックスを消去する必要がある場合は、補完的なコマンドがあります。 neomodel_remove_labels. このスクリプトは、neomodel が以前にインストールした既存の制約とインデックスをすべて自動的に削除します。また、削除された内容を出力するため、操作の影響を明確に確認できます。

両方のスキーマ管理コマンドは、 --db 引数とデフォルト NEO4J_BOLT_URL 指定されていない場合は環境変数。 この動作により、資格情報や接続の詳細がコマンドライン履歴に残らず、環境変数によるシンプルな設定が可能になります。また、自動化スクリプトやデプロイメントスクリプトの管理も容易になります。

スキーマ作成に加えて、neomodel には、既存のグラフをリバース エンジニアリングしてモデル ファイルを生成できるデータベース検査ツールが含まれています。 使い方 inspect コマンド（Neo4jにAPOCプロシージャがインストールされている必要があります）を使用すると、データベースをスキャンして、 models.py 対象ディレクトリの下のファイル、例えば yourapp生成されたファイルには、検出されたグラフ構造に一致するインポート、ノード クラス定義、および関係定義が含まれます。

関係プロパティとカーディナリティスキャンをスキップすることで、大規模なグラフの検査プロセスを調整できます。 数十万のノードと100万以上のリレーションシップを持つデータベースの場合、フルスキャンには数十秒かかることがあります。 --no-rel-props および --no-rel-cardinality 詳細な分析を省略し、関係フィールドを生成しながらもカーディナリティを ZeroOrMore などの汎用値にデフォルト設定することで、処理速度を向上させます。

ネオモデルクエリAPIの操作

Neomodel のクエリ API を使用すると、Cypher を直接記述するのではなく、モデル クラスで Python メソッドを介して豊富なグラフ クエリを実行できます。 各モデルは、 .nodes 対応するラベルを持つノードの集合を表す、マネージャーのような属性です。そこから、グラフの基となるデータのカウント、フィルタリング、順序付け、スライス、取得を行うことができます。

呼び出し len(MyModel.nodes) 対応するラベルを持つノードをカウントするCypherクエリをトリガーします MyModel. これは、Python構文を離れることなく、直感的にカウントを取得できる方法です。ノードセットが既にフィルタリングされている場合、カウントはそれらのフィルターに一致するノードのみを反映し、一般的なORMに期待される動作と一致します。

スライスはノード セット上で直接サポートされているため、バッチ処理された結果を処理する場合に非常に便利です。 次のような表現 MyModel.nodes[0:10] スライスされたノードセットを返します。このノードセットは反復処理したり、追加のフィルターを使ってさらに連鎖させたりできます。スライスは生のリストをすぐに返すのではなく、別のノードセットオブジェクトを返すため、複雑なクエリを段階的に構築できます。

ノード セットは反復とブール チェックをサポートしますが、長さと真偽の演算は終端です。 評価したら len() あるいは、ブールコンテキストでノードセットを使用すると、連鎖可能な別のクエリオブジェクトではなく、具体的な結果を返す評価ステップを効果的にトリガーすることになります。この設計は、Pythonのイディオムとクエリ構築の遅延特性のバランスをとっています。

実際のオブジェクトを取得するには、通常次のようなメソッドを使用します。 .all() および .get() .nodes マネージャー。 これらのメソッドは、 lazy=True 引数を指定すると、完全なオブジェクトとそのすべてのプロパティではなく、ノードIDのみを返します。これは、データ転送を最小限に抑えたい場合や、IDに基づいて手動で後続のクエリを実行したい場合に役立ちます。

作成、更新、削除、関係

ネオモデルでノードを作成するには、モデルクラスをインスタンス化して呼び出すだけです。 save(). プロパティとデフォルトを定義したら、必要なフィールド値を持つインスタンスを構築し、 saveすると、neomodel は Neo4j 内の対応するノードを作成または更新します。これは、ほとんどの ORM が永続性を処理する方法と似ています。

ノードの更新は同じパターンに従います。インスタンスを取得し、その属性に新しい値を割り当て、再度保存します。 Neomodelは、既存ノードの変更されたプロパティのみを変更する適切なCypherを生成します。このアプローチにより、コードは簡潔になり、更新操作の詳細をビジネスロジックから切り離すことができます。

ノードの削除も直接的に行えます。インスタンスを作成したら、 delete() 方法。 これによりノードが削除され、リレーションシップの設定とデータベースの制約によっては、関連付けられたリレーションシップも削除される可能性があります。より高度な動作やログ記録を行うには、削除前フック​​と削除後フックを定義できます。

ノード間の関係は、関係フィールドと次のような便利なメソッドを通じて管理されます。 connect(). ノードが2つできたら、次のように呼び出すことができます。 actor.movies.connect(movie) グラフ内に適切な関係インスタンスを作成します。関係プロパティは次のようにモデル化できます。 StructuredRelベースのクラスにより、エッジに属性を格納する余地も得られます。

リレーションシップ属性に従うか、リレーションシップ間でクエリ フィルターを組み合わせることで、より複雑なグラフ トラバーサルを実現できます。 例えば、 Entity ノードセットを読み込み、プロパティでフィルタリングした後、関連ノードを走査してそれらの属性でもフィルタリングします。これにより、内部的にCypherクエリが徐々に構築され、neomodelがユーザーに代わって実行します。

非同期ネオモデルとトランスパイルされた同期API

Neomodel には、公式 Neo4j Python ドライバーの非同期機能に基づいて構築された非同期サポートが含まれています。 つまり、Neo4j 操作を最新の非同期 Python フレームワークとサービスに統合して、多数の I/O バウンド操作を伴うワークロードの同時実行性を最大限に活用できます。

Locust などのツールを使用したパフォーマンス テストでは、非同期ネオモデルを同時に使用すると、シリアル クエリと、同時に実行される同期ネオモデル呼び出しの両方よりもパフォーマンスが優れていることが示されています。 多くのグラフ操作にはネットワーク I/O とデータベース応答の待機が伴うため、イベント ループで複数のクエリを一度に処理すると、スループットとリソース使用率が向上します。

内部的には、neomodel は、非同期コードを同期コードに変換するトランスパイル手順を使用して、非同期 API と同期 API の整合性を維持します。 専用のライブラリを使用して自動的にストリップする await キーワード、クラス名の変更（例： Async プレフィックスなど）を変更し、変更などのターゲット置換を実行します。 adb 〜へ db or mark_async_test 〜へ mark_sync_testこのアプローチにより、完全に別個の 2 つのコードベースを維持する必要がなくなります。

貢献する際は、主に以下の非同期実装に取り​​組みます。 neomodel/async_ 次に、提供されているトランスパイル スクリプトを実行して、同期バリアントを生成します。 このステップを自動化し、両方のバージョンが同期された状態を維持するために、事前コミットフックを利用することもできます。多くの場合、ビジネスロジックは非同期レイヤーに一度だけ記述するだけで済みます。

一部の機能は非同期のみ、または同期のみを目的としている場合があり、neomodel はそれらのコード パスを分離するためのユーティリティ パターン (公式 Neo4j ドライバーに触発されたもの) を公開します。 これにより、API サーフェス全体の一貫性を保ちながら、2 つのモード間で異なる動作を定義できます。match API をカバーするようなテストモジュールは、非同期コードがどのようにトランスパイルされ、結果として得られる同期コードがどのように動作するかをデモンストレーションします。

データベースとAsyncDatabaseシングルトン

ネオモデル6では、 Database() および AsyncDatabase() クラスは、グローバル操作の処理方法を明確にするために、真のシングルトンとして実装されます。 スタンドアロンのユーティリティ関数を分散させるのではなく、neomodel ではデータベース全体の操作をこれらのシングルトン インスタンスにグループ化することで、API の検出性と一貫性を高めています。

いくつかのレガシー関数は、 Database() クラスがグローバル名前空間から削除されました。 例としては、 change_neo4j_password, clear_neo4j_database, drop_constraints, drop_indexes, remove_all_labels, install_labels, install_all_labels非同期の対応は、 AsyncDatabase() シングルトン、通常は adb 非同期コンテキストで。

この再設計により、データベース レベルの操作に関するメンタル モデルが簡素化され、構成とグローバル状態の処理方法における曖昧さが回避されます。 同期モードと非同期モードの両方が同様の構造を共有するようにすることで、あるアプローチから別のアプローチに安全に切り替えることができるか、または大規模なアプリケーションのさまざまな部分でそれらを並行して実行できるかを判断することも容易になります。

さらに、6.0リリースでは、 merge_by バッチ操作のパラメータ。ノードとリレーションシップのマージ方法をより細かく制御できます。 バッチマージの一意性を定義するラベルとプロパティ キーをカスタマイズできます。これは、大量のデータ取り込みや同期タスクを処理するときに重要です。

Django の統合と実際の使用法

NeomodelはDjangoときれいに統合されており、 django_neomodel パッケージを使用すると、グラフ モデルを Django プロジェクトの一部として扱うことができます。 この統合により、構成は通常、 settings.pyノードとリレーションシップ クラスは、アプリ、ミドルウェア、ビューなどの Django エコシステムの残りの部分と共存します。

具体的な例としては、neomodel を使用して Paradise Papers スタイルのグラフ データベースを探索および検索する、複数のパートからなる Django チュートリアルがあります。 最初の部分ではDjangoプロジェクトをセットアップしてneomodelを統合し、後半の部分では fetch_api アプリでは、グラフ内のエンティティ、リレーションシップ、プロパティを反映するモデルを定義し、その上にユーティリティとビューを徐々に構築します。

このようなプロジェクトでは、Django ビュー、シリアライザー、またはヘルパー モジュール内で neomodel モデルを直接使用できます。 一般的なアプローチは、 utils.py クエリAPIを呼び出す便利な関数を定義するファイル。例えば、 count_nodes, fetch_nodes, fetch_node_details フィルター、ページネーション パラメーター、モデル名を動的に取り込むヘルパー。

国、管轄区域、データ ソースのリストなどの一部のデータは、繰り返しクエリを実行するとコストがかかる可能性があるため、生の Cypher を使用して事前に計算し、定数として保存することができます。 A constants.py モジュールはこれらのCypherクエリを一度実行し、次のようなソートされたリストを導出することができます。 COUNTRIES, JURISDICTIONS, DATASOURCE、Django アプリ全体で簡単にインポートできるようになります。

これらの定数がアプリケーションの起動時に準備されていることを確認するには、Djangoのアプリ構成にフックして、 ready() 方法 fetch_api/app.py. そのメソッド内では、 constants.pyは、最初のCypherクエリをトリガーし、対応するリストにデータを入力します。これにより、後続のリクエストは、既に準備されたデータ構造から簡単に読み取ることができます。

複雑なクエリに対するRaw CypherとOGMの比較

neomodel の OGM は日常的な CRUD およびリレーションシップのトラバーサルに最適ですが、手動で記述された Cypher クエリの方が効率的なシナリオもあります。 深くネストされたトラバーサル、第 2 次またはマルチホップのクエリ、および高度な集約は、OGM チェーンよりも生の Cypher としてより明確に、より優れたパフォーマンスで表現できる場合があります。

典型的な例としては、トム・ハンクスと共演したすべての人物を特定するなど、特定の俳優と共演した映画に出演した共演者を見つけることが挙げられます。 Cypherクエリとして、これは非常に直接的なクエリです。俳優をマッチングし、その俳優が出演した映画を走査し、さらにそれらの映画に出演している他の俳優を走査し、必要に応じてフィルターと集計を適用します。その結果、簡潔で最適化されたグラフパターンが得られます。

同じ動作を OGM の便利なメソッドのみで再現するには、映画と関連するアクターを Python レベルでループする O(n²) スタイルのプロセスが必要になる場合があります。 これは、Neo4j に単一の Cypher ステートメントで重い処理を任せるよりも、エレガントさも効率性も劣ります。これは、OGM があらゆるグラフアクセスパターンに万能な解決策ではないことを示しています。

さらに、ディープトラバーサルに OGM 操作を利用すると、返されるデータの形状が非常に複雑になる可能性があります。 生成されるCypherには、多くの場合、開始ノード、中間関係、隣接ノード、そしてそれらの関係が含まれます。これは、豊富なコンテキストが必要な場合には便利ですが、特定の集計結果やプロパティのサブセットのみが必要な場合は、過剰になる可能性があります。

パフォーマンスと明瞭さが最も重要となる状況では、 cypher_query 手作りの Cypher を直接実行するのが良い選択肢となる場合があります。 Neomodel では、この脱出口が意図的に作られています。つまり、モデルをスキーマの唯一の信頼できる情報源として維持しながら、特定のクエリごとに適切なツールを選択し、同じプロジェクト内で高レベルの OGM インタラクションと低レベルの Cypher を組み合わせることができます。

Neo4j Labs の Neomodel とプロジェクトガバナンス

Neomodel が Neo4j Labs プログラムに移行したことで、明確な品質への期待を持ち、積極的に保守されるコミュニティ主導のプロジェクトとしての地位が確立されました。 Neo4j Labsは、コア製品には含まれないものの、実際に注目を集めている実験的かつ高度なプロジェクトの拠点となっています。グラフデータサイエンスコンポーネント、GraphQLライブラリ、APOCコア、ストリーミング統合など、多くの著名なツールはこのプログラムに根ざしています。

Neo4j Labs に所属するということは、neomodel がテスト、セキュリティ チェック、CI/CD パイプラインなどの自動化ツールに関するベースライン標準に準拠していることを意味します。 メンテナンスチームは、幅広いバージョンのPythonとNeo4jに対して統合テストを実施し、新しいリリースがリリースされた際に互換性を確保しています。これが、neomodelが現在サポートされているすべてのPythonとNeo4jのバージョン（コミュニティ版とエンタープライズ版の両方）を完全にサポートできる理由の一つです。

このプロジェクトは完全にオープンソースかつコミュニティ中心であり、GitHub が問題、議論、貢献の主要なハブとして機能します。 問題ログは再び積極的にキュレーションされ、古い項目は時間の許す限りトリアージされ、要約されています。一方、ディスカッションエリアは誰でもアクセスでき、アナウンスや設計に関する議論に利用されています。Neo4jの従業員のうち少なくとも1人がメンテナーとして活動しており、現場での経験をプロジェクトに還元しています。

Novo Nordisk の OpenStudyBuilder などの実際の製品展開は、neomodel のロードマップを策定する上で重要な役割を果たします。 これらの大規模で実用的なアプリケーションは、具体的な要件とフィードバックを提供し、それが新機能や改善に繋がってコミュニティに還元されます。この好循環は、企業での利用とオープンソース開発がいかに相互に強化し合うかを示しています。

Python モデリング、強力な Neo4j 整合、非同期および同期 API、アクティブなラボ支援の進化により、neomodel は小規模プロジェクトと要求の厳しい本番システムの両方で Python からグラフを操作する魅力的な方法を提供します。 慎重に使用すれば（明確なドメイン モデリングと一般的なグラフのインタラクションには OGM を活用し、複雑なパターンやパフォーマンスで必要な場合は生の Cypher を使用するなど）、グラフベースのアプリケーションの設計、クエリ、保守の方法を大幅に簡素化できます。