NDCS 中的全局活动表

Oracle NoSQL Database Cloud Service 支持全局活动表体系结构，您可以在其中创建表，跨多个区域复制表，以及跨区域副本维护同步数据。

当今的企业需要为客户提供更快、更好的服务。网络延迟是评估任何应用程序性能的关键参数。网络延迟是数据包在网络中传输所需的最短时间。用户期望从任何地方顺利快速地完成在线活动。为了满足这些期望，企业需要在最接近用户的分布式区域中托管应用和数据。

Oracle NoSQL Database Cloud Service 通过全局活动表提供满足这些要求的解决方案。通过此功能，可以在多个区域中透明地复制在区域中写入的应用数据。

全局有效表的优点：

如何在 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 在三个区域中提供，一个在凤凰城，另一个在德国，第三在日本，并且有多个区域表副本，每当用户更新购物车或浏览移动电子商务商店、个性化搜索结果和其他数据从最接近用户的本地区域获取时，就会有多个区域表副本。这种本地处理可提供最低延迟和最佳性能，并消除广域网访问。

基本概念

全局活动表中使用的术语：

用于创建和管理全局活动表的基本规则：

必须满足以下标准才能创建和管理全局活动表。

注：在 NDCS 中，区域表复制在后台异步执行。

您可以在全局活动表上创建子表。全局活动表的子表可以是单例表，也可以是全局活动表。要将子表设为“Global Active（全局活动）”表，需要冻结子表的方案并添加区域副本。您可以从父表的一个区域副本中进行选择。

全局有效表工作流

在全局活动表中复制什么内容？

添加现有 NoSQL 表的区域表副本时，会将单例表转换为全局活动表。将在表中复制以下内容。

注：使用 OCI 标记，您可以向资源添加元数据。一个或多个标记可以与全局活动表关联。不会复制 OCI 标记，并且全局活动表在不同区域中可以具有不同的标记。

添加区域表副本

复制表时，表将在另一个区域（称为接收方区域）中创建。如果发件人区域中的表是单例，则该表将转换为全局活动表。如果发件人区域中的表已经是全局活动表，则会将另一个区域副本添加到表中。将使用发件人区域表中的数据初始化区域副本。例如，如果发件人区域中的表有 1000 行，则所有数据都将复制到新创建的区域副本中。

注：添加区域表副本时，接收方区域中的表将放置在与发送方区域中的表具有相同表名的同一区间中。在“全局活动”表的整个生命周期内，您可以随时将其移动到另一个区间。

区域表副本的容量（读取单位、写入单位和存储）

添加表的区域副本时， read capacity 、 write capacity 和 storage capacity 字段会自动默认为发件人区域中表的相应值。但是，您可以在接收器区域中编辑和更改表的读取容量和写入容量值。无法更改表的存储容量。接收方区域中的表与发送方区域中的表具有相同的存储容量。全局活动表的容量模式可以按需或预配。您还可以在创建全局活动表后更改其任何区域副本的容量模式。容量模式的更改是该区域副本的本地更改，不会影响“全局活动”表的任何其他区域副本。

区域表副本中记录的 TTL

Table Time to Live（表生存时间） ( TTL ) 表示允许数据在表中生存的时间量（小时数或天数）。借助 Oracle NoSQL Database Cloud Service，开发人员可以在表行上设置失效时间，之后行将自动失效，不再可用。在指定的持续时间后，行将自动失效，不再可用。区域表副本中的 TTL 与发件人区域中的表 TTL 相同。将行复制到其他区域时，其到期时间将作为绝对时间戳进行复制。因此，无论何时复制该行，该行都将同时失效。

创建区域表副本后，将使用发送方区域表中的数据对其进行初始化。在表数据的初始化期间，如果达到 TTL 值，这些行将失效，读取操作将看不到这些记录。

创建区域表副本后的 DDL 操作范围：

以下 DDL 操作具有全局范围，这意味着一个区域表副本中的更改会自动传播到所有区域表副本。

以下 DDL 操作具有本地作用域，这意味着仅在启动该 DDL 的区域表副本中更改。

全局活动表的数据建模注意事项

为什么必须冻结表的方案？

在全局活动表配置中，NDCS 中的表部署在多个区域，并且所有区域同时提供读取和写入请求。连接到 NDCS 的应用应设计为连接到最近的复制区域。表的主键、分片键和数据在各个复制区域中必须相同，因为这三个是应用程序使用表以及查询执行方式的固有组成部分。在全局活动表中，由于表记录可以同时写入多个区域的表，因此有必要就表的方案达成一致。您可以通过阻止模式更改来执行此操作，从而强制所有区域立即就表的模式达成共识。为了简化、提高性能和可预测性，Oracle NoSQL Cloud Service 要求为参与区域复制的任何表冻结方案。因此，在将单例表转换为全局活动表之前，必须冻结表方案，并且不允许进一步更改方案。如果您在创建区域副本后需要更改全局活动表的方案，则必须首先删除所有区域副本，更改表的方案，然后重新添加区域副本。Oracle NoSQL 云服务将使用发件人区域中的最新数据重新填充所有区域副本。因此，建议表中至少包含一个 JSON 列，因为它在方案中提供了更大的灵活性，并防止了需要更改方案。

在全局活动表中定义身份

策略和用户权限

表的 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 。

创建全局活动表概览

创建全局活动表的过程从创建单例表开始，然后将其转换为全局活动表

下面列出了创建全局活动表的步骤。