Cloudant NoSQL DB是一款基于Couch DB的分布式存储的文档型数据库。下面将通过数据存储结构让大家对Cloudant NoSQL DB有基本的了解。
数据存储结构
在IBM Cloud中，每一个Cloudant数据库都会由一个或多个分片组成，每一个分片都是数据库文档的子集。同时，每一个分片又会根据集群服务器的数量生成对应数量的副本分别存储在服务器中。
数据库中的每个文档都存储在单个分片上。因此，对于任何单个文档请求，拥有大量分片可实现更高的并行性。原因是协调程序仅将请求发送到保存该文档的节点。因此，如果数据库有许多分片，那么很可能其他许多节点都不需要响应该请求。这些节点可以继续处理其他任务，不会因协调程序请求而中断。
为了响应查询请求，数据库必须处理来自所有分片的结果。因此，拥有更多分片将产生更高的处理需求。原因是协调程序必须对每个分片发出一个请求，然后组合这些结果，再将响应返回给客户端。合理地设置分片数量能够保证性能。
分布于每台服务器的文档都是通过B树存储在磁盘上，当数量越大时，B树的层数也就越多，由于更多的数据需要从缓存或磁盘读取而使得响应时间变长。官方给出的建议是每个分片最多不要超过1000万，分片容量最好在10GB以下。分片越小就越容易通过网络进行Rebalancing操作。
Cloudant 与 CAP
CAP原则是指对于分布式系统中只能满足一致性（Consistency），可用性（Availability），分区容错性（Partition
Tolerance）中的两点，不可能同时满足。通过上面的介绍相信大家已经了解了Cloudant的数据存储结构，那么Cloudant满足CAP中的哪两个要素呢？
答案就是Cloudant同时满足可用性和分区容错性，这一点与Zookeeper不同。Zookeeper是主从机制，当主节点不工作时，会通过选举机制选出新的主节点，但是在选举期间整个系统是不能提供服务的，直到选举结束，因此Zookeeper是CP的。
Cloudant集群中的任何一个节点都可以提供读写操作，这一属性牺牲了节点之间数据的一致性，有可能会因并发写操作导致冲突。为了解决冲突，Cloudant引入了多版本并发控制（MVCC）从而实现最终一致性，保证数据库所有节点都只包含文档的最新版本。
这里有个关于Cloudant最终一致性的小知识点——R和W参数。R应用于读操作，W应用于写操作。其作用类似，当Replica数量改变时，R和W也会相应调整。这里简单对R做下说明：
在发起请求对数据库进行读操作时，R的大小控制了在请求返回结果之前处理请求的集群节点数量。R越大，要求参与请求的节点数就越大，越能够保证用户获取的是最新的数据，相反R越小，响应的速度也就越快，但是一致性的保证就要差一些。以下示意图说明了了R值大小对读操作可能产生的影响。
结语
刚刚带大家了解了Cloudant NoSQL DB的数据存储结构和设计思路，下一篇文章将带大家了解Cloudant数据库的分区以及存储文档的基本属性，欢迎持续关注。
