上手DocumentDB On Azure(三)
本节主要是在前两天上初步体验了一下DocumentDBConsoleApp之后,补了一下部分基础知识.
- 数据库的一致性级别
- DocumentDB的计费
- DocumentCollection的索引策略的设置
- DocumentDB中各种资源的关系
因为DocumentDB以确定并入CosmosDB,所以本部分内容中大量DocumentDB和CosmosDB混用的情况,把他们理解为一个东西就好.
从Azure外网的ManualDocument上已经能看到,CosmosDB的字样了.之前的(2015-2017)DocumentDB将并入CosmosDB中成为其一个子功能.但截至5-15日,相关中文介绍中还没有变更过来.
下图为英文开发文档和中文的对比,可以发现中文还在使用DocumentDB的字样.
数据库的一致性级别
看了一些资料,终于对一致性有了一点了解:传统数据库是集中存储的,所有人都访问的是一个数据库,不牵扯到数据同步问题,每个访问得到的结果都是相同的.
有了分布式数据库,就有了2点或多点数据库之间数据同步的问题.试想北京和西雅图2个数据中心,分配在北京数据中心的用户老张发了一条消息(比如红包吧),北京的数据库接受并更新了消息.就在它发消息的1秒后,同在北京的小赵发现了红包(动动手指,含含糊糊);可在西雅图的小张(接入的是西雅图数据中心),它可能看到的还是10秒甚至10分钟前老张的状态,假如北京与西雅图的数据库同步被永久阻断,那么小张可能永远不知道老张发了一个红包.数据中心与数据中心之间同步更新的规则,在这里被称为一致性.
分布式数据库:Distribute Database
一致性:Consistency
关于一致性的背景:
传统分布式数据库(包括谷歌最近发布的Cloud Spanner）只有两种一致性模型：
强一致性（strong consistency）和最终一致性（eventual consistency）。比如说，就强一致性而言，只要数据被写入到数据库，所有的不同节点（这些节点可能分布于全球各地的数据中心）都要先就一个新的值达成一致，之后新的值才出现在应用程序中。任何时刻，任何用户或节点都可以读到最近一次成功更新的副本数据。由于这种方法增添了延迟，这在性能方面显然存在着一些不足。
最终一致性实际上是一种比较宽容的系统；所有节点并不同时更新，而是只有在一段时间没有任何最近的更新后，才就某个值达成一致….
来自 <http://www.bjqnw.com/2017/0511/712960.html>
CosmosDB提供了三种新的一致性模式:
|
|
大概的意思
Bounded Staleness:对过期进行限制的模式,官名叫"受限停滞".看了文档,其中通过时间间隔t(interval)来配置的模式比较好理解:Strong Consitency是一脚闷死刹车的话,这个就是点刹.而另一种"读取操作比写入操作滞后的文档版本 K 数"就是prefixes k来配置,完全不明觉厉了!
Session:会话一致性.官方文档说的好:单纯读一致,单纯写一致,自己读自己写入的一致,"写入根据读取一致",还有一些看不懂.
Consistent Prefix: 前缀一致性.在最终一致性的基础上确保前缀一致性.
|
DocumentDB 中的可优化数据一致性级别 来自 <https://docs.microsoft.com/zh-cn/azure/documentdb/documentdb-consistency-levels> |
关于索引(index)和前缀(prefix),如下3篇文章已经足够了解他们的概念的了:
-
什么是索引:
索引好比字典的检字表,它把检索信息和data的位置(内存地址)建立了关系,通常它是一个B-tree,索引会占用内存(新华字典的拼音检字表也要好几页,更何况还有偏旁检字表和笔画检字表,它们共同组成了字典的索引层),同步索引会消耗流量.
-
NoSqlDatabase中的索引层
非关系型数据库的索引层其实与关系型数据库类似,索引可以单字段,复合,多Key及其他方式索引,建立和变更索引需对Data层数据进行排序
CosmosDB的数据单元是以DocumentCollection来配置的,因此索引层建立在collection层上.
|
MongoDB索引原理 |
-
什么是前缀:
前缀Prefix相当于是索引层的索引,比如一个由船名组成的索引,用船名的前5个字母组成Prefix,同时映射Index的每一条元素,大概就是下边的关系.
主要解决分布式数据库之间快速传递数据的问题:如果同步数据索引层还是太慢的话,那同步前缀无疑在性能上更有优势.
也正因为索引层对Prefix的需求,其ID值(Primary Key)必须为string类型,而不是int类型.因为数据库会自动为ID生成索引和Prefix.
|
|
|
前缀索引，一种优化索引大小的解决方案 来自 <http://www.cnblogs.com/wbzhao/archive/2012/04/01/2428219.html> |
DocumentDB的计费
|
吞吐量: |
Throughput |
|
吞吐量: |
Request Unit (RU) |
|
每秒请求单位数: |
RU/S |
|
保留(预配)吞吐量: |
Reservation Throughput |
Db的核心资源: CPU、内存和 IOPS
建collection时预配吞吐量,即使这部分吞吐量为0也要按照预配的额度付费.
当预配吞吐量达到符合上限时,系统自动新建一个副本分区,然后在副本分区上提供服务和计费.
DocumentCollection的索引策略的设置
在新建collection时需要考虑如下因素,他们会直接影响RU,然后在配置collection时合理配置他们.
- 文档大小。随着文档大小的增加，用来读取或写入数据的单位数也随之增加。
- 文档属性计数。假设默认为所有属性创建索引，用于写入文档的单位数将随着属性计数的增加而增加。
- 数据一致性。当使用"强"或"有限过时"的数据一致性级别时，将占用更多单位数来读取文档。
- 已创建索引的属性。每个集合的索引策略都可确定默认情况下要进行索引的属性类别。通过限制已创建索引的属性数目或通过启用延迟索引编制，可以减少请求单位消耗。
- 文档索引。默认情况下，将自动为每个文档创建索引，如果你选择不为其中一些文档创建索引，则将占用更少的请求单位。
- 查询模式。查询的复杂性会影响操作使用的请求单位数量。谓词数、谓词性质、投影、UDF 数和源数据集的大小都会影响查询操作的成本。
- 脚本使用情况。正如查询一样，存储过程和触发器也是根据所执行的操作的复杂性来使用请求单位的。在开发应用程序时，检查请求费用标头，以更好地了解每个操作消耗请求单位容量的方式。
来自 <https://docs.microsoft.com/zh-cn/azure/documentdb/documentdb-request-units>
DocumentDB中各种资源的关系
用户和权限配置在数据库层
索引模式在集合层
默认一致性配置在账户层
一致性配置是基于单个请求配置的,也就是说查询,读取请求和写入请求都可以配置单独的一致性,来实现某种特殊的需求:
|
一致性的粒度归并为单个用户请求。写入请求可对应于插入、替换、更新插入或删除事务（执行或不执行关联的前置或后置触发器）。或者，写入请求可对应于针对某个分区中的多个文档运行的 JavaScript 存储过程的事务执行。与写入操作一样，读取/查询事务也归并为单个用户请求。用户可能需要在跨越多个分区的大型结果集中分页，但每个读取事务归并为单个页面，并从单个分区内部进行。
来自 <https://www.azure.cn/documentation/articles/documentdb-consistency-levels/>
|
