NDCS 中的全局活动表
Oracle NoSQL Database Cloud Service 支持全局活动表体系结构，您可以在该体系结构中创建表，在多个区域之间复制表，以及跨区域副本维护同步数据。
当今的企业需要为客户提供更快、更好的服务。网络延迟是评估任何应用程序性能的关键参数。网络延迟是数据包在网络中传输所需的最短时间。用户期望从任何地方顺利、快速地完成他们的在线活动。为了满足这种期望，企业需要在最接近用户的分布式区域中托管应用程序和数据。
Oracle NoSQL Database Cloud Service 通过全局活动表提供满足这些要求的解决方案。通过此功能，在一个区域中写入的应用程序数据可以在多个区域中透明地复制。
- 本地读取和写入以及全局访问数据：多个区域中全局活动表的主动 - 主动配置可确保在一个区域中对表执行的更新自动复制到其他复制区域中的表的副本。可以从任何复制的区域访问数据。
- 性能：通过全局活动表，您可以在本地读取和写入数据，提供单位毫秒的延迟，这是全局分布式应用的本地访问特性。这可以提高大规模扩展全球应用的性能，并减少应用请求的延迟。
- 易于设置和管理：Oracle NoSQL Database Cloud Service 消除了使用全局活动表部署和管理多区域复制的复杂性。添加区域表副本非常简单，可以使用 API、Terraform 或 OCI 控制台完成。
- 多区域弹性：全局活动表在极少发生区域故障时也会启用容错功能。如果单个区域变为不可用或脱机，则应用程序请求可以重定向到复制表的区域，并且可以对该表执行读取和写入操作。
如何在 NDCS 中选择全局活动设置？
利用全局活动表功能，可以在多个区域中透明地复制写入的应用程序数据。
单个区域发生故障的罕见事件不应影响用户的体验。例如，如果单个区域变为脱机、隔离或降级，则您的应用程序应重定向到其他区域，并像以前一样继续执行读取和写入。简而言之，即使某个区域发生故障，您的数据库也需要提供灾难恢复。您可以使用 Oracle NoSQL Database Cloud Service (NDCS) 中的全局活动表通过主动 - 主动配置提供灾难恢复，或者通过使用本地数据访问在多个区域之间主动复制数据以实现低延迟。
考虑一个旅行用户的需求谁从流行的网站购物。他们可以在同一天从世界各地访问同一个购物网站。您需要确保用户体验最小延迟和无缝交互，无论他们在何处。
NDCS 中的“全局活动”表功能为上述两种方案提供了解决方案。让我们探讨两种方案中的每一种，并了解全局活动表如何成为提供高可用性、低延迟和灾难恢复的最佳解决方案。
在第一种情况下，假设贵公司在凤凰城（美国西部）、法兰克福（德国）和东京（日本）使用 NDCS，并且有一个名为 ShoppingCart 的表，用于存储来自全球不同地区购物客户的购物信息。在此示例中，贵公司通过地理位置最接近的数据中心为客户提供服务。此类设置涉及多个可用 Oracle NoSQL Database Cloud Service 的地理位置。在上述每个区域中具有两个或多个地理位置分布的区域和 NoSQL Database Cloud 服务的体系结构称为全局活动表体系结构。表 ShoppingCart 是一个全局活动表，在多个区域中复制。
在主动 - 主动配置中，您的 NDCS 在多个区域中可用，并且所有区域的数据都同步。当某个区域发生故障时，其他副本区域中的全局活动表将继续正常工作，不会受故障区域的影响。出现故障的区域恢复后，其区域表副本将与其他区域同步。“全局活动”表提供灾难恢复，因为当某个区域关闭时，您的应用程序将连接到另一个副本。
在第二种情况下，假设凤凰城的用户在网上购物，并在购物车中添加手机。西海岸 NDCS 区域提供了此会话的服务，并且用户可以体验到区域本地数据存储中的最小读取和写入请求延迟。该用户随后乘坐飞机前往德国，13 小时后抵达德国，前往酒店，连接到 Wi-Fi 网络，前往移动公司的在线商店，并发现另一个手机型号看起来更具吸引力。因此，用户决定用这种新型号的手机更新购物车，并继续浏览移动电子商务商店。法兰克福的区域数据存储是最接近的数据存储，用于此会话，并为用户提供与美国相同的低延迟读取和写入体验。然后，用户前往日本，并决定访问本地移动商店以获取有关最新移动型号的更多信息。然后，用户使用当前在移动商店中的手机的最新型号更新购物车。由于 NoSQL Database Cloud Service 在三个区域中可用，一个在凤凰城，第二个在德国，第三个在日本，并且有多个区域表副本，每当用户更新购物车或浏览移动电子商务商店时，从最靠近用户的本地区域获取个性化搜索结果和其他数据。这种本地处理可提供最低的延迟、最佳性能，并消除广域网访问。
基本概念
全局活动表中使用的术语：
- 区域：Oracle Cloud Infrastructure (OCI) 区域。这是一个本地化的地理区域，客户可以在其中部署应用。
- 发件人区域：将表更新复制到其他区域的区域。
- 接收方区域：从另一个区域接收表更新的区域。
- 单例表：未区域复制的表。
- 区域表副本：在其他区域中创建的表的副本。
- 全局活动表：具有一个或多个区域表副本的表。
创建和管理全局活动表的基本规则：
- 单例表必须至少有一个 JSON 列。
- 表的方案状态必须为 FROZEN 。
- 在接收方区域中，不能已存在同名的表。
- 在接收方区域中，区间（与发送方区域中的区间名称相同）必须已存在。
- 删除表之前，必须删除表的所有区域表副本。
注意：
在 NDCS 中，区域表复制在后台异步执行。您可以在全局活动表上创建子表。全局活动表的子表可以是单例表或全局活动表。要使子表成为全局活动表，需要冻结子表的方案并添加区域副本。您可以从父表的某个区域副本中进行选取。
全局活动表工作流
将哪些内容复制到全局活动表中？
- 表定义/方案
- 表中的索引 - 辅助索引的数量和定义。
- 表中的数据。
- 读取容量和写入容量 - 默认情况下，区域副本的读取限制与全局活动表的任何其他区域副本的读取限制相同。但是，读取操作纯粹是本地操作，因此您可以根据需要设置每个区域的自身读取限制。默认情况下，区域副本的写入限制与全局活动表的任何其他区域副本的写入限制相同。但是，写入限制可以设置为每个区域中的不同值。
- 存储容量 - 由于全局活动表的所有区域副本存储相同的表数据，因此区域副本的存储限制将复制到全局活动表的所有其他区域副本。
- 表的默认生存时间 (TTL)
添加区域表副本
注意：
添加区域表副本时，接收方区域中的表将放置在与发送方区域中的表同名的同一区间中。在全局活动表的整个生命周期中，您可以随时将其移动到另一个区间。区域表副本的容量（读取单位、写入单位和存储）
添加表的区域副本时， read capacity（读取容量）、 write capacity（写入容量）和 storage capacity（存储容量）字段会自动默认为发件人区域中表的相应值。但是，您可以在接收方区域中编辑和更改表的读取容量和写入容量值。无法更改表的存储容量。接收方区域中的表具有与发送方区域中的表相同的存储容量。全局活动表的容量模式可以按需或预配。您还可以在创建全局活动表后更改其任何区域副本的容量模式。容量模式的更改是该区域副本的本地更改，不会影响全局活动表的任何其他区域副本。
区域表副本中的记录 TTL
表生存时间 ( TTL ) 表示数据允许在表中生存的时间（小时数或天数）。借助 Oracle NoSQL Database Cloud Service，开发人员可以在表行上设置到期时间，之后行将自动过期，并且不再可用。指定持续时间后，行将自动失效并且不再可用。区域表副本中的 TTL 与发件人区域中的表 TTL 的值相同。将行复制到其他区域时，其失效时间将作为绝对时间戳进行复制。因此，无论复制时间如何，此行都将同时失效。
创建区域表副本后，将使用发件人区域表中的数据初始化该副本。在表数据的初始化期间，如果达到 TTL 值，这些行将过期，读取操作将看不到这些记录。
创建区域表副本后的 DDL 操作范围：
- 添加索引
- 删除索引
- 表的存储容量更改
- 表 TTL 更改
- 读取单位数更改
- 写入单位数更改
- 容量模式从按需更改为预配，反之亦然
全局活动表的数据建模注意事项
为什么必须冻结表的方案？
在全局活动表配置中，NDCS 中的表部署在多个区域中，并且所有区域同时为读写请求提供服务。连接到 NDCS 的应用程序应设计为连接到最近的复制区域。在复制区域中，表的主键、分片键和数据必须相同，因为这三者是应用程序使用表和查询执行方式的固有部分。在全局活动表中，由于表记录可以同时写入多个区域中的表，因此有必要就表的方案达成一致。为此，您可以阻止方案更改，强制所有区域立即就表的方案达成一致。为了实现简单性、性能和可预测性，Oracle NoSQL Cloud Service 要求为参与区域复制的任何表冻结方案。因此，在将单例表转换为全局活动表之前，必须冻结表方案，不允许进一步更改方案。如果需要在创建区域副本后更改全局活动表的方案，则必须首先删除所有区域副本，更改表的方案，然后重新添加区域副本。Oracle NoSQL 云服务将使用发件人区域中的最新数据重新填充所有区域副本。
为什么在冻结其方案时表中至少需要一个 JSON 列？
在区域表副本中协调模式更改非常困难，并可能导致潜在的错误情况。提供 JSON 列可在方案中提供更大的灵活性，并防止需要更改方案。
在全局活动表中定义身份
-
区域表副本中记录的标识应在表的所有区域副本中唯一。仅当可以保证所有区域表副本的唯一性时，才能在全局活动表中将自然键（用于标识表中每个记录的全局唯一标识符）用作标识。
- 在全局活动表中使用系统生成的标识时，应使用 UUID 。在大多数情况下，不应使用标识列，因为它不能保证在区域表副本中唯一。
策略和用户权限
表的 IAM 策略特定于发件人区域。
当用户添加单例表或全局活动表的副本时，接收方区域中不会添加策略或用户权限。源区域中希望创建和管理副本的用户还必须在接收方区域中具有必要的权限。否则，用户添加区域表副本时将出现错误。
创建区域表副本后，将任何数据修改从发件人区域复制到接收者区域不需要任何用户权限。这意味着，无论用户权限如何，一个副本表中的数据更改都将复制到所有其他表副本中。下面列出了创建和管理区域表副本所需的权限。
添加副本：
要管理表副本的用户必须在发件人区域和所有现有接收者区域中具有 NOSQL_TABLE_ALTER 权限。要创建新副本的用户需要在接收器区域中具有 NOSQL_TABLE_CREATE 权限（必须创建副本）。创建区域表副本时，不会在接收方区域中创建发送方区域中表的现有读写权限。要在接收方区域中创建新副本的用户负责为其创建的每个区域表副本创建表读取和写入权限。
删除副本：
要管理表副本的用户必须在发件人区域和所有现有接收者区域中具有 NOSQL_TABLE_ALTER 权限。要删除副本的用户需要在接收方区域中具有 NOSQL_TABLE_DROP 权限（必须删除副本）。
创建索引：
要在区域表副本中创建索引的用户需要具有 NOSQL_INDEX_CREATE 权限。
删除索引：
要删除区域表副本中的索引的用户需要具有 NOSQL_INDEX_DROP 权限。
更新表限制/TTL/：
要管理表副本的用户必须在所有区域表副本中具有 NOSQL_TABLE_ALTER 权限。
读取、写入和 ACID 事务处理
创建全局活动表后，可以使用现有的数据访问 API 或 DML 语句对该表执行读写操作。
为了获得最佳延迟，您的应用通常会从本地区域副本中读取。本地区域副本中的数据还将包括从其他区域表副本复制的数据更新。每当对全局活动表执行写入操作（INSERT、UPDATE 或 DELETE）时，更改都会跨多个区域异步复制。也就是说，在发件人区域中写入行时，写入操作将在发件人区域中完全执行，而无需等待副本区域进行更新。如果多个区域使用相同的主键更新行，则会应用规则来确定哪个区域的更新被视为最终更新。在所有这些情况下，此内置冲突解决规则将导致使用最新时间戳的更新成功并提交到数据库。同时从多个区域更新 TTL 值时，此规则也适用。
ACID 事务处理是区域的本地事务处理。事务处理提交时，只能保证在发生写入的区域中是原子、一致、隔离和持久的。区域表副本的一致性模型语义与非复制表的语义相同。区域表副本的一致性不是绝对的。绝对一致性是执行读取操作的单个区域的本地。从发件人区域复制到接收者区域的数据的读取始终是一致的。
来自发件人区域的写入将在时间延迟内复制到所有接收者区域。此次跨多个区域复制更改的延迟包括从发件人区域中的区域表副本接收数据所花费的时间以及在接收者区域完成写入操作所花费的时间。最终，接收方区域从发送方区域获取更新，接收方区域永远不会错过发送方区域中发生的事务处理更新。所有区域表副本最终都将收到写入并变得持久。
副本延迟概述
每当对全局活动表执行写入操作（INSERT、UPDATE 或 DELETE）时，更改都会跨多个区域异步复制。
也就是说，在发件人区域中写入行时，写入操作将在发件人区域中完全执行，而无需等待副本区域进行更新。网络延迟会造成将更改复制到接收方区域的时间延迟。在多个区域中复制更改的延迟包括从副本接收写入并将其应用于接收器区域所花费的时间。如果发件人区域没有对表进行应用程序写入，该服务将使用 ping 机制计算滞后的近似值，并且滞后统计信息仍将在接收者区域中可用。
有关 "Replica Lag"（副本滞后）度量的更多详细信息，请参见 Details on Replica Lag 。
创建全局活动表概览
创建全局活动表的过程首先创建单例表，然后将其转换为全局活动表
- 创建单例表并确保一列为 JSON。
- 将表的模式状态从可变更改为已冻结。
- 确定要在其中添加表的区域副本的区域。添加区域副本时，系统会自动使用发件人区域的相应值填充读取容量、写入容量和存储容量字段。可以更改表的读取容量和写入容量。
- 云服务在接收方区域中创建表。如果源区域中的表具有数据，则会开始将数据从发送方区域复制到接收方区域。当数据从发送方区域复制到接收方区域时，初始化百分比从 0 增加到 100。您可以在 OCI 控制台中的表信息下查看初始化百分比的值，如下所示。在初始化过程完成之前，新区域表副本中不允许执行 DML 操作。
