分库分表后跨分片查询与Elastic Search

携程酒店订单Elastic Search实战：http://www.lvesu.com/blog/main/cms-610.html

为何分库分表后不建议跨分片查询：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列对应的表的数据都是全量的

 

 冗余关系表：只有一个sharding column的分库分表的数据是全量的，其余分库分表只是与这个sharding column的关系表。实际使用中可能会冗余更多经常使用字段，如用户名称、商户名称等。

冗余全量表 VS 冗余关系表

• 速度对比：冗余全量表速度更快，冗余关系表须要二次查询，即便有引入缓存，仍是多一次网络开销；
• 存储成本：冗余全量表须要几倍于冗余关系表的存储成本；
• 维护代价：冗余全量表维护代价更大，涉及到数据变动时，多张表都要进行修改。

总结：选择冗余全量表仍是索引关系表，这是一种架构上的trade off（权衡），二者的优缺点明显，阿里的订单表是冗余全量表。

 （3）单个sharding column分库分表示例（帐户表）

通常帐户相关API使用account_no为sharding column

（4）多个sharding column分库分表示例（用户表）

用户能够经过mobile_no，email和username进行登陆，一些用户相关API又常使用user_id，因此sharding column选这4个字段。

 （5）sharding column分库分表 + ES检索（模糊查询）

上面提到的都是条件中有sharding column的SQL执行。可是，总有一些查询条件是不包含sharding column的，同时，咱们也不可能为了这些请求量并不高的查询，无限制的冗余分库分表。那么这些查询条件中没有sharding column的SQL怎么处理？以sharding-jdbc为例，有多少个分库分表，就要并发路由到多少个分库分表中执行，而后对结果进行合并。这种条件查询相对于有sharding column的条件查询性能很明显会降低不少。

更有甚者，尤为是有些运营系统中的模糊条件查询，或者上十个条件筛选。例如淘宝个人全部订单页面，筛选条件有多个，且商品标题能够模糊匹配，这即便是单表都解决不了的问题，更不用谈分库分表了。

sharding column + es的模式，将分库分表全部数据全量冗余到es中，将那些复杂的查询交给es处理。（ElasticSearch，搜索引擎）以订单表为例：

 PS：多sharding column不到万不得已的状况下最好不要使用，建议采用单sharding column + es的模式简化架构。

5.全文索引思路（HBase）

• Solr+HBase
• ES+HBase

可能参与条件检索的字段索引到ES中，全部字段的全量数据保存到HBase中，这就是经典的ES+HBase组合方案，即索引与数据存储隔离的方案。Hadoop体系下的HBase存储能力咱们都知道是海量的，并且根据它的rowkey查询性能那叫一个快如闪电。而es的多条件检索能力很是强大。这个方案把es和HBase的优势发挥的淋漓尽致，同时又规避了它们的缺点，能够说是一个扬长避免的最佳实践。

它们之间的交互大概是这样的：先根据用户输入的条件去es查询获取符合过滤条件的rowkey值，而后用rowkey值去HBase查询，后面这一查询步骤的时间几乎能够忽略，由于这是HBase最擅长的场景，交互图以下所示： 

 

6.总结

最后，对几种方案总结以下（sharding column简称为sc）：

对于海量数据，且有必定的并发量的分库分表，毫不是引入某一个分库分表中间件就能解决问题，而是一项系统的工程。须要分析整个表相关的业务，让合适的中间件作它最擅长的事情。例若有sharding column的查询走分库分表，一些模糊查询，或者多个不固定条件筛选则走es，海量存储则交给HBase。

作了这么多事情后，后面还会有不少的工做要作，好比数据同步的一致性问题，还有运行一段时间后，某些表的数据量慢慢达到单表瓶颈，这时候还须要作冷数据迁移。

 

MySQL单表能够存储10亿级数据，只是这时候性能比较差，业界公认MySQL单表容量在1KW如下是最佳状态，由于这时它的BTREE索引树高在3~5之间。

 

参考文档：

分库分表技术演进&最佳实践-修订篇

HBase应用实践专场-HBase for Solr

分库分表思路

基于Solr的HBase多条件查询测试

 

转自：https://www.cnblogs.com/badboy200800/p/9790395.html