上回说到，勤劳勇敢的中国人民，受到《康熙字典》中古老的智慧启发，在对象存储中引入了索引，帮助“觅影”产品快速地从对象存储中筛选出了带有covid-19和Sternum这两个标签的影像用于深度学习。
实际上，这是实现了在海量非结构化数据中进行查询的功能，也就是搜索引擎——互联网的基本“轮子”。
如果Swift重新发明轮子……相当于自己重新写一个搜索引擎，工作量是可想而知的。
厚厚的OpenStack文档指出，重新发明轮子不可取，专业的事情交给专业的组件办最好！
https://wiki.openstack.org/wiki/Swift/ideas/metadata-sync
在这个链接中，Swift团队聪明地将专业的事情交给了专业的人——ElasticSearch。
ElasticSearch实际上是一个分布式的搜索引擎。它本身支持JAVA API， RestAPI等接口，可以在海量非结构化的文本和key-value数据中，秒级时间返回搜索结果。
我们在上期提到，对象存储的metadata，实际上就是key-value的键值对形式的数据。
让我们举一个栗子。
Johnny同学搞到了一本《金瓶梅》，打算把它保存在对象存储里面。为了防止被查出，Johnny同学想起来少年时代把《陆小凤》套上语文书皮看的行为。
老师发现了Johnny的异常行为，点了Johnny的名，让他回答问题：
“刀是什么样的刀？”
“金丝大环刀！”
“剑是什么样的剑？”
“洗浴大宝剑！”
“啪！”
一个耳光，Johnny醒了，原来是个梦。
Johnny想到，如果把《金瓶梅》的文件名改了，在metadata中标注文件名，就可以不会被查出了。
Johnny将《金瓶梅》改名为：
xygdxdhbhshw.doc
并且上传到swift的对象存储，在metadata里面写入：
“BookName: Golden_Bottle_Palm"
这样，《金瓶梅》就摇身一变，变成《下一个倒下的会不会是华为》了。
上传的命令行如下：
curl -i publicURL/johnny/xygdxdhbhshw.doc -X POST -H "X-Auth-Token:
Swift接收了这个http请求后，一方面将xygdxdhbhshw.doc存入johnny的存储桶中，另一方面，需要对接elasticsearch，存储这样一条metadata：
BookName: Golden_Bottle_Palm
光阴似箭。
随着时光流逝，Johnny同学已经忘记了《下一个倒下的会不会是华为》实际上是《金瓶梅》，想翻出金瓶梅复习一遍却在自己Swift的存储桶中遍寻不得的时候，突然想起来自己用metadata标识过金瓶梅：
BookName: Golden_Bottle_Palm
Johnny调用Swift的API搜索这个对象，Swift就可以在elasticsearch中查找到
$publicURL/johnny/xygdxdhbhshw.doc
的结果。
果然，ElasticSearch是一个好东西！
显然，ElasticSearch迅速地在海量metadata中返回所查询的键值，一定不是通过遍历所有数据实现的——这在时间上无法接受。实际上，ElasticSearch就是通过所谓的索引机制，实现了快速根据关键字查找到对象的功能。
实际上，绝大部分IaaS云服务提供商实现的对象存储，都包括了类似的查询与索引功能。
以腾讯云的COS (Cloud Object Storage)为例，可以设定用户自定义的x-cos-meta-[自定义后缀]，来存储用户自行设定的metadata，并可以通过sql等方式查询metadata。当然，大部分用于生产的商用对象存储的查询与索引功能，并没有用到ElasticSearch这么强大的工具，而是自己建立轻量级的索引系统实现。
当然，如果我们想把对象存储用于生产业务，仅仅提供基于http的RestAPI、一致性哈希、查询与存储功能，还是不够的。
请看下回分解。
