Chinaunix首页 | 论坛 | 博客
  • 博客访问: 315403
  • 博文数量: 163
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: -40
  • 用 户 组: 普通用户
  • 注册时间: 2017-03-08 00:28
文章分类

全部博文(163)

文章存档

2015年(2)

2014年(35)

2013年(28)

2012年(30)

2011年(22)

2010年(14)

2009年(8)

2008年(13)

2007年(11)

分类: Mysql/postgreSQL

2014-06-04 13:44:04


一直在从事postgres内核修改的工作,对postgres的代码还算比较熟悉,在工作讨论中,有意无意的大家都会提起,MySQL在这方面是怎么做的,最近读了以下网站:

关于MySQL源码解读 的文章,感觉作者对MySQL也是相当熟悉,文章写的也很好,MySQL和PostgresQL在很多功能设计上有许多相似之处,又有些许不同,简单的总结以下,以下的谈论都是针对MySQL的InnoDB引擎的。

1.       数据文件存储
1.1       Postgres 是一张表对应一个文件(或多个文件),一个索引也是对应一个文件(或多个文件),Postgres在创建表时,会默认创建一个物理文件,文件大小默认为1G,随着表中数据的增长,会接着产生第二个,第三个默认大小为1G的数据文件,索引也是类似。
1.2       MySQL InnoDB其实是所有的数据库中所有表都存在一个文件中(ibdata1 by default),后来版本增加了参数 innodb_file_per_table,默认为disable,也可以每张表一个物理文件如mytable.ibd,这里和Postgres的区别是:MySQL会把表和表上的所有索引都存入该文件,而Postgres不会,表对应一个(多个)物理文件,表上的每个索引对应一个(多个)物理文件。
1.3       那么MySQL为什么要增加这个特性呢,以前为什么又把所有的表存入一个文件呢?

从上述讨论中,未找到明确答案。

2.       日志
/2012/04/06/innodb-log1.html
/2012/04/06/innodb-log2.html
/2012/04/06/innodb-log3.html
以上三篇文章把MySQL的日志记录方法说的非常清楚,循序渐进。

2.1       MySQL既存在Redo日志又存在Undo日志,日志记录的格式既有物理日志又有逻辑日志。而Postgres只存在Redo日志,并且日志记录的格式只有物理日志。
2.2       对于日志的恢复策略是:不管事务是否提交,全部重做而非只做提交的事务。这一点Postgres和InnoDB相同。
2.3       为了解决Page部分写到磁盘的问题(如page的头面刷盘,而尾部为刷盘的情况下掉电),MySQL提供了Double Write的机制:
Double Write的思路很简单:
 A. 在覆盖磁盘上的数据前,先将Page的内容写入到磁盘上的其他地方(InnoDB存储引擎中的doublewrite
    buffer,这里的buffer不是内存空间,是持久存储上的空间).
 B. 然后再将Page的内容覆盖到磁盘上原来的数据。

        Postgres也有类似的机制,通过full_page_write来控制,不同之处在于Postgres先将页面的内容写入Redo日志,而MySQL是写入double write buffer.
2.4       MySQL的数据页有checksum,而Postgres的数据页并没有checksum,只有索引页有。对于日志在内存中缓存结构,两者都采用了环形缓冲的形式。

3.       Checkpoint
/2012/04/23/mysql-innodb-checkpoint.html
在这一点上Postgres和MySQL差别很大。
3.1       Postgres的Checkpoint会刷盘所有的脏页面,而MySQL的checkpoint并不会刷盘所有的脏页面,只是部分脏页面,很多情况下checkpoint时,并不写脏页到存储。只是将所有脏页的  最小的LSN记做checkpoint.在部分情况下,checkpoint会刷盘部分脏页面并向前推进checkpoint点。从这一点上来说,MySQL的checkpoint和PureScale的castout非常类似:刷盘部分页面,并向前推进checkpoint点。另外MySQL对于每次checkpoint刷新多少页面,也有一套计算方法。

4.       Buffer pool
/2012/05/25/mysql_innodb_buffer_pool_size.html
/2012/05/29/mysql-innodb-buffer-pool.html
/2012/05/30/mysql-innodb-buffer-pool-allocate.html
4.1       MySQL最新版本中,支持多个buffer pool Instance;而Postgres只有一个Buffer pool,IBM的Z/OS也有多个buffer pool,每个buffer pool中存放的页面类型不同。而MySQL的多个buffer pool是如何管理的,和单个相比有什么优势,目前没看清晰。
4.2       MySQL有预读功能,Postgres没有;
4.3       MySQL数据库InnoDB存储引擎的 Buffer Pool通过LRU算法管理页面的替换策略。LRU List按照功能被划分为两部分:LRU_young与LRU_old,默认情况下,LRU_old为链表长度的3/8。页面读取时(get/read ahead),首先链入LRU_old的头部。页面第一次访问时(read/write),从LRU_old链表移动到LRU_young的头部(整个LRU链表头)。而Postres采用的是Clock Sweep算法。MySQL虽然采用的LRU,但也不是每次新访问的页面都会移到list的头部,如果list很长,一个页面在list的第10位和头部的作用可以看做是相同的,即都不可能被淘汰。
4.4       全表扫描对buffer命中率的影响
全表扫描,在表比较大时,如果不采用特别的策略,大表的页面会使得buffer pool中的所有页面被换出,降低buffer pool的命中率。对于这个问题MySQL和Postgres都有处理:
MySQL全表扫描的所有页面,也遵循先读入LRU_old,后移动到LRU_young的原则,会导致Buffer Pool中的其他页面被替换出内存。为防止全表扫描的负面影响,InnoDB存储引擎提供了系统参数,innodb_old_blocks_time:只有当页面的后续访问与第一次访问时间间隔大于此值,才会移动到LRU链表头。innodb_old_blocks_time在5.1.41版本中引入。默认为0,也就是说全表扫描的页面会进入LRU_young(链表头),一个大表的全表扫描会导致大量page被替换出内存。
Postgres使用了buffer ring。
二者的思想都是,分配一部分buffer给类似全表扫描的场景使用,不让其污染整个buffer pool。
4.5       在正常情况下,buffer中的脏页MySQL是通过checkpoint刷出的,而Postgres是通过称之为bgwriter的进程刷出的,工作进程大部分情况下并不会直接刷盘,但是在bgwriter忙不过来的时候,工作进程也会自己刷盘,对于MySQL也是类似,在checkpoint忙不过时,工作线程也会自己刷盘。
4.6       MySQL具有AIO(异步)的功能,而Postgres没有。MySQL的异步IO有两种实现方式,一是使用linux自带的AIO功能,二是自己通过线程模拟的。
/2012/05/22/mysql-innodb-aio.html
在Linux系统上,MySQL数据库InnoDB存储引擎除了可以使用Linux自带的libaio之外,其内部还实现了一种称之为Simulated aio功能,用以模拟系统AIO实现(其实,Simulated aio要早于linux native aio使用在innodb中,可参考网文[16])。前面的章节,已经分析了InnoDB存储引擎对于Linux原生AIO的使用,此处,再简单分析一下 Innodb simulated aio的实现方式。
以下一段话摘自Transactions on InnoDB网站[16],简单说明了simulated aio在innodb中的处理方式。
… The query thread simply queues the request in an array and then returns to the normal working. One of the IO helper thread, which is a background thread, then takes the request from the queue and issues a synchronous IO call (pread/pwrite) meaning it blocks on the IO call. Once it returns from the pread/pwrite call, this helper thread then calls the IO completion routine on the block in question …
Linux simulated aio,实现简单,基本采用的仍旧是同步IO的方式。相对于Linux native aio,simulated aio最大的问题在于:每个I/O请求,最终都会调用一次pread/pwrite进行处理(除非可以进行相邻page的合并),而Linux native aio,对于一个array,进行一次异步I/O处理即可。

5.       Insert buffer
/2012/05/21/mysql-innodb-insert-buffer.html
http://blogs.innodb.com/wp/2010/09/mysql-5-5-innodb-change-buffering/
MySQL的Insert buffer的思想就是,把一些对页面的修改先缓存在内存中,然后集中将修改与硬盘的原始数据Merge在一起。个人感觉这一点 和淘宝的OceanBase的思想比较相似,OceanBase把数据分为增量数据和基准数据,也就说应用对基准数据的修改,数据库层面并不会马上就修改基准数据,而是将修改数据汇总在一起成为增量数据,然后隔一段时间增量数据和基准数据进行merge,形成新的基准数据。这样可以把增量数据和基本数据分开对待,比如将增量数据放在SSD上。

6.       Lock
/2012/05/19/locks_in_innodb.html
6.1       这一块看到的资料比较少,感觉MySQL的锁机制貌似比Postgres复杂一点,但是它们都支持行级锁,但是现在不是特别清楚MySQL的行锁是如何存储的,是直接存在内存中,还是其它方案,下面这篇文章对比了DB2和Oracle的锁机制。
http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0512niuxzh/?S_TACT=105AGX52&S_CMP=12-w-cto
6.2       DB2的行级锁直接记录在内存中,因此如果事务比较大,修改行比较多,锁占用的内存比较大,此时就需要锁升级;而Oracle是通过在元组头上作标记来标识行级锁,因此行级锁并不占内存,Postgres行级锁的方案和Oracle类似。关于表级锁的模式,从上述文章感觉DB2和Postgres差不多,表上都有8种模式。

6.3       值得注意的是,DB2的行级锁模式比较多,有7中之多,并且当插入一行数据时,该行上并不是直接加X(排他锁),而是加W(弱排他锁)。

6.4       Oracle存在一种单独的TX锁,许多对Oracle不太了解的技术人员可能会以为每一个TX锁代表一条被封锁的数据行,其实不然。TX的本义是Transaction(事务),当一个事务第一次执行数据更改(Insert、Update、Delete)或使用SELECT… FOR UPDATE语句进行查询时,它即获得一个TX(事务)锁,直至该事务结束(执行COMMIT或ROLLBACK操作)时,该锁才被释放。

在这一点上,Postgres和Oracle类似,也存储单独的事务锁,锁的标识为事务ID.

7.       Deadlock
Postgres并没有一个单独的死锁检测进程,而是由各工作进程在申请锁超时时,自己检测。
/2011/12/05/innodb-dead-lock.html
根据以上描述,MySQL也没有一个单独的死锁检测线程,而是依靠各工作线程,MySQL和Postgres都采用构造WFG的形式进行死锁检测,MySQL会计算事务重量,在回滚环中的事务时,会选择轻量的事务进行回滚,而Postgres检测到环之后,直接回滚检测者自己。




原文地址: http://blog.sina.com.cn/s/blog_742eb90201010yul.html
阅读(1333) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~