分类归档: Database

Oracle Exadata 的混合列压缩功能

Oracle 发布了关于 Exadata 的混合列压缩(Hybrid Columnar Compression)功能的白皮书(refer)。到现在这方面中文资料还比较少,所以分享一下我读这篇白皮书的笔记。Oracle 在这个文档中也提出了 数据仓库压缩(Warehouse Compression)与归档压缩(Archive Compression)两个概念上的”新”功能。

Oracle Block via http://www.dbasupport.com/img/gupta1.gif我们知道 Oracle 数据库引擎默认是以数据块(block)为存储单位,以数据行(row)作为存储与组织方式,当然理想情况是在一个数据块内存储更多的数据行,而实际上这样的方式对于一些列数较多的表不可避免的会带来存储空间的浪费。相反,以列(columnar)的方式组织、存储数据在空间上会带来很好的收益,但是对于依赖于行的查询,也是我们最常用的查询方式,则性能会差很多,而对于数据分析方面常见的汇总之类的查询,因为只需要扫描较少的数据块,就会达到很好的性能。可实际环境中,人们往往要熊掌与鱼兼得,为了达到空间和性能上的折衷,Oracle 引入了新的方式:用行与列混合的方式来存储数据。

Logical Compression Unit.jpg

如上面的示意图,从高一层抽象上看,引入了一个新的叫做压缩单元(compression unit,cu)的结构用于存储混合列压缩的行的集合。新的数据载入后,列值追加到旧有的行集合的后面,然后进行排序与分组等操作后进行压缩。这一系列动作完成后,组成一个压缩单元。直接一点说,也就是对列存储做分段处理,而压缩单元用来维系不同分段之间的关系。有个特别之处是,要使用批量装载(Bulk Loading)的方式,对于已经存储的数据依然可以应用 DML 操作。而 Exadata 引擎对待已经存入的数据的策略是按需进行解压缩。

这是与传统的 Oracle 数据库引擎所说的压缩截然不同的方式。至于数据仓库压缩与归档压缩的功能,看起来只是针对不同的场景而设置了不同的压缩密度而已。而 Oracle 之所以强调 Exadata 的压缩能力,我想更多是因为 Exadata 目前对于存储能力和价格上的限制吧。

EOF

此文作者:, 位于 Database 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

Second Life 升级 MySQL 的案例参考

尽管前一段时间有媒体报道 Second Life 已经悄无声息的衰败,不过林登实验室的人也还是很忙,这不,刚把一堆 MySQL 服务器进行了升级,还进行了详尽的经验总结(Refer)。

原有的 MySQL 都是跑在 4.1 版本上(4.1.11),在 2007 年的时候计划升级到 5.0 版本,不过遭遇到了…嗯,失败。当时的 5.0 版本不够快。被迫回滚。之后中心 DB 一直运行 4.1 的版本,而 Slave 和其它 DB 都逐渐升级到了 5.0.51 的版本。

用 Python 和 RabbitMQ 写了一个支持 MySQL 协议的分布式压力测试框架,该工具用于捕捉产品环境中的流量并在测试环境下回放模拟,以便更加接近系统的真实运行情况。此外,使用了 Maatkit 工具包用于验证 SQL 语法以及数据。

4.1.11 与 5.0.51 的对比测试表明,5.0.51 比 4.1.11 要慢不少,经过与 Percona 的沟通后,决定升级到 5.0.84 。从我几天前这份 MySQL 版本的调查看, 5.0.84 也是目前用户采用比较多的版本。初步测试 5.0.84 的性能和 4.1.11 的性能相差无几,随后测试打了 Percona 与 Google 的补丁的版本,未作调整下收益不大。一些关键的参数需要作调整以便得到更好的 I/O 能力(要注意如果是 SSD 环境下 innodb_read_ahead 参数要做一点调整,16K 还是 32K ? 要测试才知道)。此外,将 Binlog 放到单独的块设备上,得到 10% 的提升。值得注意的是,默认的系统 I/O 调度器不是很适合,切换到 Deadline 后得到了 15% 的提升(参考 I/O 调度器与 DB的关系)。

经过一番折腾,峰值并发达到了14-16k QPS,只用了 80% I/O 能力,而 4.1.11 最高是 8200 QPS,5.0.51 最高 11,500 QPS,看到这里,猜测他们费这么大劲升级也就是要得到更好的并发能力?

然后是对代码的验证上,包括 SQL 在不同 DB 版本上的正确性以及 SQL 运行的效率,后者也就是执行计划稳定性。这两个测试主要是用 Maatkit 来做的。对于后者,我个人觉得他们的验证过程还有点黑盒子,或许应该关注到具体的 TOP SQL 才会更稳妥一些。此外,复制数据的一致性检查也有必要加以重视。

这台中心服务器数据量大约 250GB。当前所用的服务器是 8 核 Xeon E5450 CPU,64GB 内存,400GB 的直连磁盘(RAID 10),接下来有计划表明要迁移到 16 核的机器上,并且将启用 SSD 。

总体来看,对 MySQL 升级的过程其实也不是那么简单的,也要有个方法论与好的方案才会保证最后升级的成功。

EOF
延伸参考:Percona 针对 MySQL 5.0.84 的 Patch 说明

MySQL 数据库版本调查与分析

针对 MySQL 数据库的版本也做个调查。分析一下大家使用 MySQL 的趋势与习惯。选择大家都选择的,总不会有更大的错误。而如果使用了一个不太合适的版本,或许会后患无穷。

点击访问在线调查 (如果你不能访问这个 URL,需要动动脑子想想为什么)。

现阶段收集到的统计数据:

MySQL_version_chart.png

国内用户用 5.0 的是最多的。如果小版本加起来还是 5.1 的居多。4.1 的版本渐渐推出历史舞台。如果你也在考虑选择 MySQL 的版本,这个数据是否对你有参考性呢?

EOF

Oracle 数据库版本调查与分析

据我所知,很多第三方公司给客户实施的时候,选择的 Oracle 版本 都是非常随意的。数据库软件的版本选择多少是有点技术含量在里面的,毕竟数据库这东西要升级并非易事。这里小范围调查一下大家都在用 Oracle RDBMS 的哪个版本,然后把分析数据和大家分享一下。或许会对新手 DBA 有一定的参考价值。

点击访问在线调查 (如果你不能访问这个 URL,需要动动脑子想想为什么)。

统计数据:

Oracle_version_chart.png

出乎我的意料,9.2.0.8 这个版本现在用的人并不是特别多了(没有我预期的多),而10.2.0.4 这个版本现在看起来像是不少用户的选择,这其实也侧面说明着很多用户升级到 11g 还需要一段时间。版本的分散意味着 Oracle 升级的难度的确不小。

不少明显质量不够稳定的版本也有用户在用(比如,10gR1),看来第三方实施的弊端的确不小。Oracle 一般发布的Release 1 其实多少都会有一些问题–否则也不会有后续的 PatchSet 发布了,要知道每个 PatchSet 都是包含几百个 Bug Fix 的。一般来说,在线 OLTP 恐怕少有人用 R1 的版本。

现在收集到大约 100 多份样本,相信还是有点参考价值的。

有的 DBA 对于统计所用的 URL 可访问性有疑问,这侧面验证了我另一个想法:Oracle DBA 对 Web 的熟悉整体上不如 MySQL DBA

EOF