从 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–

CAP：高可用架构的另一基石

在上周六的 QClub 上，BASE 成为了一个热点话题，其实除了这个 BASE 之外，还有个 CAP 理论也是值得关注一下的。这个概念也来自 Inktomi 公司(被雅虎收购后已是明日黄花)的 Eric A. Brewer ，应该说他 10 年前的那篇 Lessons from Internet Services: ACID vs. BASE 是互联网技术最为重要的一篇文章了。

C: Consistency 一致性 
A: Availability 可用性
P: Tolerance of network Partition 分区容忍性(有翻译为耐受性的，个人觉得不妥)

熊掌与鱼不可兼得，三个目标不能同时满足。如果对”一致性”要求高，且必需要做到”分区”，那么就要牺牲可用性；而对大型网站，可用性与分区容忍性优先级要高于数据一致性，一般会尽量朝着 A、P 的方向设计，然后通过其它手段保证对于一致性的商务需求。

CAP 不是什么高深的东西，应该说 CAP 只是一个经验理论，切不可钻牛角尖，号称自己做的东西能打破 CAP 理论，那只是无意义的事情罢了。

如果知道 ACID(酸) 、BASE(碱) 在词典中的含义，那么这个 CAP 的辞典含义也很有趣。

–EOF–

最后推荐阅读一下这篇：可伸缩性原则

QClub 杭州站成功在支付宝举行

我开始还有点担心到底多少人会来参加这次 QClub，毕竟这几天杭州太热了，不过大家的热情比天气还热 :) 甚至还有从上海、宁波等地赶来的朋友，如果今天的技术活动能让各位感到不虚此行则是我们莫大的荣幸，非常感谢各位朋友的光临!

组织这样的会议，我也不是很有经验，希望没有怠慢了大家。有点小纰漏：最后要不是同事提醒，为大家准备的 T 恤居然差点忘了发送，有几位朋友走的快，可能没有拿到 T 恤，希望下次活动的时候给大家补上。

会议内容，回头 InfoQ 泰稳那边会有视频和文字的技术内容，我这里先发点会议的照片(拍的好的可能是同事拍的，拍的手法很差的基本是我按的快门，如有不合适的地方请通知我，完整的照片集等下周整理一下放上来）。

上图：会议结束时合影

上图：泰稳拿了一只录音笔，让程立别在身上；同事拿来一只录音笔，程立也别在衣服上；接着又要拿无线麦克风，发现身上挂的东西太多了 :)

上图：聚精会神。可见程立的技术分享之精彩。

上图：左边：支付宝架构师胡喜，右：淘宝架构师林昊(BlueDavy)，有点遗憾的是没让他给大家分享点东西:)

上图：谈到妙处，开怀一笑。

上图：这两个朋友对支付宝的学习发展计划居然很感兴趣 :) 今天活动的会议室平时支付宝用来做新员工培训的，所以墙壁上有很多招贴画、手写的海报什么的。

更多照片看我的 Flickr 或者 Yupoo 相册。

–EOF–