从 Neo4j 迁移到 Amazon Neptune

Neo4j 和 Amazon Neptune 都是图形数据库，专为支持带标签的属性图数据模型的在线事务图形工作负载而设计。这些相似之处使 Neptune 成为寻求迁移其当前 Neo4j 应用程序的客户的常见选择。但是，这些迁移并不仅仅是直接迁移，因为两个数据库之间在语言和特征支持、操作特性、服务器架构和存储能力方面存在差异。

本页概述了迁移过程，并提出了在将 Neo4j 图形应用程序迁移到 Neptune 之前需要考虑的事项。这些注意事项通常适用于任何 Neo4j 图形应用程序，无论是由社区、企业还是 Aura 数据库提供支持。尽管每种解决方案都是独一无二的，可能需要额外的过程，但所有迁移都遵循相同的一般模式。

以下各节中描述的每个步骤都包括简化迁移过程的注意事项和建议。此外，还有开源工具和描述流程的博客文章，以及包含推荐架构选项的特征兼容性部分。

有关从 Neo4j 迁移到 Neptune 的一般信息

借助 Neptune 对 openCypher 查询语言的支持，您可以将大多数使用 Bolt 协议或 HTTPS 的 Neo4j 工作负载迁移到 Neptune。但是，openCypher 是一个开源规范，它包含其它数据库（例如 Neo4j）支持的大部分（但不是全部）功能。

尽管在许多方面兼容，但 Neptune 并不是 Neo4j 的直接替代。Neptune 是一项完全托管式图形数据库服务，具有高可用性和高耐久性等企业级特征，在架构上与 Neo4j 不同。Neptune 基于实例，具有一个主写入器实例和最多 15 个只读副本实例（可让您水平扩展读取容量）。使用 Neptune 无服务器，您可以根据查询量自动横向扩展和缩减计算容量。这与 Neptune 存储无关，Neptune 存储会随着您添加数据而自动扩展。

Neptune 支持开源 openCypher 标准规范，版本 9。在 Amazon，我们相信开源对每个人都有好处，我们致力于将开源的价值带给我们的客户，并为开源社区带来 Amazon 的运营卓越性。

但是，许多在 Neo4j 上运行的应用程序也使用非开源且 Neptune 不支持的专有特征。例如，Neptune 不支持 APOC 过程、某些特定于 Cypher 的子句和函数以及 Char、Date 或 Duration 数据类型。Neptune 确实会将缺失的数据类型自动转换为支持的数据类型。

除了 openCypher 之外，Neptune 还支持用于属性图的 Apache TinkerPop Gremlin 查询语言（以及用于 RDF 数据的 SPARQL）。Gremlin 可以在同一个属性图上与 openCypher 互操作，在许多情况下，您可以使用 Gremlin 来提供 openCypher 不提供的功能。以下是两种语言的快速比较：

Match p=(a)-[:route]->(d)
WHERE a.code='ANC'
RETURN p

g.V().has('code', 'ANC').
out('route').path().
by(elementMap())

通常，无需更改数据模型即可从 Neo4j 迁移到 Neptune，因为 Neo4j 和 Neptune 都支持带标签的属性图 (LPG) 数据。但是，Neptune 有一些架构和数据模型差异，您可以利用这些差异来优化性能。例如：

如果您还有问题，请联系 Amazon Support 或联系您的 Amazon 客户团队。我们会根据您的反馈来确定满足您需求的新特征的优先顺序。