像非结构化数据一样存储结构化数据

这个命题看起来有点绕，在通常的存储中，尤其是面向关系型的数据库存储中，我们通常是把所有的数据按照结构化，进行数据存储。

这样所有的数据不论从哪个维度进行查询、索引和修改，都针对特定的数据单元修改就可以了。

但在很多应用场合，存在大量的结构化但又不容易统一存储的数据，举个例子，我们在写一个工厂的设备管理系统，通常为便于保存处理，在存储层会构建两种表，一张用于存储设备分类，另一张用于记录设备的明细。在界面显示时，很简单的主从关系，但是问题来了，工厂的设备千千万，都有各自的属性，我们没法统一在一种结构中，将所有的设备属性信息描述清楚，但问题总是要面对的，将独立的设备结构化数据，直接存储到硬盘，这是一种好办法，因为序列化数据是结构化数据最好的存储表现，但是这又带来了另一个麻烦，这种方式在单点存储上效果很好，如果在多点复制时呢，这又会带来了结构和格式不统一的困扰。

数据库的优势就是便于集中式管理，而序列化文件的优势是方便灵活，对内存结构的直接映射扩展，如果把二者结合起来，利用数据库做统一的存储管理，但是涉及到很多个性化配置信息时，我们将其进行结构化处理，不是保存到硬盘上，而是直接存储到表字段中，那问题就迎刃而解了。其实这又有点像NOSQL的处理了，通过键值对进行索引，但是区别于NOSQL，我们是利用的常规的关系数据库做存储，为了便于索引，在进行结构化数据的序列化存储之前，可将特定的索引字段的内容，统一按照格式类型追加到全局索引表中，所谓全局索引表，就是用来承载所有的序列化存储的结构化数据对应的索引信息，最终呈现给使用者时，与传统的关系存储没有了任何的区别。

存储机制自身原理不是太复杂，但需要在一些地方进行大量的转化，从对象到字节流，到存储，或从存储到字节流，到对象，这个会相当繁琐，频繁的转化会造成业务层面的零乱，因此一套好的独立的转化框架，是实现该机制的保证。软件的开发设计就是这样，当分解了一个复杂面时，总归需要在其他地方实现另一个复杂面，只是转化的方向能否更适合业务系统的需求。