本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 准备从 Neo4j 迁移到 Neptune
<a name="preparing-to-migrate-from-neo4j"></a>

 从 Neo4j 图形数据库迁移到 Neptune 图形数据库服务主要通过以下两种方式实现：更换平台或重构/重新架构。更换平台方法包括修改现有的数据模型和应用程序架构，以充分利用 Neptune 的功能，而重构方法则侧重于在 Neptune 中寻找等效的组件来构建类似的实现。在实践中，这些策略通常组合使用，因为迁移过程需要在目标 Neptune 架构与现有 Neo4j 实现的限制和要求之间取得平衡。无论采用哪种方法，关键都是基于应用程序的使用案例反推，设计出最能满足您需求的数据模型、查询和整体架构。

## 迁移方法
<a name="migration-approaches"></a>

将 Neo4j 应用程序迁移到 Neptune 时，我们推荐两种策略之一：要么重构平台，要么重构/转换架构。有关迁移策略的更多信息，请参阅 Stephen Orban 撰写的博客文章[将应用程序迁移到云中的 6 种策略](https://www.amazonaws.cn/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/)。

*平台重组方法*（有时被称为 *lift-tinker-and-shift*）涉及以下步骤：
+ 确定您的应用程序要满足的用例。
+ 使用 Neptune 的功能修改现有的图形数据模型和应用程序架构，以最好地满足这些工作负载需求。
+ 确定如何将数据、查询和源应用程序的其它部分迁移到目标模型和架构中。

如果这是一个全新的项目，这种逆向工作的方法可以让您将应用程序迁移到您可能设计的这种 Neptune 解决方案中。

相比之下，*重构方法*涉及：
+ 确定现有实施的组件，包括基础设施、数据、查询和应用程序功能。
+ 在 Neptune 中寻找可用于构建类似实现的等效项。

这种向前推进的方法试图将一种实现换成另一种实现。

实际上，您很可能会混合使用这两种方法。您可以从一个用例开始，设计目标 Neptune 架构，但然后转向现有的 Neo4j 实现来确定您必须维护的约束和不变量。例如，您可能需要继续与其他外部系统集成，或者继续为图形应用程序的使用者提供特定的 APIs 产品。利用这些信息，您可以确定哪些数据已经存在可移动到目标模型，哪些数据必须从其它地方获取。

在其它时候，您可以从分析 Neo4j 实现的特定部分开始，以此作为有关您的应用程序打算完成的任务的最佳信息来源。现有应用程序中的这种考古学可以帮助定义一个用例，然后您可以设计这个用例来使用 Neptune 的功能。

无论您是使用 Neptune 构建新的应用程序，还是从 Neo4j 迁移现有应用程序，我们都建议您从用例向后倒推，以设计可满足您业务需求的数据模型、一组查询和应用程序架构。