携程酒店订单Elastic Search实战：
为什么分库分表后不建议跨分片查询：https://www.jianshu.com/p/1a0c6eda6f63
分库分表技术演进（阿里怎么分）：https://mp.weixin.qq.com/s/3ZxGq9ZpgdjQFeD2BIJ1MA
1.需求背景
移动互联网时代，海量的用户每天产生海量的数量，这些海量数据远不是一张表能Hold住的。比如
用户表：支付宝8亿，微信10亿。CITIC对公140万，对私8700万。
订单表：美团每天几千万，淘宝历史订单百亿、千亿。
交易流水表
2.选择方案
（1）NoSQL/NewSQL（不选择）
选择RDBMS，不选择NoSQL/NewSQL，主要是因为NoSQL/NewSQL可靠性无法与RDBMS相提并论。RDBMS有以下几个优点：
RDBMS生态完善；
RDBMS绝对稳定；
RDBMS的事务特性；
目前绝大部分公司的核心数据都是：以RDBMS存储为主，NoSQL/NewSQL存储为辅！互联网公司又以MySQL为主，国企&银行等不差钱的企业以Oracle/DB2为主！NoSQL比较具有代表性的是MongoDB，es。NewSQL比较具有代表性的是TiDB。
（2）分区（不选择）
分区原理：分区表是由多个相关的底层表实现，存储引擎管理分区的各个底层表和管理普通表一样，只是分区表在各个底层表上各自加上一个相同的索引（分区表要求所有的底层表都必须使用相同的存储引擎）。
分区优点：它对用户屏蔽了sharding的细节，即使查询条件没有sharding column，它也能正常工作（只是这时候性能一般）。
分区缺点：连接数、网络吞吐量等资源都受到单机的限制；并发能力远远达不到互联网高并发的要求。（主要因为虽然每个分区可以独立存储，但是分区表的总入口还是一个MySQL示例）。
适用场景：并发能力要求不高；数据不是海量（分区数有限，存储能力就有限）。
（3）分库分表（选择）
互联网行业处理海量数据的通用方法：分库分表。 分库分表中间件全部可以归结为两大类型：
CLIENT模式；
PROXY模式；
CLIENT模式代表有阿里的TDDL，开源社区的sharding-jdbc（sharding-jdbc的3.x版本即sharding-sphere已经支持了proxy模式）。架构如下：
PROXY模式代表有阿里的cobar，民间组织的MyCAT。架构如下：
无论是CLIENT模式，还是PROXY模式。几个核心的步骤是一样的：SQL解析，重写，路由，执行，结果归并。
3.分库分表思路（MYSQL）
单个sharding column分库分表 ；
多个sharding column分库分表；
sharding column分库分表 + ES检索；
阿里：选用orderid分表，那我用userid来查询的很多，那不是所有的分表都要查？怎么处理
以阿里订单系统为例（参考《企业IT架构转型之道：阿里巴巴中台战略思想与架构实现》），它选择了三个column作为三个独立的sharding column，即：order_id，user_id，merchant_code。user_id和merchant_code就是买家ID和卖家ID，因为阿里的订单系统中买家和卖家的查询流量都比较大，并且查询对实时性要求都很高。而根据order_id进行分库分表，应该是根据order_id的查询也比较多。
4.分库分表落地（MYSQL）
（1）选择合适的sharding column
分库分表第一步也是最重要的一步，即sharding column的选取，sharding column选择的好坏将直接决定整个分库分表方案最终是否成功。sharding column的选取跟业务强相关。
选择方法：分析你的API流量，将流量比较大的API对应的SQL提取出来，将这些SQL共同的条件作为sharding column。
选择示例：例如一般的OLTP系统都是对用户提供服务，这些API对应的SQL都有条件用户ID，那么，用户ID就是非常好的sharding column。
（2）冗余全量表和冗余关系表选择（订单表）
例如将一张订单表t_order拆分成三张表t_order、t_user_order、t_merchant_order。分别使用三个独立的sharding column，即order_id（订单号），user_id（用户ID），merchant_code（商家ID）。
冗余全量表：每个sharding列对应的表的数据都是全量的