本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# Amazon Neptune 存储、可靠性和可用性
Amazon Neptune 使用分布式共享存储架构，这一架构可随着数据库存储需求增长而自动扩展。
Neptune 数据存储在集群卷中，该卷是一个使用基于非易失性存储器 Express (NVMe) 固态硬盘的驱动器的单个虚拟卷。集群卷由一组称为分段的逻辑块组成。每个分段都分配了 10GB 的存储空间。每个分段中的数据被复制到六个副本中，然后在数据库集群所在 AWS 区域的三个可用区 (AZs) 中进行分配。
创建 Neptune 数据库集群时，会为其分配单个 10GB 的分段。随着数据量增加并超过当前分配的存储空间，Neptune 通过添加新的分段来自动扩展集群容量。在除中国以外的所有受支持区域，Neptune 集群的最大容量可以增长到 128 TiB (TiB)，中国除外，这些地区的容量限制在 64 GovCloud TiB 以内。但是，对于早于[版本：1.0.2.2（2020 年 3 月 9 日）](engine-releases-1.0.2.2.md) 的引擎版本，所有区域中的集群卷大小限制为 64TiB。
数据库集群卷包含所有用户数据、索引和字典（如[Neptune 图形数据模型](feature-overview-data-model.md)部分所述）以及内部元数据，例如内部事务日志。所有这些图形数据，包括索引和内部日志，不能超过集群卷的最大大小。
## I/O 优化存储选项
Neptune 提供两种存储定价模式：
+ **标准存储**-标准存储为中低 I/O 使用率的应用程序提供经济实惠的数据库存储。
+ **I/O — 优化的存储 — 你可以**用I/O–Optimized storage, you pay only for the storage you are using, at a higher cost than for standard storage, and you pay nothing for the I/O它来使用。
I/O–Optimized storage is designed to meet the needs of I/O–intensive graph workloads at a predictable cost, with low I/O latency and consistent I/O吞吐量。
有关更多信息，请参阅 [I/O 优化型存储](storage-types.md#provisioned-iops-storage)。
## Neptune 存储分配
即使 Neptune 集群卷可以增长到 128TiB（或在少数区域可增长到 64TiB），您也只需为实际分配的空间付费。分配的总空间由存储*高水位*决定，这是集群卷在它存在期间的任何时候分配给集群卷的最大容量。
这意味着，即使从集群卷中移除了用户数据（例如通过 `g.V().drop()` 等此类删除查询），分配的总空间仍保持不变。Neptune 确实会自动优化未使用的分配空间，以供将来重复使用。
除用户数据外，另外两种类型的内容会占用内部存储空间，即字典数据和内部事务日志。尽管字典数据与图形数据一起存储，但即使它支持的图形数据已被删除，它也会无限期地保存，这意味着如果重新引入数据，条目可以重复使用。内部日志数据存储在单独的内部存储空间中，该存储空间具有自己的高水位。内部日志过期后，其占用的存储空间可以重新用于其它日志，但不能用于图形数据。为日志分配的内部空间量包含在该`VolumeBytesUsed`[CloudWatch 指标](cloudwatch.md)报告的总空间中。
查看[存储最佳实践](#feature-overview-storage-best-practices)以了解如何将分配的存储空间保持在最低限度并重用空间。
## Neptune 存储账单
如上所述，存储费用根据存储*高水位*进行计费。尽管数据复制成六个副本，但您只需为一个数据副本付费。
您可以通过监控`VolumeBytesUsed` CloudWatch 指标来确定数据库集群当前的存储最高水位是多少（请参阅[使用亚马逊监控 Neptune CloudWatch](cloudwatch.md)）。
可能影响 Neptune 存储成本的其它因素包括数据库快照和备份，它们作为备份存储单独计费，并基于 Neptune 存储成本（请参阅[CloudWatch 对管理 Neptune 备份存储非常有用的指标](backup-restore-overview-metrics.md)）。
但是，如果您创建数据库的[克隆](manage-console-cloning.md)，则该克隆指向的集群卷与数据库集群本身使用的集群卷相同，因此对于原始数据没有额外的存储费用。对克隆的后续更改将使用该[copy-on-write 协议](manage-console-cloning.md#manage-console-cloning-protocol)，并且确实会导致额外的存储成本。
有关 Neptune 定价的更多信息，请参阅 [Amazon Neptune 定价](https://aws.amazon.com/neptune/pricing)。
## Neptune 存储最佳实践
由于某些类型的数据会消耗 Neptune 中的永久存储空间，因此请使用以下最佳做法来避免存储增长大幅激增：
+ 在设计图形数据模型时，请尽可能避免使用本质上是临时性的属性键和面向用户的值。
+ 如果您计划更改数据模型，则在使用[快速重置 API](manage-console-fast-reset.md) 清除现有数据库集群中的数据之前，不要使用新模型将数据加载到该数据库集群中。最好的办法通常是将使用新模型的数据加载到新的数据库集群上。
+ 对大量数据进行操作的事务会生成相应大量的内部日志，这可能会永久增加内部日志空间的高水位。例如，删除数据库集群中所有数据的单个事务可能会生成庞大的内部日志，这需要分配大量内部存储空间，从而永久减少图形数据的可用空间。
为避免这种情况，请将大型事务拆分为较小的事务并在两者之间留出时间，以便关联的内部日志有机会过期并释放其内部存储以供后续日志重用。
+ 为了监控 Neptune 集群容量的增长，您可以对该指标设置 CloudWatch 警报。`VolumeBytesUsed` CloudWatch 如果数据已达到集群卷的最大大小，则此功能将特别有用。有关更多信息，请参阅[使用 Amazon CloudWatch 警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)。
当您有大量未使用的已分配空间时，缩小数据库集群使用的存储空间的唯一方法是导出图形中的所有数据，然后将其重新加载到新的数据库集群中。有关从数据库集群导出数据的简便方法，请参阅 [Neptune 的数据导出服务和实用程序](machine-learning-data-export.md)；有关将数据导入回 Neptune 的简单方法，请参阅 [Neptune 的批量加载程序](bulk-load.md)。
**注意**
创建和还原[快照](backup-restore-restore-snapshot.md)不会减少分配给数据库集群的存储量，因为快照会保留集群底层存储的原始映像。如果大量已分配的存储未被使用，则缩小已分配存储量的唯一方法是导出图形数据并将其重新加载到新的数据库集群中。
## Neptune 存储可靠性和高可用性
Amazon Neptune 的设计具有可靠、持久和容错的特点。
Neptune 数据的六个副本在三个可用区 (AZs) 中维护，这一事实确保了数据的存储非常耐用，而且数据丢失的可能性非常低。无论可用区中是否有数据库实例，数据都会跨可用区自动复制，并且复制的数量与集群中的数据库实例数量无关。
这意味着您可以快速添加只读副本，因为 Neptune 不会创建图形数据的新副本。相反，只读副本连接到已包含您的数据的集群卷。同样，移除只读副本不会移除任何底层数据。
只有在删除集群卷的所有数据库实例后，才能删除集群卷及其数据。
Neptune 还会自动检测构成集群卷的分段中的故障。当分段中的数据副本损坏时，Neptune 立即修复该分段，同时使用同一分段中的其它数据副本来确保修复的数据是最新的。因此，Neptune 避免了数据丢失，并减少了从磁盘故障中 point-in-time恢复所需的执行恢复。