MongoDB技术分析（4）-对象模型

MongoDB数据库的对象模型，用MongoDB的术语叫做Catalog，包括逻辑上的对象Database、Collection、View，以及偏物理概念的对象Shard、Chunk、Zone之类的。

对象模型

Shard

Shard是组成集群的物理节点，通常由一个复制集组成，Shard还可以设置多个tag标签，用于定制Collection数据的分布位置。

Database

和关系型数据库的Database概念相同，在MongoDB中仅是当做Collection的Namespace在使用，每个Database在创建时都会随机选择一个Shard作为其primary shard，用于存储其下的Non-Shard Collection数据，以及View的定义和执行。

Collection

Collection对应关系型数据库中Table的概念，支持Non-Shard Collection和Shard Collection两种类型，Non-Shard Collection的数据仅存储在所属数据库的Priamry Shard节点上，Shard Collection则打散存储在所有Shard节点上，或者具有对应tag属性的Shard节点上。

Chunk

Chunk是Collection的一段key range，Shard Collection以Chunk为单位打散存在多个Shard节点上，打散的方式支持range partition和hash partition两种方式。Chunk还是Rebalance的最小粒度，通过在不同Shard间迁移Chunk实现Shard间的负载均衡，Chunk还支持分裂，当单个Chunk容量达到阈值后触发分裂，生成多个Chunk。

Tags

Collection除了均衡打散到所有Shard节点外，还支持根据tag打散到制定Shard节点。可以给每个Collection的不同key range定位为特定的tag，这样这部分数据只会打散存储到拥有该tag定义的shard节点上，特别适合跨地域部署时的就近访问。

View

View是一个逻辑概念，是对同一个Database下，一个或多个Collection的只读操作定义，View的定义和执行由该View所在Database的Primary Shard执行。

Catalog的实现

上面的对象模型，除view外，都存储在ConfigServer的config数据库中，分别对应Collection为：

Mongos在处理DDL类的Command时，由catalog模块负责和ConfigServer交互操作对应的Collection，主要设计如下图所示：

ShardingCatalogManager和ShardingCatalogClient分别负责修改操作和只读操作，具体操作交由对应Shard对象执行，Shard再封装成Task交由固定的一个TaskExecutor线程执行。

这里有两个重要的缓存：

CatalogCache：缓存了所有Collection的ChunkMap，即Chunk在Shard的分布视图，读写操作通过查找该缓存来判断操作涉及哪些Shard节点；

ShardRegistry：缓存所有Shard节点和ConfigServer节点的连接及版本信息；

.......................... END..........................