mysql大数据量处理

一、概述
分表是个目前算是比较炒的比较流行的概念，特别是在大负载的情况下，分表是一个良好分散数据库压力的好方法。
首先要了解为什么要分表，分表的好处是什么。我们先来大概了解以下一个数据库执行SQL的过程：
接收到SQL --> 放入SQL执行队列 --> 使用分析器分解SQL --> 按照分析结果进行数据的提取或者修改 --> 返回处理结果
当然，这个流程图不一定正确，这只是我自己主观意识上这么我认为。那么这个处理过程当中，最容易出现问题的是什么？就是说，如果前一个SQL没有执行完毕的话，后面的SQL是不会执行的，因为为了保证数据的完整性，必须对数据表文件进行锁定，包括共享锁和独享锁两种锁定。共享锁是在锁定的期间，其它线程也可以访问这个数据文件，但是不允许修改操作，相应的，独享锁就是整个文件就是归一个线程所有，其它线程无法访问这个数据文件。一般MySQL中最快的存储引擎MyISAM，它是基于表锁定的，就是说如果一锁定的话，那么整个数据文件外部都无法访问，必须等前一个操作完成后，才能接收下一个操作，那么在这个前一个操作没有执行完成，后一个操作等待在队列里无法执行的情况叫做阻塞，一般我们通俗意义上叫做“锁表”。
锁表直接导致的后果是什么？就是大量的SQL无法立即执行，必须等队列前面的SQL全部执行完毕才能继续执行。这个无法执行的SQL就会导致没有结果，或者延迟严重，影响用户体验。
特别是对于一些使用比较频繁的表，比如SNS系统中的用户信息表、论坛系统中的帖子表等等，都是访问量大很大的表，为了保证数据的快速提取返回给用户，必须使用一些处理方式来解决这个问题，这个就是我今天要聊到的分表技术。
分表技术顾名思义，就是把若干个存储相同类型数据的表分成几个表分表存储，在提取数据的时候，不同的用户访问不同的表，互不冲突，减少锁表的几率。比如，目前保存用户分表有两个表，一个是user_1表，还有一个是 user_2 表，两个表保存了不同的用户信息，user_1 保存了前10万的用户信息，user_2保存了后10万名用户的信息，现在如果同时查询用户 heiyeluren1 和 heiyeluren2 这个两个用户，那么就是分表从不同的表提取出来，减少锁表的可能。
我下面要讲述的两种分表方法我自己都没有实验过，不保证准确能用，只是提供一个设计思路。下面关于分表的例子我假设是在一个贴吧系统的基础上来进行处理和构建的。（如果没有用过贴吧的用户赶紧Google一下）
二、基于基础表的分表处理
这个基于基础表的分表处理方式大致的思想就是：一个主要表，保存了所有的基本信息，如果某个项目需要找到它所存储的表，那么必须从这个基础表中查找出对应的表名等项目，好直接访问这个表。如果觉得这个基础表速度不够快，可以完全把整个基础表保存在缓存或者内存中，方便有效的查询。
我们基于贴吧的情况，构建假设如下的3张表：
1. 贴吧版块表: 保存贴吧中版块的信息
2. 贴吧主题表：保存贴吧中版块中的主题信息，用于浏览
3. 贴吧回复表：保存主题的原始内容和回复内容
“贴吧版块表”包含如下字段：
版块ID       board_id          int(10)
版块名称    board_name      char(50)
子表ID       table_id            smallint(5)
产生时间    created             datetime
“贴吧主题表”包含如下字段：
主题ID          topic_id        int(10)
主题名称        topic_name     char(255)
版块ID          board_id          int(10)
创建时间       created           datetime
“贴吧回复表”的字段如下：
回复ID        reply_id           int(10)
回复内容      reply_text        text
主题ID        topic_id           int(10)
版块ID        board_id         int(10)
创建时间      created            datetime
那么上面保存了我们整个贴吧中的表结构信息，三个表对应的关系是：
版块 --> 多个主题
主题 --> 多个回复
那么就是说，表文件大小的关系是：
版块表文件 < 主题表文件 < 回复表文件
所以基本可以确定需要对主题表和回复表进行分表，已增加我们数据检索查询更改时候的速度和性能。
看了上面的表结构，会明显发现，在“版块表”中保存了一个"table_id"字段，这个字段就是用于保存一个版块对应的主题和回复都是分表保存在什么表里的。
比如我们有一个叫做“PHP”的贴吧，board_id是1，子表ID也是1，那么这条记录就是：
board_id | board_name | table_id | created
1 | PHP | 1 | 2007-01-19 00:30:12
相应的，如果我需要提取“PHP”吧里的所有主题，那么就必须按照表里保存的table_id来组合一个存储了主题的表名称，比如我们主题表的前缀是“topic_”，那么组合出来“PHP”吧对应的主题表应该是：“topic_1”，那么我们执行：
SELECT * FROM topic_1 WHERE board_id = 1 ORDER BY topic_id DESC LIMIT 10
这样就能够获取这个主题下面回复列表，方便我们进行查看，如果需要查看某个主题下面的回复，我们可以继续使用版块表中保存的“table_id”来进行查询。比如我们回复表的前缀是“reply_”，那么就可以组合出“PHP”吧的ID为1的主题的回复：
SELECT * FROM reply_1 WHERE topic_id = 1 ORDER BY reply_id DESC LIMIT 10
这里，我们能够清晰的看到，其实我们这里使用了基础表，基础表就是我们的版块表。那么相应的，肯定会说：基础表的数据量大了以后如何保证它的速度和效率？
当然，我们就必须使得这个基础表保持最好的速度和性能，比如，可以采用MySQL的内存表来存储，或者保存在内存当中，比如Memcache之类的内存缓存等等，可以按照实际情况来进行调整。
一般基于基础表的分表机制在SNS、交友、论坛等Web2.0网站中是个比较不错的解决方案，在这些网站中，完全可以单独使用一个表来来保存基本标识和目标表之间的关系。使用表保存对应关系的好处是以后扩展非常方便，只需要增加一个表记录。
【优势】增加删除节点非常方便，为后期升级维护带来很大便利
【劣势】需要增加表或者对某一个表进行操作，还是无法离开数据库，会产生瓶颈
三、基于Hash算法的分表处理
我们知道Hash表就是通过某个特殊的Hash算法计算出的一个值，这个值必须是惟一的，并且能够使用这个计算出来的值查找到需要的值，这个叫做哈希表。
我们在分表里的hash算法跟这个思想类似：通过一个原始目标的ID或者名称通过一定的hash算法计算出数据存储表的表名，然后访问相应的表。
继续拿上面的贴吧来说，每个贴吧有版块名称和版块ID，那么这两项值是固定的，并且是惟一的，那么我们就可以考虑通过对这两项值中的一项进行一些运算得出一个目标表的名称。
现在假如我们针对我们这个贴吧系统，假设系统最大允许1亿条数据，考虑每个表保存100万条记录，那么整个系统就不超过100个表就能够容纳。按照这个标准，我们假设在贴吧的版块ID上进行hash，获得一个key值，这个值就是我们的表名，然后访问相应的表。
我们构造一个简单的hash算法：
function get_hash($id){
     $str = bin2hex($id);
     $hash = substr($str, 0, 4);
     if (strlen($hash)<4){
         $hash = str_pad($hash, 4, "0");
     }
     return $hash;
}
算法大致就是传入一个版块ID值，然后函数返回一个4位的字符串，如果字符串长度不够，使用0进行补全。
比如：get_hash(1)，输出的结果是“3100”，输入：get_hash(23819)，得到的结果是：3233，那么我们经过简单的跟表前缀组合，就能够访问这个表了。那么我们需要访问ID为1的内容时候哦，组合的表将是：topic_3100、reply_3100，那么就可以直接对目标表进行访问了。
当然，使用hash算法后，有部分数据是可能在同一个表的，这一点跟hash表不同，hash表是尽量解决冲突，我们这里不需要，当然同样需要预测和分析表数据可能保存的表名。
如果需要存储的数据更多，同样的，可以对版块的名字进行hash操作，比如也是上面的二进制转换成十六进制，因为汉字比数字和字母要多很多，那么重复几率更小，但是可能组合成的表就更多了，相应就必须考虑一些其它的问题。
归根结底，使用hash方式的话必须选择一个好的hash算法，才能生成更多的表，然数据查询的更迅速。
【优点hash算法直接得出目标表名称，效率很高】通过
【劣势】扩展性比较差，选择了一个hash算法，定义了多少数据量，以后只能在这个数据量上跑，不能超过过这个数据量，可扩展性稍差
四、其它问题
1. 搜索问题
现在我们已经进行分表了，那么就无法直接对表进行搜索，因为你无法对可能系统中已经存在的几十或者几百个表进行检索，所以搜索必须借助第三方的组件来进行，比如Lucene作为站内搜索引擎是个不错的选择。
2. 表文件问题
我们知道MySQL的MyISAM引擎每个表都会生成三个文件，*.frm、*.MYD、*.MYI 三个文件，分表用来保存表结构、表数据和表索引。Linux下面每个目录下的文件数量最好不要超过1000个，不然检索数据将更慢，那么每个表都会生成三个文件，相应的如果分表超过300个表，那么将检索非常慢，所以这时候就必须再进行分，比如在进行数据库的分离。
使用基础表，我们可以新增加一个字段，用来保存这个表保存在什么数据。使用Hash的方式，我们必须截取hash值中第几位来作为数据库的名字。这样，完好的解决这个问题。
五、总结
在大负载应用当中，数据库一直是个很重要的瓶颈，必须要突破，本文讲解了两种分表的方式，希望对很多人能够有启发的作用。当然，本文代码和设想没有经过任何代码测试，所以无法保证设计的完全准确实用，具体还是需要读者在使用过程当中认真分析实施。
文章写的比较匆忙，质量可能无法保证，遇到错误，不要见怪，欢迎提出批评指教，谢谢~~~~！
---------------------
作者：纳木错
来源：CSDN
原文：https://blog.csdn.net/neubuffer/article/details/16900983
版权声明：本文为博主原创文章，转载请附上博文链接！

mysql大数据量处理相关推荐

MySQL大数据量分页查询方法及其优化
点击上方好好学java ,选择星标公众号重磅资讯.干货,第一时间送达今日推荐:收藏了!7 个开源的 Spring Boot 前后端分离优质项目个人原创+1博客:点击前往,查看更多链接:ht ...
mysql大数据量分页的一些做法
随着公司业务的增长,数据库的数据也呈指数级增长,拿订单表为例,之前公司的订单表每天只有几千个,一个月下来不超过十万.而现在每天的订单大概就是2w+,目前订单表的数据已经达到了700w.这带来了各种各样 ...
easyui分页查询为什么会有下拉框_6个针对MySQL大数据量分页查询优化的锦囊妙计...
作者:大神养成记转载来源:http://sina.lt/gauW 方法1: 直接使用数据库提供的SQL语句语句样式: MySQL中,可用如下方法: SELECT * FROM 表名称 LIMIT M ...
mysql大数据量导入
mysql大数据量导入 mysql大数据量导入数据生成测试数据5000万 import java.io.*; import java.util.Random;public class Genera ...
千锋重庆Java学习之MySQL大数据量分页查询方法及其优化
方法1: 直接使用数据库提供的SQL语句语句样式: MySQL中,可用如下方法: SELECT * FROM 表名称 LIMIT M,N 适应场景: 适用于数据量较少的情况(元组百/千级) 原因/缺 ...
MYSQL大数据量分页查询优化 - 十万、百万级优化
1. 常见问题在mysql大数据量的基础下,分页中随着页码的增加,查询时间也会响应的增加.所以到了百万级别的数据量时,我们就需要优化已有的查询代码进行合理有效的分页. 一般情况下,页码与查询时间成正 ...
Linux下MySQL数据库的备份与还原，mysql快速导入导出数据库实例演示，解决mysql大数据量数据库导出慢的问题
MySQL 数据库的备份与还原第一章:数据库的导入与导出 ① 数据库的导出 ② 大数据量下 mysqldump 的导出优化 ③ 数据库的导出第一章:数据库的导入与导出 ① 数据库的导出需要用到 ...
一次mysql大数据量查询慢查询导致服务阻塞后的学习
场景还原:前一个月给朋友写了个简单的登录功能,简单的查询数据库登录逻辑,使用mysbatis-plus进行的dao层代码生成(吐槽一下这个工具,真是方便一时爽,后面维护难,比较喜欢自己能够组装和优化s ...
mysql 大数据量插入遇到瓶颈可行性方案探究
数据迁移.数据恢复往往都需要做大数据量的插入操作,但是,不同的插入方法对性能的影响也是非常大的插入数据分析一次插入多行的值插入行所需的时间由以下因素决定(参考 MySQL 5.7 参考手册: 8 ...

mysql大数据量处理

mysql大数据量处理相关推荐

最新文章

热门文章