对象存储，一般地，我们认为是指对于给定的唯一的key，获取对应的value。这其实是一种map的数据结构，它仅仅是根据提供的key这单一因素获取指定的value。这里的map指带的是路由的map，非本地基于内存的数据映射，因为路由经常是分布式系统需要重要考虑的因素，也是影响性能的重要因素。对象存储一般用来存储小文件，其大小一般在KB～20MB之间（KB～10MB），如果从终端用户的角度看待对象存储，那么这个key就是一个filepath（文件系统中的称谓）或者存储系统中的url，而value就是文件内容。从这个角度来讲，对象存储系统就是实现了文件URL到文件内容的CURD服务。
在具体实现时，根据不同的约束条件或者限制，可能具有不同的实现设计。在此，先不评头论足，仅仅横向记录下可用的选择，以及对其设计进行抽象总结，进而以帮助分析其“秋色如何”。
为了表述严谨，我们将真正获取到存储数据实体地址之前的路由过程称之map的过程。
有的设计中，在获取到value之前，需要1次或者多次用到递进式map方能获取到需要的value，而多次递进式map可能会有多次网络链路请求。比如HDFS，文件的key为HDFS://filepath，在获取文件内容时，需要map[filepath] -> [blocks: dns]，进而定位到存储数据的实体，获取value，即文件内容。在比如HBase，tableName+rawkey就是记录的url，而获取rawkey对应的内容，或者一行记录，需要至多经过3次递进式map+1次HDFSmap，map[tableName, raowKey]->root table -> meta table -> region server ， 再经过map[HFile]->[HDFS blocks, dns], 定位到具体的存储数据的实体（这里是datanode）即可获取数据。
有的设计中，在获取value时，仅需要0次map就可以定位到存储数据的实体，目前为止，这种设计的寻址方式是基于计算，而非查询。比如Ceph，在获取到整个CRUSH map后，仅仅通过一致性算法计算便可得到存储数据的地址，进而就可以获取数据本身。这里的key一般是指object_id，而object_id可由bucket + filepath + sharding/stripping组合而成。在比如Redis，对于给定的key，可以通过一致性hash算法计算出记录对应的redis实例地址。
有的设计中，在借鉴前两种设计的基础上，进行自己的扩展设计。典型的设计方式是，在获取底层存储数据元数据时，采用前面两种设计中的一种，而获取真正的value时进行另外的设计。比如采用HBase作为用户文件到底层存储系统的key的映射，而key是由底层存储系统产生的，它具有唯一性。这样key的设计就比较灵活，可以是一个64位的串，可以是一个128位的串，也可以是数据库的primaryid，当然也可以是md5串，这取决于如何设计key到存储实体的映射以及实体如何管理众多的对象。在这种设计方式中，key到存储实体dn的获取有两种方法，一是通过查询，一是通过计算。
以上设计，暂不进行“华山论剑”，但是其分析的过程，就映射着各自不同的特点。接下来，从整体上，基于另外一个角度，谈一谈自己的思考。在此谈论的对象存储设计思路都是基于一对一查询，即用户提供某种形式的url，获取相关内容，而对于多条件查询并未涉及。
一对一的key到value的查询一般应用于一次仅处理一个对象的系统或者一次处理多个确定对象的系统。比如对于静态网页，网页中嵌入的多张静态图片，或者新闻报道中嵌入的多张图片等等。这种应用非常常见，也确实是对象存储系统的用武之地。但是最近几年机器学习或者深度学习技术如火如荼，基于标记的数据获取作为训练样本可能更加具有意义，而这离不来多条件查询机制。比如获取大量标记为人群活动、像素大小在800*800、生活在北京的图片作为AI算法的训练样本。这对对象存储系统有了更高的要求。 关于这部分的对象存储设计，因今日天色已晚，待日后补充
201811102340pm 记 北京 西坝河 周六 双11前夕