在一个这样大体量的数据集上，需要能够满足用户随时查询的低延时需求，同时需要达到极低的存储成本，在技术上是一个非常大的挑战。

淘宝从2003年成立至今近17年的时间，随着流量不断上涨，交易订单数据库的架构也经历过数次演进。

第一阶段，开始由于流量较小，使用了一套Oracle数据存储了所有的订单信息，新订单创建和历史订单查询都在同一套数据库进行。

第二阶段，由于历史订单量数据量越来越大，单一一套库已经不能满足同时满足性能和容量的问题，于是对交易订单库进行了拆分，单独建立了一个Oracle历史库，将三个月以前的订单迁移进历史库，同时由于数据量巨大，查询性能不能满足需求，因此当时的历史订单不提供查询功能。用户只能查询三个月之内的订单信息。

第三个阶段，为了解决扩展性和存储成本问题，交易历史库整体迁移到了HBase方案，这套方案在当时很好了解决了存储成本和业务查询需求这2个诉求。整体方案是使用主表结合索引表，查询订单详细信息通过主表完成，通过买家或者卖家ID查询订单，则需要借助索引表先得到订单号。

• 存储成本，每日写入量巨大且数据永不删除，必须要保证极低的成本。

• 节省存储成本的前提下，保证丰富的查询特性，例如按时间维度排序等。因此底层数据库需要支持二级索引，且二级索引需要保证一致性和性能。

• 保证较低的查询延时，不影响用户使用体验。虽然90天前的历史订单的查询量比90天内要少很多，但这依然是直接面对用户的，需要保证长尾延时在一定限度内。

• 在线库依然沿用之前的MySQL InnoDB集群，但是只保存90天的数据量，90天之前的订单会被删除，数据量少，可以保证较高的缓存命中率，确保读写延时。

• 通过数据同步将在线库中超过90天的订单迁移到历史库中，迁移之后该部分订单从在线库删除。

• 历史库切换为X-Engine，保存全量的交易订单数据，90之前的订单读写，直接操作历史库, 同时历史库承接在线库的所有迁移写入负载。

这套架构上线之后，交易历史库的存储成本相比较于使用HBase没有上升，同时由于历史库和在线库能力相同，可以创建完全一样的索引，历史订单恢复了对订单按时间排序功能的支持，同时其读取延时也得到了保证。

在淘宝交易历史库的方案中，考虑到业务层面历史代码架构的延续性，采用了InnoDB引擎在线库和X-Engine历史库分离的方案。在这套架构中，X-Engine历史库其实同时承担了在线库迁移过来的写入以及90天以前记录的读写流量。 

实际上，考虑到淘宝交易订单记录流水型的访问特征(最近写入的记录会被大量访问，随着时间推移，记录访问频次急剧衰减），X-Engine引擎内部的冷热分离机制就能很好的处理这种流水型业务，所以单一X-Engine数据库集群完全解决需求。

对于新开业务或者有大量流水型记录存储需求的现有业务且业务层面还未做冷热分离，我们建议直接使用一套X-Engine引擎，在存储成本降低的同时，DB层的访问代码会更简单。基于X-Engine引擎的PolarDB-X分布式数据库可以同时解决scale out问题和成本问题。

目前X-Engine引擎已经上线阿里云， 经过阿里内部业务验证，欢迎有成本和性能需求的用户购买使用。