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检索;

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 + es的模式,将分库分表所有数据全量冗余到es中,将那些复杂的查询交给es处理。以订单表为例:

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多条件查询测试

【大数据和云计算技术社区】分库分表技术演进&最佳实践笔记的更多相关文章

  1. 分库分表技术演进&最佳实践

    每个优秀的程序员和架构师都应该掌握分库分表,这是我的观点. 移动互联网时代,海量的用户每天产生海量的数量,比如: 用户表 订单表 交易流水表 以支付宝用户为例,8亿:微信用户更是10亿.订单表更夸张, ...

  2. MySQL纯透明的分库分表技术还没有

    MySQL纯透明的分库分表技术还没有  种树人./oneproxy --proxy-address=:3307 --admin-username=admin --admin-password=D033 ...

  3. Mysql系列七:分库分表技术难题之分布式全局唯一id解决方案

    一.前言 在前面的文章Mysql系列四:数据库分库分表基础理论中,已经说过分库分表需要应对的技术难题有如下几个: 1. 分布式全局唯一id 2. 分片规则和策略 3. 跨分片技术问题 4. 跨分片事物 ...

  4. 海量数据分库分表方案(二)技术选型与sharding-jdbc实现

    上一章已经讲述分库分表算法选型,本章主要讲述分库分表技术选型 文中关联上一章,若下文出现提及其时,可以点击 分库分表算法方案与技术选型(一) 主要讲述 框架比较 sharding-jdbc.zdal ...

  5. 在多数据源中对部分数据表使用shardingsphere进行分库分表

    背景 近期在项目中需要使用多数据源,其中有一些表的数据量比较大,需要对其进行分库分表:而其他数据表数据量比较正常,单表就可以. 项目中可能使用其他组的数据源数据,因此需要多数据源支持. 经过调研多数据 ...

  6. 解读分库分表中间件Sharding-JDBC

    [编者按]数据库分库分表从互联网时代开启至今,一直是热门话题.在NoSQL横行的今天,关系型数据库凭借其稳定.查询灵活.兼容等特性,仍被大多数公司作为首选数据库.因此,合理采用分库分表技术应对海量数据 ...

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

    携程酒店订单Elastic Search实战:http://www.lvesu.com/blog/main/cms-610.html 为什么分库分表后不建议跨分片查询:https://www.jian ...

  8. 分库分表中间件Sharding-JDBC

    数据库分库分表从互联网时代开启至今,一直是热门话题.在NoSQL横行的今天,关系型数据库凭借其稳定.查询灵活.兼容等特性,仍被大多数公司作为首选数据库.因此,合理采用分库分表技术应对海量数据和高并发对 ...

  9. 分库分表 or NewSQL数据库?终于看懂应该怎么选!【转】

    最近与同行科技交流,经常被问到分库分表与分布式数据库如何选择,网上也有很多关于中间件+传统关系数据库(分库分表)与NewSQL分布式数据库的文章,但有些观点与判断是我觉得是偏激的,脱离环境去评价方案好 ...

随机推荐

  1. 【easy】225. Implement Stack using Queues

    用队列实现栈.这个实现方法十分的简单,就是在push这一步的时候直接变成逆序. class MyStack { private: queue<int> q; queue<int> ...

  2. rsyslog磁盘辅助(Disk-Assisted)模式踩坑记

    最近公司为方便tracing.排查, 搞全链路日志收集,而我手上的10亿+pv的动态前端服务必然在考虑之列. 之前呢. 都是运维定制的收集方式: 如上图,rsyslog push kafka, 优点嘛 ...

  3. canvas图片与img图片的相互转换

    最近在一个项目中,遇到了一个问题,需要把生成的canvas形式的二维码转换为图片,可以长按识别,保存等.查找了一些资料归纳总结了一些知识. 默认在jq库里进行,引入jquery.qrcode.min. ...

  4. vue路由懒加载

    大项目中,为了提高初始化页面的效率,路由一般使用懒加载模式,一共三种实现方式.(1)第一种写法: component: (resolve) => require(['@/components/O ...

  5. pip install psycopg2出现python setup.py egg_info failed with error code 1 in /tmp/pip-build-YtLeN3/psycopg2错误处理

    折腾了一上午flask部署,到最后访问域名还是出现Application Error错误提示.估计是程序还有问题,想着直接clone书中作者的代码先试试能不能部署成功.结果在执行pip install ...

  6. Flask简述

    Flask是一个基于Python开发并且依赖jinja2模板和Werkzeug WSGI服务的一个微型框架,对于Werkzeug本质是Socket服务端,其用于接收http请求并对请求进行预处理,然后 ...

  7. 如何新建PDF文档,新建PDF文档的方法

    新建PDF文件的话,有两种方式,一种是直接通过使用PDF编辑器http://bianji.xjpdf.com/来新建PDF文件,,还有一种就是将PDF文件转换成Word文件,然后在Word文件中添加, ...

  8. Spring Boot+CXF搭建WebService(转)

    概述 最近项目用到在Spring boot下搭建WebService服务,对Java语言下的WebService了解甚少,而今抽个时间查阅资料整理下Spring Boot结合CXF打架WebServi ...

  9. 对屏幕的理解---分辨率,dpi,ppi,屏幕尺寸,像素 等

    1. 名词理解 屏幕尺寸(screen size) 屏幕尺寸(screen size),是屏幕的对角线长度,一般讲的大小单位都是英寸. DPI (dots per inch) dpi 是(英文Dots ...

  10. web理论知识--网页访问过程(附有Django的web项目访问流程)

    当我们闲暇之余想上网看看新闻,或者看个电影,通常的操作是:打开电脑.打开浏览器.输入网址.浏览页面信息.点击自己感兴趣的连接......那么有没有想过,这些网页从哪里来的?过程中计算机又做了什么事情了 ...