Monthly Archives: August 2008

从 Flickr 的 DB 服务器配置说起 Swap

又读了一遍这个 PPT： Federation at Flickr: Doing Billions of Queries Per Day ，发现还是值得咀嚼一下，尽管这”甘蔗”已经被吃过了。

针对主机环境的实践参考

Flickr 数据库的硬件配置一般用 16G 内存，6块 15K 硬盘，RAID 10，在 EM64T 下跑 RHEL 4，运行在 Deadline I/O 调度器 模式 。回写 Cache 用控制器电池而不用磁盘的 Cache。Swappiness 设置为 0 . 。

大内存数据库服务器的 Swap 设置问题

上面提到了 Flickr 是把 Swappiness 设置为 0 ，简单的通过:

echo 0 > /proc/sys/vm/swappiness

个别情况下这样也可能没起作用，因为实际上对 Swap 的调用是由如下的公式计算得到的：

swap_tendency = mapped_ratio/2 + distress + vm_swappiness;

其中 vm_swappiness 默认值是 60.

这是个防御性的措施。Linux Kernel 2.6 （个别版本）有些诡异行为，当有大量物理内存空闲的时候，Linux 仍(或许)会傻乎乎的调用 Swap 空间，这导致有的时候系统性能很差。有人建议如果是 INNODB 的引擎的话，可以用 O_DIRECT 的方式强制直接调用物理内存。但似乎副作用很大（存疑)。

如果关闭 Swap (swapoff -a)的话，又会遇到 OOM 的问题。这是绝对不推荐的。

还有人用的方式是把 Swap 建立到 RAM 盘上。

Swap 的自动校正其实是个老问题，几年前可能超过 4g 的 Linux 服务器都不多，而现在动辄几十 G 的内存配置，应用场景发生了很大变化，Kernel 的算法思路肯定也要调整一些了吧(尽管几年来不断看到有小的 Patch 出来，可好像 RHEL 的 Kernel 还是老样子)。

我在这里抛砖引玉，大家实际应用中应该也遇到类似问题吧? 有什么建议? 还是干脆就不管? 默认情况下其实也能跑…

–EOF–

Paypal 的 数据仓库管窥

一直以来，Paypal 的技术信息都很封闭的，很少能看到披露后台关于信息架构的东西。

Paypal 当前的数据仓库用的是 NCR Teradata ，32 个节点，50 TB 的数据，耗时三年打造。而整个公司投入在 BI 范围上的资金占据全部 IT 投入的 60%。

之前 Paypal 用的是 Oracle 数据仓库的解决方案，旧的 Oracle 数据仓库环境其实类似生产环境 Schema 数据的镜像。从 Oracle 到 Teradata ，不是简单的迁移，而是完全重构了数据模型，对数据重新清洗并提高数据质量。

因为欧美是依赖信用卡的消费习惯，所以 Paypal 面对的信用卡消费欺诈还是很严重的，一度高达 0.25% 的资损(印象中好像有段时间来自俄罗斯和东欧的欺诈特别多)，这可能也是 Paypal 在数据仓库/BI 上投入重金的一个原因(此外还收购了 Fraud Sciences 公司来减少这方面的风险)。

除了有效提供损益报告，Paypal 的数据仓库还必须即时有效的提供的一个指标叫做 “Funny Mix”，代表信用卡资金交易帐务平衡指标与 ACH(自动化清算所，Automated Clearing House) 帐务平衡。

作为对比 eBay 数据仓库环境每天新进来的数据就有 40TB(和Yahoo! 的DW不相上下)，这样的数据量，处理起来的难度还是有一点点的，据说原来技术人员 90% 的时间要花费在数据清洗上，现在也开始用 Teradata 大集中式数据仓库的模式了。

尽管收集 Paypal 的信息非常不容易，但也希望能挖掘出点有意思的东西来。

–EOF–