作者文章: Fenng

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 .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

公司 BLOG 运作经验谈

在过去的 18 个月里,我一直用 20% 的时间在运营支付宝的官方网志 – 支付志 ,不要误会,我说的 20% 是 100% 之外的时间。

因为在兄弟公司中第一家推出官方 Blog,可参考的同行案例并不多,借鉴了一些 Google 运作产品 Blog 的大致思路和策略(尽管没有明确的策略)。所以,更多只能是摸石头过河,一点点的进行尝试。这里总结一点运作的经验,以供后来人参考。

避免陷入争论

对于用户的疑惑或者质疑,做解释说明(To make plain or comprehensible),不要辩解,也不要争辩。其实总有一些话题一些客观因素导致的现状是很难迅速解决的,比如”网银对非 IE 浏览器的支持”,一旦就某些观点讨论起来,很容易陷入论战。身处漩涡是一件危险的事情,更好的办法是说明,中立性的的说明。在这里我也建议如果遇到恶意攻击,最好的办法当然是保持沉默。

传递必要信息

说是”官方”,但不意味着事无巨细报道公司的一切,也没有必要专写一些小道消息,有关公司文化或者公益活动等事宜是有必要进行宣传的。而有关产品更新,有关用户问题的跟进解决是有必要进行说明的。而我个人比较关注的是一些被忽视但是对用户会有价值的地方。

关心有用指标

我知道有很多公司的官方网志是有专人维护的,而且,主管会定下来很多莫名其妙的指标给维护人,比如访问人次、PV 等等。其实这些指标可能会背离做这件事情的初衷。产生价值有多种渠道和方法,通过 RSS 、转载等多种渠道更能够有效的传递信息,未必一定要用户总在本地阅读,而用户阅读的多寡也不意味着信息传递价值的大小。所以,对于支付志来说,重要的是对用户传递产品信息公司理念,前面一两个月我还是关心访问人次,到了后期,我更关心的是内容引用率的跟踪,以及引用本站内容的网站所产生的影响。

制定内容策略

在准备运行的时候,针对内容制定了如下几条原则,现在看起来依然适用:

  • 我们可能会犯错误,但一旦发现会尽快纠正;
  • 所有评论在通过管理人员审核后发布,并且将在适当时候尽可能快地回复评论;
  • 我们将尽可能对引用的文章和内容给出初始连接;
  • 对所有不同的意见我们都将给予尊重。

这里面要说明的是对待留言的态度,我对留言的处理先行定下策略,实际操作中有章可循。

积极对待反馈

官方 Blog 的维护过程中,会看到非常多的用户反馈,而有些典型但是没有引起重视的问题要第一时间转发给内部团队,积少成多,长期下来看,这个收益是非常可观的。也有用户会提供针对某些长期问题的自行解决办法,也是非常值得参考的。有的时候,可能从有些角度看,只是小问题,但是对单个用户来说,都是大问题。不要忘了蝴蝶效应,小问题,可能也会带来大影响。这也是我在开始游说开辟 Blog 的一个出发点。

善用媒体工具

适当利用 Twitter (@Alipay)或是新浪微博( @支付宝 ,已经有超过 5000 人关注了) 等工具,面向不同的关注群体做一下信息广播也会有不错的效果。

结束语

必须要说的是,尽管获得了一点经验,但实际上现状距离目标还相去甚远,还有太多不尽人意的地方,只能尽力为之。

EOF

此文作者:, 位于 Review 分类 标签: , 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 说明

Movable Type 与 WordPress

在几次跳票之后,Six Apart 终于发布了 Movable Type 5。作为少数坚守在 MT 阵地的用户,当然是第一时间升级到新版本进行了一番体验,结果就是这几天正在一点点修改升级后的一些模板上的问题。倒是有活干了。

一点小经验是如果是延续用旧的主题的话,迁移到新的目录后要确保有 “theme.yaml” 这个文件,否则后台点击 Setting 按钮的时候会弹出一个”Can’t call method "label" on unblessed reference” 的错误。多数插件都能继续用,可以打开 MT 的 Debug 模式,然后查看 Plugin 列表,会显示哪些插件兼容性不够好。我觉得用好 MT 的一个秘诀就是…尽量少用插件。

总体来看 MT 新版本的确带来了很大改进,除了增加了版本历史功能外,内容结构的组织有更大的改进,模板的可定制化非常好,是目前能看到的 CMS 平台的登峰造极之作。只是从平台的角度考虑恐怕还竞争不过 WordPress ,我个人觉得语言的实现(Perl vs. PHP)造成了二者在最初发展上的差异,进而导致插件上开发的 Movable Type 远远不如 WordPress 容易,而插件的多寡影响功能的完善与丰富性。用户会接受哪一个不言而明了。另外一个影响因素就是更多的主机提供商对 PHP 的支持更为友好,甚至一些提供商提供一键安装 WordPress 的服务。而 MT 的安装怎么也需要用户懂一点点技术才成。

好的工具才会激发写作的乐趣,MT 属于这样的工具

EOF

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