CEPH VERSION： Quincy 17.2.6
BlueStore极为庞大复杂，包含的Types远不止上图这些。所以，采用切换视角的方式，每次只观察一个方面，分析理解一个部分，抽丝剥茧，最终达成完整的认知。
把视线聚焦到BlueStore中，用于表达用户数据的数据结构上，忽略掉组件、流程、过程数据相关的数据结构，最后，得到上面的两部分数据结构以及数据之间的关系。
OnDisk Types
这部分数据是最终保存到RocksDB中的，它们被序列化，而后不同类型以不同的PREFIX保存为RocksDB K-V条目。
这些类型被设计为尽可能的独立，类型之间尽可能少的呈现组合关系，而一些类型之间，通过offset进行微妙的逻辑关联。这样设计的好处在于每种类型可以独立的encode、decode，可以方便而且小代价的进行局部修改，尽量少的冗余信息使得存盘容量小，减少BlueStore整体的元数据占用空间。InMemory Types
这部分数据结构只在BlueStore被OSD等进程加载后，存在于内存中，它们与OnDisk Types存在直接或间接的对应关系。它们能够依靠OnDisk Types从盘上读出并decode后，在内存进行完整的构建以及关联。
与OnDisk Types的显著不同有几点：InMemory Types有更多的辅助性的、无持久化需求的字段；类型之间有复杂的组合、继承、共享等关系，这更加符合面向对象的设计，便于组件流程的编程使用；组合类型间通常有着双向的关联字段，便于在类型间高效的导航；大多数的对象引用为智能指针的方式，降低了内存管理的压力和风险，也更符合现代C++习惯。
剥离一些非关键细节，进一步抽象后，类型关系呈现为下图
Collection
PG在BlueStore中对应的内存元数据管理类型，每个PG在BlueStore中有一个对应的Collection对象常驻内存。每个Collection有一个OpSequencer对象用于IO保序，这意味着在BlueStore中，仍然遵守OSD上层的PG内IO保序要求。OpSequencer的详细工作机制将在后续文章分析。
Collection通过对应的bluestore_cnode_t类型成员cnode关联到具体的pgid。
Collection关联着两个Cache分片，分别是数据缓存(BufferCacheShard)和元数据缓存(OnodeCacheShard)。两种分片的确定，均是通过pgid进行hash映射。本篇不对BlueStore Cache做深入分析，此处只需意识到它们的存在即可。
Collection通过OnodeSpace类型成员onode_space来管理本PG下的object元数据OnodeSpace
OnodeCacheShard *cache成员由Collection创建时，由pgid做hash映射确定后传入。
unordered_map<ghobject_t,OnodeRef> onode_map成员则管理着本PG下已加载到内存的Onode对象引用，使用unordered_map来实现最快的objectID查找Onode。Onode
一个对象的元数据内存结构。由于boost::intrusive_ptr的要求，它自己管理着引用计数。bluestore_onode_t onode成员对应着它的OnDisk数据结构。ExtentMap extent_map成员则是它与盘上数据映射关系的内存管理结构。ExtentMap
包含若干个逻辑上不一定连续的Extent对象，整个ExtentMap包含了该object所有数据在盘上的所有映射区间Extent
代表着object的一段数据的映射信息，它关联到一个Blob，并记录这段数据该Blob中的偏移和长度。Blob
它是OnDisk结构bluestore_blob_t的内存对应结构，受到参数bluestore_max_blob_size(默认64KB)的限制，当Blob过大时会发生分裂。Blob结构使得大object的元数据和数据均被分割为合适粒度的多个片段，每个片段能够独立的被读写、变更，有效控制元数据的读写放大。bluestore_blob_t
Blob的OnDisk对应结构，其中包含了若干个bluestore_pextent_t，后者记录了一个offset和length，代表Block设备上的一段物理区间。
csum相关的成员记录了校验和相关信息，包括校验码类型、分段校验的分段长度、以及整个Blob的校验和(csum_data)
最后，借用一张网上画得很直观的一张图，进一步清晰的展现上述各数据结构的映射关系。
