Azure Cosmos DB 分析存储(预览版)是什么?What is Azure Cosmos DB Analytical Store (Preview)?

重要

Azure Cosmos DB 分析存储目前处于预览状态。Azure Cosmos DB analytical store is currently in preview. 此预览版在提供时没有附带服务级别协议,不建议将其用于生产工作负荷。This preview version is provided without a service level agreement, and it's not recommended for production workloads. 有关详细信息,请参阅适用于 Azure 预览版的补充使用条款For more information, see Supplemental terms of use for Azure previews.

Azure Cosmos DB 分析存储是完全独立的列存储,可以借助它对 Azure Cosmos DB 中的操作数据进行大型分析,这对事务性工作负载没有任何影响。Azure Cosmos DB analytical store is a fully isolated column store for enabling large-scale analytics against operational data in your Azure Cosmos DB, without any impact to your transactional workloads.

对操作数据进行大型分析面临的挑战Challenges with large-scale analytics on operational data

Azure Cosmos DB 容器中的多模型操作数据存储在已编索的基于行的“事务性存储”内部。The multi-model operational data in an Azure Cosmos DB container is internally stored in an indexed row-based "transactional store". 行存储格式旨在快速实现事务性读写(以毫秒级的响应时间)和操作查询。Row store format is designed to allow fast transactional reads and writes in the order-of-milliseconds response times, and operational queries. 如果数据集增长得很大,就以此格式存储的数据的预配吞吐量而言,复杂的分析查询可能会非常昂贵。If your dataset grows large, complex analytical queries can be expensive in terms of provisioned throughput on the data stored in this format. 预配吞吐量的高消耗反过来会影响你的实时应用程序和服务所使用的事务工作负荷的性能。High consumption of provisioned throughput in turn, impacts the performance of transactional workloads that are used by your real-time applications and services.

通常,若要分析大量的数据,则从 Azure Cosmos DB 的事务性存储中提取操作数据,并将其存储在单独的数据层中。Traditionally, to analyze large amounts of data, operational data is extracted from Azure Cosmos DB's transactional store and stored in a separate data layer. 例如,采用适当的格式将数据存储在数据仓库或数据湖中。For example, the data is stored in a data warehouse or data lake in a suitable format. 之后将使用此数据进行大型分析,并使用计算引擎(如 Apache Spark 群集)分析它们。This data is later used for large-scale analytics and analyzed using compute engine such as the Apache Spark clusters. 从操作数据中分离分析存储和计算层会增加延迟,因为运行 ETL(提取、转换、加载)管道的频率会降低,以最大程度减少对事务性工作负荷的潜在影响。This separation of analytical storage and compute layers from operational data results in additional latency, because the ETL(Extract, Transform, Load) pipelines are run less frequently to minimize the potential impact on your transactional workloads.

相对于仅处理新引入的操作数据而言,处理操作数据更新时,ETL 管道也会变得复杂。The ETL pipelines also become complex when handling updates to the operational data when compared to handling only newly ingested operational data.

面向列的分析存储Column-oriented analytical store

Azure Cosmos DB 分析存储解决了传统 ETL 管道所具有的复杂和延迟问题。Azure Cosmos DB analytical store addresses the complexity and latency challenges that occur with the traditional ETL pipelines. Azure Cosmos DB 分析存储可以自动将操作数据同步到单独的列存储。Azure Cosmos DB analytical store can automatically sync your operational data into a separate column store. 列存储格式适用于采用优化的方式执行大型分析查询,可改进此类查询的延迟性。Column store format is suitable for large-scale analytical queries to be performed in an optimized manner, resulting in improving the latency of such queries.

借助 Azure Synapse Link,现在可以直接从 Synapse Analytics 链接到 Azure Cosmos DB 分析存储,生成无 ETL HTAP 解决方案。Using Azure Synapse Link, you can now build no-ETL HTAP solutions by directly linking to Azure Cosmos DB analytical store from Synapse Analytics. 借助它,你可以以接近实时的速度对操作数据运行的大型分析。It enables you to run near real-time large-scale analytics on your operational data.

分析存储的功能Features of analytical store

在 Azure Cosmos DB 容器中启用分析存储时,将基于容器中的操作数据在内部创建新的列存储。When you enable analytical store on an Azure Cosmos DB container, a new column-store is internally created based on the operational data in your container. 此列存储将与该容器的面向行的事务性存储分开保存。This column store is persisted separately from the row-oriented transactional store for that container. 对操作数据的插入、更新和删除将自动同步到分析存储。The inserts, updates, and deletes to your operational data are automatically synced to analytical store. 你无需更改源或 ETL,即可同步数据。You don't need the change feed or ETL to sync the data.

用于操作数据分析工作负荷的列存储Column store for analytical workloads on operational data

分析工作负荷通常涉及聚合和按顺序扫描选定字段。Analytical workloads typically involve aggregations and sequential scans of selected fields. 通过按以列为主的顺序存储数据,分析存储可以将每个字段的值组合在一起序列化。By storing the data in a column-major order, the analytical store allows a group of values for each field to be serialized together. 此格式减少了扫描或计算特定字段中统计信息所需的 IOPS。This format reduces the IOPS required to scan or compute statistics over specific fields. 它极大地改进了扫描大型数据集所需的查询响应时间。It dramatically improves the query response times for scans over large data sets.

例如,操作表采用下面的格式时:For example, if your operational tables are in the following format:

示例操作表

行存储会采用序列化格式将上面的数据按行保存到磁盘中。The row store persists the above data in a serialized format, per row, on the disk. 此格式可以加快事务性读写和操作查询,如“返回产品 1 的相关信息”。This format allows for faster transactional reads, writes, and operational queries, such as, "Return information about Product1". 不过,随着数据集增大,如果你想要对数据运行复杂的分析查询,它的成本可能会很高。However, as the dataset grows large and if you want to run complex analytical queries on the data it can be expensive. 例如,如果想要获取“‘设备’类别下的某个产品在不同业务单位和月份的销量趋势”,则需要运行复杂查询。For example, if you want to get "the sales trends for a product under the category named 'Equipment' across different business units and months", you need to run a complex query. 就预配的吞吐量而言,对此数据集执行大型扫描的成本可能会变得很高,这还可能会影响支持实时应用程序和服务的事务性工作负荷的性能。Large scans on this dataset can get expensive in terms of provisioned throughput and can also impact the performance of the transactional workloads powering your real-time applications and services.

分析存储是列存储,它更适用于此类查询,因为它会将相似的数据字段一起序列化,减少磁盘 IOPS。Analytical store, which is a column store, is better suited for such queries because it serializes similar fields of data together and reduces the disk IOPS.

下图说明了 Azure Cosmos DB 中的事务性行存储与分析列存储:The following image shows transactional row store vs. analytical column store in Azure Cosmos DB:

Azure Cosmos DB 中的事务性行存储与分析列存储

分析工作负荷性能已分离Decoupled performance for analytical workloads

分析查询不会影响事务性工作负荷的性能,因为分析存储已与事务性存储分开。There is no impact on the performance of your transactional workloads due to analytical queries, as the analytical store is separate from the transactional store. 分析存储无需分配单独的请求单位 (RU)。Analytical store does not need separate request units (RUs) to be allocated.

自动同步Auto-Sync

自动同步是指 Azure Cosmos DB 的完全托管功能,对操作数据执行的插入、更新、删除将准实时自动从事务存储同步到分析存储。Auto-Sync refers to the fully managed capability of Azure Cosmos DB where the inserts, updates, deletes to operational data are automatically synced from transactional store to analytical store in near real time. 自动同步延迟通常在 2 分钟内。Auto-sync latency is usually within 2 minutes. 如果共享吞吐量数据库拥有大量容器,则单个容器的自动同步延迟可能会更高,最长可能达 5 分钟。In cases of shared throughput database with a large number of containers, auto-sync latency of individual containers could be higher and take up to 5 minutes. 我们希望详细了解此延迟如何适应你的场景。We would like to learn more how this latency fits your scenarios. 请联系 Azure Cosmos DB 团队提供相关反馈。For that, please reach out to the Azure Cosmos DB team.

自动同步功能与分析存储一起提供了以下主要优势:The auto-sync capability along with analytical store provides the following key benefits:

可伸缩性和弹性Scalability & elasticity

通过使用水平分区,Azure Cosmos DB 事务性存储无需停机即可弹性缩放存储和吞吐量。By using horizontal partitioning, Azure Cosmos DB transactional store can elastically scale the storage and throughput without any downtime. 事务性存储中的水平分区为自动同步提供了可伸缩性和弹性,确保数据以接近实时的速度同步到分析存储。Horizontal partitioning in the transactional store provides scalability & elasticity in auto-sync to ensure data is synced to the analytical store in near real time. 无论事务性流量吞吐量如何数据同步都会执行(无论是 1000 个操作/秒还是 1 百万个操作/秒),并且它不会影响事务性存储的预配吞吐量。The data sync happens regardless of the transactional traffic throughput, whether it is 1000 operations/sec or 1 million operations/sec, and it doesn't impact the provisioned throughput in the transactional store.

自动处理架构更新Automatically handle schema updates

Azure Cosmos DB 事务性存储架构不可知,因此你能够迭代事务性应用程序,而无需处理架构或索引管理。Azure Cosmos DB transactional store is schema-agnostic, and it allows you to iterate on your transactional applications without having to deal with schema or index management. 与此相反,Azure Cosmos DB 分析存储已架构化,以便优化分析查询性能。In contrast to this, Azure Cosmos DB analytical store is schematized to optimize for analytical query performance. 借助自动同步功能,Azure Cosmos DB 可管理对事务存储中最新更新的架构推断。With the auto-sync capability, Azure Cosmos DB manages the schema inference over the latest updates from the transactional store. 它还管理现成分析存储中的架构表示形式,其中包括处理嵌套数据类型。It also manages the schema representation in the analytical store out-of-the-box which, includes handling nested data types.

随着架构不断演化,并且将随时间推移添加新属性,分析存储会自动跨事务存储中的所有历史架构呈现联合架构。As your schema evolves, and new properties are added over time, the analytical store automatically presents a unionized schema across all historical schemas in the transactional store.

架构约束Schema constraints

当启用分析存储以自动推断并正确表示架构时,以下约束适用于 Azure Cosmos DB 中的操作数据:The following constraints are applicable on the operational data in Azure Cosmos DB when you enable analytical store to automatically infer and represent the schema correctly:

  • 架构的任何嵌套级别最多可以有 200 个属性,最大嵌套深度为 5 个级别。You can have a maximum of 200 properties at any nesting level in the schema and a maximum nesting depth of 5.

    • 顶层具有 201 个属性的项不满足此约束,因此不会呈现在分析存储中。An item with 201 properties at the top level doesn't satisfy this constraint and hence it will not be represented in the analytical store.

    • 架构中具有 5 个以上嵌套级别的项也不满足此约束,因此不会呈现在分析存储中。An item with more than five nested levels in the schema also doesn't satisfy this constraint and hence it will not be represented in the analytical store. 例如,以下项不满足要求:For example, the following item doesn't satisfy the requirement:

      {"level1": {"level2":{"level3":{"level4":{"level5":{"too many":12}}}}}}

  • 以不区分大小写的方式进行比较时,属性名称应该是唯一的。Property names should be unique when compared case insensitively. 例如,以下项不满足此约束,因此不会呈现在分析存储中:For example, the following items do not satisfy this constraint and hence will not be represented in the analytical store:

    {"Name": "fred"} {"name": "john"} - 以不区分大小写的方式进行比较时,“Name”和“name”是相同的。{"Name": "fred"} {"name": "john"} - "Name" and "name" are the same when compared in a case insensitive manner.

架构表示形式Schema representation

在分析存储中,架构表示形式有两种模式。There are two modes of schema representation in the analytical store. 这些模式在简化列式表示形式、处理多态架构和简化查询体验之间进行了权衡:These modes have tradeoffs between the simplicity of a columnar representation, handling the polymorphic schemas, and simplicity of query experience:

  • 定义明确的架构表示形式Well-defined schema representation
  • 完全保真架构表示形式Full fidelity schema representation

备注

对于 SQL(核心)API 帐户,启用分析存储后,将明确定义分析存储中的默认架构表示形式。For SQL (Core) API accounts, when analytical store is enabled, the default schema representation in the analytical store is well-defined. 而对于用于 MongoDB 帐户的 Azure Cosmos DB API,分析存储中的默认架构表示形式是完全保真架构表示形式。Whereas for Azure Cosmos DB API for MongoDB accounts, the default schema representation in the analytical store is a full fidelity schema representation. 如果你的场景需要与每个 API 的默认产品/服务不同的架构表示形式,请与 Azure Cosmos DB 团队联系,以启用它。If you have scenarios requiring a different schema representation than the default offering for each of these APIs, reach out to the Azure Cosmos DB team to enable it.

定义明确的架构表示形式Well-defined schema representation

定义明确的架构表示形式可在事务存储中创建与架构无关的数据的简单表格表示形式。The well-defined schema representation creates a simple tabular representation of the schema-agnostic data in the transactional store. 定义明确的架构表示形式具有以下注意事项:The well-defined schema representation has the following considerations:

  • 一个属性在多个项中的类型始终相同。A property always has the same type across multiple items.

    • 例如,{"a":123} {"a": "str"} 没有完善定义的架构,因为 "a" 有时是字符串,有时是数值。For example, {"a":123} {"a": "str"} does not have a well-defined schema because "a" is sometimes a string and sometimes a number. 在这种情况下,分析存储会将 "a" 的数据类型注册为容器生存期期间第一个出现的项中的 "a" 的数据类型。In this case, the analytical store registers the data type of "a" as the data type of "a" in the first-occurring item in the lifetime of the container. 如果项中 "a" 的数据类型与众不同,则不会将其包含在分析存储中。Items where the data type of "a" differs will not be included in the analytical store.

      此条件不适用于 null 属性。This condition does not apply for null properties. 例如,{"a":123} {"a":null} 仍是定义明确的。For example, {"a":123} {"a":null} is still well defined.

  • 数组类型必须包含单个重复的类型。Array types must contain a single repeated type.

    • 例如,{"a": ["str",12]} 不是定义明确的架构,因为此数组包含整数和字符串类型组合。For example, {"a": ["str",12]} is not a well-defined schema because the array contains a mix of integer and string types.

备注

如果 Azure Cosmos DB 分析存储遵循定义明确的架构表示形式,但某些项违反了上述规范,则这些项不会包含在分析存储中。If the Azure Cosmos DB analytical store follows the well-defined schema representation and the specification above is violated by certain items, those items will not be included in the analytical store.

完全保真架构表示形式Full fidelity schema representation

完全保真架构表示形式旨在处理与架构无关的操作数据中的各种多态架构。The full fidelity schema representation is designed to handle the full breadth of polymorphic schemas in the schema-agnostic operational data. 在此架构表示形式中,即使违反定义明确的架构约束(也就是既没有混合数据类型字段也没有混合数据类型数组),也不会从分析存储中删除任何项。In this schema representation, no items are dropped from the analytical store even if the well-defined schema constraints (that is no mixed data type fields nor mixed data type arrays) are violated.

这是通过根据属性中值的数据类型将操作数据的叶属性转换为具有不同列的分析存储来实现的。This is achieved by translating the leaf properties of the operational data into the analytical store with distinct columns based on the data type of values in the property. 叶属性名称在分析存储架构中使用数据类型作为后缀进行扩展,以便它们可以无歧义地进行查询。The leaf property names are extended with data types as a suffix in the analytical store schema such that they can be queries without ambiguity.

例如,在事务存储中获取以下示例文档:For example, let's take the following sample document in the transactional store:

{
name: "John Doe",
age: 32,
profession: "Doctor",
address: {
  streetNo: 15850,
  streetName: "NE 40th St.",
  zip: 98052
},
salary: 1000000
}

嵌套对象 address 中的叶属性 streetNo 将在分析存储架构中表示为列 address.object.streetNo.int32The leaf property streetNo within the nested object address will be represented in the analytical store schema as a column address.object.streetNo.int32. 数据类型作为后缀添加到列中。The datatype is added as a suffix to the column. 这样一来,如果将其他文档添加到事务存储中,其中叶属性 streetNo 的值为“123”(请注意,这是一个字符串),则分析存储的架构会自动演变,而不会更改先前编写的列的类型。This way, if another document is added to the transactional store where the value of leaf property streetNo is "123" (note it's a string), the schema of the analytical store automatically evolves without altering the type of a previously written column. 一个新列作为 address.object.streetNo.string 添加到分析存储中,其中存储值“123”。A new column added to the analytical store as address.object.streetNo.string where this value of "123" is stored.

要映射到后缀的数据类型Data type to suffix map

下面是分析存储中所有属性数据类型及其后缀表示形式的映射:Here is a map of all the property data types and their suffix representations in the analytical store:

原始数据类型Original data type SuffixSuffix 示例Example
DoubleDouble ".float64"".float64" 24.9924.99
ArrayArray ".array"".array" ["a", "b"]["a", "b"]
二进制Binary ".binary"".binary" 00
布尔Boolean ".bool"".bool" TrueTrue
Int32Int32 ".int32"".int32" 123123
Int64Int64 ".int64"".int64" 255486129307255486129307
NullNull ".null"".null" nullnull
StringString ".string"".string" "ABC""ABC"
时间戳Timestamp ".timestamp"".timestamp" Timestamp(0, 0)Timestamp(0, 0)
DateTimeDateTime ".date"".date" ISODate("2020-08-21T07:43:07.375Z")ISODate("2020-08-21T07:43:07.375Z")
ObjectIdObjectId ".objectId"".objectId" ObjectId("5f3f7b59330ec25c132623a2")ObjectId("5f3f7b59330ec25c132623a2")
文档Document ".object"".object" {"a": "a"}{"a": "a"}

以经济高效的方式将历史数据存档Cost-effective archival of historical data

数据分层指在存储基础结构之间分隔数据,以适用于不同的方案,Data tiering refers to the separation of data between storage infrastructures optimized for different scenarios. 从而提高端到端数据堆栈的整体性能和经济高效性。Thereby improving the overall performance and cost-effectiveness of the end-to-end data stack. Azure Cosmos DB 借助分析存储,现在支持使用不同的数据布局将事务性存储中的数据自动分层到分析存储。With analytical store, Azure Cosmos DB now supports automatic tiering of data from the transactional store to analytical store with different data layouts. 相对于事务性存储,分析存储在存储成本方面实现了优化,你可以将操作数据保留更长时间,来进行历史分析。With analytical store optimized in terms of storage cost compared to the transactional store, allows you to retain much longer horizons of operational data for historical analysis.

启用分析存储后,你可以根据事务性工作负荷的数据保留需求,配置“事务性存储生存时间(事务性 TTL)”属性,以便超过特定时间后即自动从事务性存储删除记录。After the analytical store is enabled, based on the data retention needs of the transactional workloads, you can configure the 'Transactional Store Time to Live (Transactional TTL)' property to have records automatically deleted from the transactional store after a certain time period. 同样,你可以通过“分析存储生存时间(分析 TTL)”管理分析存储(独立于事务性存储)中保留的数据的生命周。Similarly, the 'Analytical Store Time To Live (Analytical TTL)' allows you to manage the lifecycle of data retained in the analytical store independent from the transactional store. 通过启用分析存储并配置 TTL 属性,你可以进行无缝分层,并定义两个存储的数据保留期。By enabling analytical store and configuring TTL properties, you can seamlessly tier and define the data retention period for the two stores.

全局分发Global Distribution

如果你拥有多区域分发的 Azure Cosmos DB 帐户,为容器启用分析存储后,它将适用于该帐户的所有区域。If you have a multiple-regionally distributed Azure Cosmos DB account, after you enable analytical store for a container, it will be available in all regions of that account. 对操作数据的任何更改都会将多区域复制到所有区域。Any changes to operational data are multiple-regionally replicated in all regions. 你可以高效地对 Azure Cosmos DB 中距离最近的区域的数据副本运行分析查询。You can run analytical queries effectively against the nearest regional copy of your data in Azure Cosmos DB.

安全性Security

对分析存储进行身份验证的方式,与对给定数据库的事务性存储进行身份验证的方式相同。Authentication with the analytical store is the same as the transactional store for a given database. 可以使用主密钥或只读密钥进行身份验证。You can use master or read-only keys for authentication. 可以利用 Synapse Studio 中的链接服务,以防止粘贴 Spark 笔记本中的 Azure Cosmos DB 密钥。You can leverage linked service in Synapse Studio to prevent pasting the Azure Cosmos DB keys in the Spark notebooks. 有权访问工作区的任何用户都可以访问此链接服务。Access to this Linked Service is available to anyone who has access into the workspace.

支持多个 Azure Synapse Analytics 运行时Support for multiple Azure Synapse Analytics runtimes

分析存储已经过优化,无需依赖计算运行时即可为分析工作负荷提供可伸缩性、弹性和性能。The analytical store is optimized to provide scalability, elasticity, and performance for analytical workloads without any dependency on the compute run-times. 存储技术是自行管理,无需手动操作即可优化分析工作负荷。The storage technology is self-managed to optimize your analytics workloads without manual efforts.

通过将分析存储系统与分析计算系统分离,可以同时从 Azure Synapse Analytics 支持的不同分析运行时中查询 Azure Cosmos DB 分析存储中的数据。By decoupling the analytical storage system from the analytical compute system, data in Azure Cosmos DB analytical store can be queried simultaneously from the different analytics runtimes supported by Azure Synapse Analytics. 目前,Synapse Analytics 支持 Apache Spark 和 SQL 无服务器使用 Azure Cosmos DB 分析存储。As of today, Synapse Analytics supports Apache Spark and SQL serverless with Azure Cosmos DB analytical store.

备注

只能使用 Synapse Analytics 运行时读取分析存储。You can only read from analytical store using Synapse Analytics run time. 可以将数据重写入事务性存储,将其作为服务层。You can write the data back to your transactional store as a serving layer.

定价Pricing

分析存储采用基于消耗的定价模型,计费项包括:Analytical store follows a consumption-based pricing model where you are charged for:

  • 存储:分析存储每个月保留的数据量,包括分析 TTL 定义的历史数据。Storage: the volume of the data retained in the analytical store every month including historical data as defined by Analytical TTL.

  • 分析写入操作:从事务性存储将操作数据更新以完全托管的方式同步到分析存储(自动同步)Analytical write operations: the fully managed synchronization of operational data updates to the analytical store from the transactional store (auto-sync)

  • 分析读取操作:从 Synapse Analytics Spark 和 SQL 无服务器运行时对分析存储执行的读取操作。Analytical read operations: the read operations performed against the analytical store from Synapse Analytics Spark and SQL serverless run times.

备注

Azure Cosmos DB 分析存储目前以公共预览版提供,免收任何费用。Azure Cosmos DB analytical store is currently available in public preview free of any charges.

分析存储定价与事务性存储定价模型不同。Analytical store pricing is separate from the transaction store pricing model. 分析存储中没有预配 RU 这一概念。There is no concept of provisioned RUs in the analytical store. 有关分析存储定价模型的完整详细信息,请参阅 Azure Cosmos DB 定价页See Azure Cosmos DB pricing page, for full details on the pricing model for analytical store.

若要为在 Azure Cosmos DB 容器中启用分析存储进行高级别成本估算,可以使用 Azure Cosmos DB 容量规划器,来获得分析存储和写入操作成本的估算值。In order to get a high-level cost estimate to enable analytical store on an Azure Cosmos DB container, you can use the Azure Cosmos DB Capacity planner and get an estimate of your analytical storage and write operations costs. 分析读取操作成本取决于分析工作负荷特性,但按照高级别估算,扫描分析存储中的 1 TB 的数据通常引发 130,000 个分析读取操作,产生的成本为 0.065 美元。Analytical read operations costs depends on the analytics workload characteristics but as a high-level estimate, scan of 1 TB of data in analytical store typically results in 130,000 analytical read operations, and results in a cost of $0.065.

分析生存时间 (TTL)Analytical Time-to-Live (TTL)

分析 TTL 表示应将容器的分析存储中的数据保留多久。Analytical TTL indicates how long data should be retained in your analytical store, for a container.

如果启用了分析存储,则无论事务性 TTL 配置如何,都会从事务性存储中将对操作数据执行的插入、更新、删除自动同步到分析存储。If analytical store is enabled, inserts, updates, deletes to operational data are automatically synced from transactional store to analytical store, irrespective of the transactional TTL configuration. 分析存储中操作数据的保留可以由容器级别的分析 TTL 值控制,如下所示:The retention of this operational data in the analytical store can be controlled by the Analytical TTL value at the container level, as specified below:

使用 AnalyticalStoreTimeToLiveInSeconds 属性设置容器中的分析 TTL:Analytical TTL on a container is set using the AnalyticalStoreTimeToLiveInSeconds property:

  • 若将此值设置为“0”、此值缺失(或设置为 null):将禁用分析存储,不会将任何数据从事务性存储复制到分析存储If the value is set to "0", missing (or set to null): the analytical store is disabled and no data is replicated from transactional store to analytical store

  • 若此值存在且设置为“-1”:无论事务性存储中数据的保留期是多久,分析存储都将保留所有历史数据。If present and the value is set to "-1": the analytical store retains all historical data, irrespective of the retention of the data in the transactional store. 此设置表示分析存储会无限期保留操作数据This setting indicates that the analytical store has infinite retention of your operational data

  • 若此值存在且设置为某个正数“n”:距在事务性存储中最后一次修改项“n”秒后,项将从分析存储中过期。If present and the value is set to some positive number "n": items will expire from the analytical store "n" seconds after their last modified time in the transactional store. 如果想要在有限的一段时间内将操作数据保留在分析存储中,而不考虑该数据在事务性存储中的保留期,可利用此设置。This setting can be leveraged if you want to retain your operational data for a limited period of time in the analytical store, irrespective of the retention of the data in the transactional store

考虑的要点:Some points to consider:

  • 使用分析 TTL 值启用分析存储后,可以在以后将其更新为其他有效值。After the analytical store is enabled with an analytical TTL value, it can be updated to a different valid value later.
  • 尽管可在容器或项级别设置事务性 TTL,但目前只能在容器级别设置分析 TTL。While transactional TTL can be set at the container or item level, analytical TTL can only be set at the container level currently.
  • 将容器级别的分析 TTL 设置为大于或等于事务性 TTL,即可将操作数据存档在分析存储中更长时间。You can achieve longer retention of your operational data in the analytical store by setting analytical TTL >= transactional TTL at the container level.
  • 将分析 TTL 设置为等于事务性 TTL,分析存储即可镜像事务存储。The analytical store can be made to mirror the transactional store by setting analytical TTL = transactional TTL.

在容器上启用分析存储时:When you enable analytical store on a container:

  • 在 Azure 门户中,分析 TTL 选项设置为默认值 -1。From the Azure portal, the analytical TTL option is set to the default value of -1. 可以通过导航到数据资源管理器下的容器设置,将此值更改为“n”秒。You can change this value to 'n' seconds, by navigating to container settings under Data Explorer.

  • 在 Azure SDK 或 PowerShell 或 CLI 中,可以通过将分析 TTL 选项设置为 -1 或“n”来启用该选项。From the Azure SDK or PowerShell or CLI, the analytical TTL option can be enabled by setting it to either -1 or 'n'.

若要了解详细信息,请参阅如何对容器配置分析 TTLTo learn more, see how to configure analytical TTL on a container.

后续步骤Next steps

若要了解更多信息,请参阅下列文档:To learn more, see the following docs: