亿级订单表数据存储

场景
  电商平台需要进行持久化所有平台产生的订单数据。同时，基于所有的订单数据，系统又需要向外提供面向多种角色：消费者、店家、平台三类人群的多元化的查询服务。消费者可以查询自己的历史订单，商家可以统计热销产品，平台也可以分析用户行为、平台交易规模等。主要查询方式涵盖订单的多维度检索，以及订单数据的分析、统计等，例如：
 面向消费者：【A消费者】* 【近1年】* 【产品名含’电脑’字段】订单查询；
 面向店家：【B店家】* 【近1个月】*【每个产品】销售量排名；
…
技术点
  在订单场景中，技术上通常需要考虑的技术点，主要包含如下几个方面：
【查询能力】：需要具备丰富的查询类型，如多维度、范围、模糊查询等，同时具备排序、统计等功能
【数据量】：存储海量数据的同时，满足强一致、高可用、低成本等要求
【服务性能】：应对高并发请求高并发的同时，保证低延迟

【方案】
  应对订单场景，通常会采用MySQL传统方案。借助关系型数据库强大的查询能力，用户可直接通过SQL语句实现订单数据的多维度查询、数据统计等。MySQL、SQL Server等，都是以“行”为单位进行存储，为了快速检索，也都采用了B树或其他索引技术。从原理上来讲，表中的数据越多，索引树的范围越大，磁盘读取也越多，性能也就越低。所谓数据膨胀，分为横向、纵向两种，横向即不断迭代引入的新字段维度，纵向即总的存储数据量。在面对这两种订单数据膨胀上，单MySQL方案逐渐变得吃力。 SQL + NoSQL的组合方案便应运而生，借助两个数据库各自的优势分别解决不同场景各自的需求。但组合方案牺牲空间成本，同时也增加了开发工作量与运维复杂度。在保证数据一致性上产生额外开销。
  目前经常使用的关系型数据库如MySQL、SQL Server等，都是以“行”为单位进行存储，为了快速检索，也都采用了B树或其他索引技术。从原理上来讲，表中的数据越多，索引树的范围越大，磁盘读取也越多，性能也就越低。
读和写分