DatabaseHolder：负责创建、关闭、获取DB。
Database：Database的入口，是Database的类的实现，提供了Collection的创建销毁接口。
StorageEngine：存储引擎的抽象类，各类存储引擎事实上都是继承于StorageEngine。
KVEngine：KVStorageEngine实际是调用这个类的操作。
WiredTigerKVEngine：KVEngine实际也只是一个抽象类，具体的实现由WiredTigerEngine完成，我们关心的Wiredtiger存储引擎的工作就是从这开始的，从上层来看，这里就是WiredTiger存储工作的起始；而从下层看，这里只是向外提供了一层接口，真正的使用是在各接口中调用WT的方法。
RecordStore：各类存储引擎的实现类具体工作只是创建RecordStore（以下简称RS），真正负责数据的读取存储都是在RS中完成。
ServiceContext：负责在启动时设置系统环境，StorageEngine的设置也是在其中完成。
CatalogEntry：各类CatalogEntry，几乎每一层概念都会有一个CatalogEntry，其会有一些辅助功能，但这种类的意义我还不是太理解。
1. DB的创建
代码如上所示，如果这个dbname不存在就会创建，Collection也是如此。所以可以看到Mongo创建DB的逻辑。
- 首先得到dbname，然后检查是否已经存在这个DB，如果没有，就开始创建过程。
- 获取storageEngine，在启动的时候storage engine就被设置好了。由storage engine获取 DatabaseCatalogEntry。
- 由dbname、entry创建DB，并将DB保存到map中。
2. 创建Collection
创建Collection的过程如下代码所示，我们从Database类的CreateCollection方法开始。至于这个方法在哪里调用有兴趣的可以去跟踪。
- 前面看到创建DB时传入了DatabaseCatalogEntry，第一步就是通过这个entry的CreateCollection创建，但你继续跟踪的话会发现，这个步骤正如注释的在创建用于存储Collection数据的文件，Mongo的底层并没有区分db，Collection，而是将db.collection作为键值生成一个唯一的文件名，每一个db.collection都是唯一的，对应着一个文件。在后面数据格式的章节会详细说明。
- 紧接着这第一步的基础上创建真正的Collection实例，因为第一步会得到RS，而RS是真正存储的地方。
如下代码是WT创建RS.
如下代码是插入一条数据在WiredTigerRecordStore的接口操作。
3. WT对数据的组织
虽然对用户而言，DB->Collection->Record层次关系十分清晰，但到了底层数据的存储就不在保留这些关系。
WT将db.collection作为一个键值，通过算法计算得到对应的一个唯一的字符串，因为db.collection是唯一的，所以得到这个唯一的字符串也不是什么难事，然后将这个字符串作为文件名生成一个Collection文件，相应的也会生成一个索引文件。在Collection文件中记录着KV对，其中这个Value是插入的数据，而Key是自动加1的。对于每个collection，key都是从0开始递增，然后index文件会生成对应的索引。形式如下：
说明：上述数据组织很多是个人分析后的推测，具体的生成文件名的方法没有具体看。除了各自的Collection插入KV是自增外，另外应该还会有一个全局的自增，记录每一个DB.Collection。这条记录作为系统的元数据，我暂时不能确定是存在wiredtiger文件还是在collection-0文件。图片引用自：https://yq.aliyun.com/articles/65?spm=5176.100240.searchblog.47.IU5fhf
引用：
