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

# 准备从 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://aws.amazon.com/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 迁移现有应用程序，我们都建议您从用例向后倒推，以设计可满足您业务需求的数据模型、一组查询和应用程序架构。

# Neptune 和 Neo4j 之间的架构差异
<a name="migration-architectural-differences"></a>

当客户第一次考虑将应用程序从 Neo4j 迁移到 Neptune 时，通常会倾向于根据实例大小进行 like-to-like比较。但是，Neo4j 和 Neptune 的架构有根本的区别。Neo4j 基于一种 all-in-one方法，即数据加载、数据 ETL、应用程序查询、数据存储和管理操作都发生在同一组计算资源中，例如 EC2 实例。

相比之下，Neptune 是一个以 OLTP 为中心的图形数据库，其中，架构将职责分开，且资源是解耦的，因此它们可以动态和独立地扩展。

从 Neo4j 迁移到 Neptune 时，请确定应用程序的数据持久性、可用性和可扩展性要求。Neptune 的集群架构简化了需要高耐久性、高可用性和高可扩展性的应用程序的设计。了解 Neptune 的集群架构后，就可以设计出满足这些要求的 Neptune 集群拓扑了。

## Neo4j 的集群架构
<a name="migration-neo4j-cluster-architecture"></a>

许多生产应用程序使用 Neo4j 的[因果集群](https://neo4j.com/docs/operations-manual/current/clustering/introduction/)来提供数据持久性、高可用性和可扩展性。Neo4j 的集群架构使用核心服务器和只读副本实例：
+ 核心服务器通过使用 Raft 协议复制数据，提供数据持久性和容错能力。
+ 只读副本使用事务日志传送，以异步复制高读取吞吐量工作负载的数据。

集群中的每个实例，无论是核心服务器还是只读副本，都包含图形数据的完整副本。

## Neptune 的集群架构
<a name="migration-neptune-cluster-architecture"></a>

[Neptune 集群](feature-overview-db-clusters.md)由一个主写入器实例和最多 15 个只读副本实例组成。集群中的所有实例共享与实例分开的相同底层分布式存储服务。
+ 主写入器实例协调对于数据库的所有写入操作，并且可以垂直扩展，为不同的写入工作负载提供灵活的支持。它还支持读取操作。
+ 只读副本实例支持从底层存储卷进行读取操作，并允许您水平扩展以支持高的读取工作负载。它们还通过充当主实例的失效转移目标来提供高可用性。
**注意**  
对于繁重的写入工作负载，最好将只读副本实例扩展到与写入器实例相同的大小，以确保读取器能够与数据变化保持一致。
+ 随着数据库中数据的增加，底层存储卷自动扩展存储容量，最多可达 128TiB 存储空间。

实例大小是动态且独立的。可以在集群运行时调整每个实例的大小，也可以在集群运行时添加或移除只读副本。

随着需求上升和下降，[Neptune 无服务器](neptune-serverless.md)特征可以自动纵向扩展和缩减您的计算容量。这不仅可以减少管理开销，还可以让您将数据库配置为在不降低性能或要求您过度预调配的情况下处理需求激增的状况。

您可以停止 Neptune 数据库集群最多 7 天。

Neptune 还支持[自动扩缩](manage-console-autoscaling.md)，可根据工作负载自动调整读取器实例的大小。

使用 Neptune 的[全球数据库特征](neptune-global-database.md)，您最多可以在其它 5 个区域中镜像集群。

Neptune [在设计上也是容错的](backup-restore-overview-fault-tolerance.md)：
+ 为集群中的所有实例提供数据存储的集群卷在单个 AWS 区域可用区 (AZs) 中跨越多个可用区 ()。每个可用区均包含集群数据的一个完整副本。
+ 如果主实例变得不可用，Neptune 会自动失效转移到现有的只读副本，数据丢失为零，通常在 30 秒内完成。如果集群中没有现有的只读副本，Neptune 会自动预调配一个新的主实例，同样不会丢失任何数据。

所有这些都意味着，从 Neo4j 因果集群迁移到 Neptune 时，您不必为了获得较高的数据持久性和高可用性而显式设计集群拓扑。这使您可以通过以下几种方式调整集群的大小，以满足预期的读取和写入工作负载以及任何可能增加的可用性要求：
+ 要扩展读取操作，请[添加只读副本实例](feature-overview-db-clusters.md#feature-overview-read-replicas)或启用 [Neptune 无服务器](neptune-serverless.md)功能。
+ 要提高可用性，请将集群中的主实例和只读副本分布到多个可用区 (AZs)。
+ 要缩短任何失效转移时间，请预调配至少一个可作为主实例的失效转移目标的只读副本实例。您可以通过[为每个副本分配优先级](manage-console-add-replicas.md)，确定在发生故障后将只读副本实例提升为主实例的顺序。最佳实践是确保失效转移目标所具有的实例类在提升为主实例后，能够处理应用程序的写入工作负载。

# Neptune 和 Neo4j 之间的数据存储区别
<a name="migration-storage-differences"></a>

Neptune 使用基于原生四元组模型的[图形数据模型](feature-overview-data-model.md)。将数据迁移到 Neptune 时，为了以最佳的方式利用 Neptune 提供的分布式和可扩展共享存储，您应该注意数据模型和存储层的架构存在一些差异：
+ Neptune 不使用任何显式定义的架构或约束。它允许您动态添加节点、边缘和属性，而无需提前定义架构。Neptune 不限制所存储数据的值和类型，除非在 [Neptune 限制](limits.md#limits-properties)中另有说明。作为 Neptune 存储架构的一部分，还会[自动对数据编制索引](feature-overview-storage-indexing.md)，以处理许多最常见的访问模式。这种存储架构消除了创建和管理数据库架构和索引优化的操作开销。
+ Neptune 提供了一种独特的分布式共享存储架构，这种架构可随着数据库存储需求的增长以 10GB 的区块进行扩展，最高可达 128TiB。该存储层可靠、耐用且具有容错性，可在 3 个可用区中复制数据 6 次，每个可用区复制两次。默认情况下，它为所有 Neptune 集群提供了高可用性和容错性的数据存储层。Neptune 的存储架构降低了成本，并且无需为应对未来的数据增长而预调配或过度预调配存储。

在将数据迁移到 Neptune 之前，最好先熟悉 Neptune 的[属性图数据模型](feature-overview-storage-indexing.md#feature-overview-storage-indexing-gremlin)和[事务语义](transactions.md)。

# Neptune 和 Neo4j 之间的操作差异
<a name="migration-operational-differences"></a>

Neptune 是一项完全托管式服务，可自动执行您在使用本地或自行管理的数据库（例如 Neo4j Enterprise 或 Community Edition）时必须执行的许多正常操作任务：
+ **[自动备份](backup-restore.md#backup-restore-overview-backups)** – Neptune 自动备份您的集群卷，并将备份保留您指定的保留期（从 1 到 35 天不等）。这些备份是连续且递增的，因此，您可以快速还原到保留期内的任何时间点。在写入备份数据时，不会发生任何性能影响或数据库服务中断。
+ **[手动快照](backup-restore.md)** – Neptune 允许您创建数据库集群的存储卷快照，以备份整个数据库集群。然后，这种快照可用于还原数据库、制作数据库副本并在多个账户之间共享。
+ **[克隆](manage-console-cloning.md)** – Neptune 支持克隆特征，可让您快速创建经济实惠的数据库克隆。克隆使用 copy-on-write协议，在创建克隆后只需要最少的额外空间。数据库克隆是在不中断原始集群的情况下试用 Neptune 新特征或升级的高效方法。
+ **[监控](monitoring.md)** – Neptune 提供了多种方法来监控集群的性能和使用情况，包括：
  + 实例状态
  + 与 Amazon 整合 CloudWatch 以及 AWS CloudTrail
  + 审计日志功能
  + 事件通知
  + 标签
+ **[安全](security.md)** – Neptune 默认提供安全的环境。集群位于私有 VPC 中，该私有 VPC 可与其它资源进行网络隔离。所有流量均通过 SSL 加密，所有数据都使用静态加密 AWS KMS。

  [此外，Neptune 还与 AWS Identity and Access Management (IAM) 集成以提供身份验证。](iam-auth.md)通过指定 [IAM 条件键](iam-condition-keys.md)，您可以使用 IAM policy 对[数据操作](iam-data-access-policies.md)进行精细的访问控制。

## Neptune 和 Neo4j 之间的工具和集成差异
<a name="migration-tooling-differences"></a>

Neptune 的集成和工具架构与 Neo4j 不同，这可能会影响您的应用程序架构。Neptune 使用集群的计算资源来处理查询，但利用其他 best-in-class AWS 服务来实现诸如全文搜索（使用 OpenSearch）、ETL（使用 Glue）等功能。有关这些集成的完整列表，请参阅[Neptune 集成](integrations.md)。