翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Neo4j から Neptune への移行の準備

Neo4j グラフデータベースから Neptune グラフデータベースサービスへの移行には、再プラットフォームまたはリファクタリング/再設計の 2 つの主要な方法のいずれかでアプローチできます。再プラットフォームアプローチには、Neptune の機能を最大限に活用するために既存のデータモデルとアプリケーションアーキテクチャを変更することが含まれますが、リファクタリングアプローチでは、Neptune で同等のコンポーネントを見つけて同等の実装を構築することに重点を置いています。実際には、移行プロセスではターゲット Neptune アーキテクチャと既存の Neo4j 実装の制約と要件のバランスをとる必要があるため、これらの戦略の組み合わせがよく使用されます。アプローチに関係なく、キーはアプリケーションのユースケースから逆算して、ニーズに最適なデータモデル、クエリ、全体的なアーキテクチャを設計することです。

移行へのアプローチ

Neo4j アプリケーションを Neptune に移行する場合、リプラットフォームまたはリファクタリング/リアーキテクチャの2つの戦略のうちの 1 つをお勧めします。移行戦略の詳細については、Stephen Orban によるブログ記事「アプリケーションをクラウドに移行するための 6 つの戦略」を参照してください。

再プラットフォームアプローチ は、 とも呼ばれlift-tinker-and-shift、次のステップを伴います。

この逆算アプローチにより、まったく新しいプロジェクトの場合に設計するような種類の Neptune ソリューションにアプリケーションを移行できます。

これとは対照的に、リファクタリングアプローチには以下が含まれます。

この逆算アプローチは、ある実装を別の実装に置き換えることを目的としています。

実際には、これら 2 つのアプローチを組み合わせて採用することになるでしょう。ユースケースから始めて、ターゲットの Neptune アーキテクチャを設計しますが、次に、既存の Neo4j 実装に目を向けて、維持しなければならない制約や不変条件を特定することもできます。例えば、他の外部システムとの統合を継続したり、グラフアプリケーションのコンシューマーAPIsに固有の の提供を継続したりする必要がある場合があります。この情報を使用して、ターゲットモデルに移行するデータがすでに存在し、どのデータを他の場所にソースする必要があるかを判断できます。

また、アプリケーションが意図している仕事に関する最良の情報源として、Neo4j 実装の特定の部分を分析することから始めることもできます。既存のアプリケーションにおけるこのような考古学は、Neptuneの機能を使用するように設計できるユースケースを定義するのに役立ちます。

Neptune を使用して新しいアプリケーションを構築する場合でも、Neo4j から既存のアプリケーションを移行する場合でも、ユースケースから逆算して、ビジネスニーズに対応するデータモデル、クエリのセット、およびアプリケーションアーキテクチャを設計することをお勧めします。