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，其会有一些辅助功能，但这种类的意义我还不是太理解。
代码如上所示，如果这个dbname不存在就会创建，Collection也是如此。所以可以看到Mongo创建DB的逻辑。
首先得到dbname，然后检查是否已经存在这个DB，如果没有，就开始创建过程。获取storageEngine，在启动的时候storage engine就被设置好了。由storage engine获取 DatabaseCatalogEntry。由dbname、entry创建DB，并将DB保存到map中。创建Collection的过程如下代码所示，我们从Database类的CreateCollection方法开始。至于这个方法在哪里调用有兴趣的可以去跟踪。
前面看到创建DB时传入了DatabaseCatalogEntry，第一步就是通过这个entry的CreateCollection创建，但你继续跟踪的话会发现，这个步骤正如注释的在创建用于存储Collection数据的文件，Mongo的底层并没有区分db，Collection，而是将db.collection作为键值生成一个唯一的文件名，每一个db.collection都是唯一的，对应着一个文件。在后面数据格式的章节会详细说明。紧接着这第一步的基础上创建真正的Collection实例，因为第一步会得到RS，而RS是真正存储的地方。如下代码是WT创建RS.如下代码是插入一条数据在WiredTigerRecordStore的接口操作。
虽然对用户而言，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
引用：
https://yq.aliyun.com/articles/65?spm=5176.100240.searchblog.47.IU5fhfhttps://yq.aliyun.com/articles/61?spm=5176.8091938.0.0.uN6vY4 相关资源：七夕情人节表白HTML源码(两款)