Azure Cosmos DB小白入门

COSMOS DB

介绍

Azure Cosmos DB 是一种用于新式应用开发的完全托管的 NoSQL 数据库。 个位数的毫秒响应时间以及自动和即时的可伸缩性，可保证任何规模的速度。 高可用性和企业级安全性可确保业务连续性。 得益于全球各地的统包多区域数据分布、适用于常用语言的开源 API 和 SDK，应用的开发速度更快、效率更高。 作为一项完全托管的服务，Azure Cosmos DB 使用自动管理、更新和修补，使你无需进行数据库管理。 它还通过经济高效的无服务器和自动缩放选项处理容量管理，这些选项可响应应用程序的需求，使容量与需求相匹配。

Azure Cosmos DB对于任务关键性应用程序提供多区域，分布式，多模型数据库模型。

Azure Cosmos DB 旨在提供低延迟、吞吐量的弹性可伸缩性、定义良好的数据一致性语义和高可用性。

可将数据库配置为全局分布，并使其可在任何 Azure 区域中使用。 为了降低延迟，请将数据放置在更靠近用户的位置。 选择所需的区域数目取决于应用程序的全球覆盖范围以及用户所处的位置。

使用 Azure Cosmos DB 可以随时添加或删除与帐户关联的区域。 无需暂停或重新部署应用程序即可添加或删除区域。

全局分布的重要优势

使用新式多主数据库复制协议，每个区域都支持写入和读取。 多主数据库功能还可以实现：

• 无限弹性写入和读取可伸缩性。
• 在全球 99.999% 的读写可用性。
• 在 99% 的时间内，在 10 毫秒内为读写提供服务。

应用程序可以在为数据库选择的所有区域中执行近乎实时的读写。 Azure Cosmos DB 在内部处理区域之间的数据复制，并保证提供所选的一致性级别。

在全球多个区域运行数据库可以提高数据库的可用性。 如果一个区域不可用，其他区域可自动处理应用程序请求。 Azure Cosmos DB 为多区域数据库提供 99.999% 的读取和写入可用性。

资源模型

Azure Cosmos DB 是完全托管的平台即服务 (PaaS)。 若要开始使用 Azure Cosmos DB，首先需要在订阅的 Azure 资源组中创建一个 Azure Cosmos DB 帐户。 然后，在帐户中创建数据库和容器。

容器

Azure Cosmos DB 容器用于存储数据。 与具有较大 VM 大小的纵向扩展的大多数关系数据库不同，Azure Cosmos DB 为横向扩展。数据存储在一个或多个服务器上，称为分区。 为了增加吞吐量或存储，会添加更多分区。 这为容器提供了几乎无限量的吞吐量和存储。 创建容器时，需要提供分区键。 这是从文档中选择的要存储的属性。 然后，该属性的值用于将数据路由到要写入、更新或删除的分区。 它还可用于查询中的 WHERE 子句，以实现高效数据检索。

Azure Cosmos DB 中数据的基础存储机制称为物理分区。 这些可以具有高达 10,000 RU/s 的吞吐量并存储多达 50 GB 的数据。 Azure Cosmos DB 使用可存储多达 20 GB 数据的逻辑分区对此进行抽象。 随着添加更多分区，逻辑分区允许服务为基础物理分区上的数据提供更大的弹性和更好的管理。

项

根据所使用的 API，数据可以表示容器中的一个项、集合中的一个文件、表格中的一行或者图形中的一个节点或边缘。

计费单位

所有数据库操作的成本将由 Azure Cosmos DB 规范化，并以“请求单位”（简称 RU）表示。 可将请求单位视为性能货币，它抽象化了执行 Azure Cosmos DB 支持的数据库操作所需的系统资源，例如 CPU、IOPS 和内存。

对于一个 1 KB 的项，执行点读取（按 ID 和分区键值提取单个项）的成本是 1 个请求单位（或 1 RU）。 以类似方式为其他所有数据库操作分配 RU 成本。 不管使用哪个 API 来与 Azure Cosmos 容器和数据库操作交互，都始终以 RU 来计量成本。 无论数据库操作是写入、点读取还是查询，都始终以 RU 来计量成本。

总的来说，我们设置的Azure CosmosDB RU数值越高，则表示该CosmosDB的读写的性能越好。但是每个小时的单价越贵。

在估计你的工作负荷消耗的 RU 数量时，请考虑以下因素：

• 项大小：随着项的增大，读取或写入该项所要消耗的 RU 数也会增加。

• 项索引：默认情况下会自动为每个项创建索引。 如果选择不为容器中的某些项创建索引，则消耗的 RU 数将会减少。

• 项属性计数：假设所有属性采用默认索引，写入某个项所要消耗的 RU 数会随着项属性计数的增加而增加。

• 带索引的属性：每个容器的索引策略都可确定默认情况下要进行索引的属性类别。 若要减少写入操作的 RU 消耗，请限制带索引的属性数目。

• 数据一致性：在执行读取操作时，非常一致性和有限过期一致性级别消耗的 RU 数大约比其他宽松一致性级别要多两倍。

• 查询模式：查询的复杂性会影响操作使用的 RU 数。 影响查询操作成本的因素：

  • 查询结果数
  • 用户定义的函数数目
  • 源数据的大小
  • 结果集的大小

  对相同数据的相同查询在重复执行时始终消耗相同数量的 RU。

分区

• 逻辑分区：存储于同一分区键值关联的所有数据

  以数据库的某一字段作为分区键，具有同一值的Field就会被轨道同一个逻辑分区里去。例如：有一组车辆的数据vehicle_data,以其车辆的Vin作为分区键，那么同一个Vin的数据文档就会被归纳到一个逻辑分区之中。

• 物理分区：对应固定数量的预留SSD存储+计算资源

对应实际的物理资源块，每一个物理分区都有自己独立的SSD存储、计算机资源、 CPU、 IO等等资源。容器是通过在物理分区之间分配数据和吞吐量来进行缩放的。 在内部，一个或多个逻辑分区映射到一个物理分区。 通常，较小的容器会有许多逻辑分区，但这些容器只需要一个物理分区。 与逻辑分区不同，物理分区是系统的内部实现，并且全部由 Azure Cosmos DB 管理。

容器中的物理分区数依赖于以下各项：

• 预配的吞吐量（每个单独的物理分区最多可以提供每秒 10,000 个请求单位的吞吐量）。 由于每个逻辑分区仅会映射到一个物理分区，若物理分区受到 10,000 RU/秒的限制，则意味着逻辑分区也会受 10,000 RU/秒的限制。
• 总数据存储量（每个单独的物理分区最多可以存储 50GB 数据）。

1. Cosmos DB在少量物理分区之间分配逻辑分区
2. 从应用角度：为每个容器定义一个分区

有一份车辆的文档数据，其中一个属性VIN，当有此文档写入的时候Cosmos DB的后台会根据hash原则

来对这个字段的值进行hash的分配，然后把这个逻辑分区对应到对应的物理分区当中去。由于不同的vin的hash值可能相同，因此理论上一个物理分区上可能存在多个不同的逻辑分区。

通过hash分配的原则当大规模的文档被同时写入的时候，Cosmos DB可以以这种分布式的方式快速的占到不同的物理资源，通过不同的物理分区他自己的独立资源，来保障每一个分区的读写效率，从而保障整体的读写效率。

Tip：

在传统的关系性数据库当中一般会限制分区数量，但是对于Cosmos DB设计思想而言，概念恰恰相反，Cosmos DB不在乎用户有多少分区数，理论上可以无限添加分区数，它提倡我们的每个分区的数量尽可能多，数据尽可能的分散到不同分区之上。

索引

默认情况下，Azure Cosmos DB 自动对容器中所有项的每个属性编制索引，不用定义任何架构或配置辅助索引。

当我们初始化一个容器的时候，Cosmos DB的默认设置所有属性都会被归入索引，因此在我们查询的时候不论怎么查都是会使用到索引。这样会大大的提高我们的数据读取效率。但是对于有大量的写数据的业务需求的时候，效率就会降低。

1. 从项到树

每次在容器中存储项时，项的内容都投影为 JSON 文档，然后转换为树表示形式。 这意味着，该项的每个属性都在树中以节点的形式表示。 伪根节点被创建为项的所有第一级属性的父级。 叶节点包含项带有的实际标量值。

例如，请看以下项：

{
        "locations": [
            { "country": "Germany", "city": "Berlin" },
            { "country": "France", "city": "Paris" }
        ],
        "headquarters": { "country": "Belgium", "employees": 250 },
        "exports": [
            { "city": "Moscow" },
            { "city": "Athens" }
        ]
    }

它由以下树表示：

2. 从树到属性路径

Azure Cosmos DB 将项转换为树的原因是，它允许通过这些树中属性的路径来引用属性。 若要获取属性的路径，可从根节点到该属性来遍历树，并将每个遍历的节点的标签连接起来。

下面是上述示例项中每个属性的路径：

• /locations/0/country:“Germany”
• /locations/0/city:“Berlin”
• /locations/1/country:“France”
• /locations/1/city:“Paris”
• /headquarters/country:“Belgium”
• /headquarters/employees:250
• /exports/0/city:“Moscow”
• /exports/1/city:“Athens”

写入项时，Azure Cosmos DB 会有效地对每个属性的路径及其相应的值编制索引。

自动伸缩

每一个物理分区都有各自的SSD存储，因此每个物理分区都会有各自的存储上限，当某一分区的数据达到饱和后，Cosmos DB后台会自动进行拆分，生成一个新的物理分区，将不同的逻辑分区数据挪到新的物理分区中，新的物理分区依旧遵循逻辑分区的规则。这样以来不会因为物理分区的数据过饱和导致读写效率的降低。

tips：同一个逻辑分区是不能拆分到两个物理分区上去。这意味着逻辑分区的存储是有上限的。一般是20GB。如果数据量过大的时候可以考虑符合键分区 例如：VIN + datatime。