DBA notes

利用电脑启动、收邮件的一些零散时间，看完了这本 Inside Facebook 翻译版，感觉有所得。有些朋友说没看到"实质性"的东西，什么是"实质性"的东西? 难道你要看到"成功宝典"么? Facebook 只有一个，东施效颦的模仿者学其形或许还成，学其神就难了。

观点

• 任何一件没有全力以赴的事情，都会对其它员工造成不良影响 ... 一个成功的公司的公司，绝对不应该允许其员工只是简单地维持现状。
• 对于不需要第二天早上八点半爬起来送孩子上学的年轻人来说，熬夜工作是一种纯粹的乐趣。
• 若是待遇不错，客服人员是公司最能解决问题的人手。他们甚至会发自内心地以愉悦的面貌投入工作。

细节

• Google 趋向于招聘领域内的知名专家，而 Facebook 则鼓励工程师成为多面手。
Note: 一个公司能有几个技术上能包打通关的人(比如 Livid 同学)是幸事。但在国内，往往走从泛到专的路线。
• 任何公司里都只有一小部分工程师是最出成果的。
Note: 这么说是不是会伤害很多人? 但这的确是一句真话。对于公司来说，如何在创业初期找到的人都是这一小部分工程师? 对于个人来说，在创业团队如何成为这样的一小部分工程师?
• 现在 Facebook 内部还在用 Trac 。
Note: 工具无所谓轻量级重量级之分。Trac ，可能上一点规模的开发团队都不屑一顾了，看看Facebook，用的挺好。
• 简化会议
Note: 虽然没看到 Facebook 如何开会的，如果 CEO 在会议上的 PPT 都不超过 5 页，其他人也不会好意思来进行冗长的会议。
• CEO 肖恩在生活细节上非常马虎。
Note: 嗯，如果你也有同样的特点，没准也能做CEO呢...

这本书尽管翻译行文上有一些不一致和粗糙的地方，但还是指的一看的。毕竟应该看传递出来有价值的那一部分，盯着一本书的缺点就没意思了。这本书定价不贵，建议买一本也算支持译言翻译小组辛苦的劳动了。

--EOF--

BTW: 最近工作、私事都很多，奥运也来了，可能更新频率会不那么高了，朋友们见谅!

为什么有些人创业成功，而更多人失败? 成功的人当初承担过哪些压力，做过那些重要的抉择? 有没有初创公司的创业者们必须要看的一本书? Founders at Work 或许能担当此重任。

前一段时间在财帮子网站创建人孟岩的推荐后读完了这本书，最近这几天分析 Paypal 的一些东西，又把电子版翻了出来。重新读了一遍对 Paypal 创始人 Max Levchin 的采访。10 年前创建的 Paypal 现在是美国互联网最赚钱的互联网企业，而走出 Paypal 的创建者们，也已形成了 Paypal 黑帮，手握着世界 Web 2.0 公司的权柄。

Paypal 最早并不是做在线支付的。因为 Levchin 对软件安全兴趣由来已久，最初做过软件加密、手持设备转帐软件等，在为手持设备用户开发软件的过程中发现了在线支付的庞大需求量和无限商机，这里面比较关键的一点是Paypal 的及时转身。

如果用一句话概括 Paypal 该怎样描述? 表面是财务服务公司，实际是一家安全公司。 Paypal 最开始的一段时间，最大的挑战倒不是来自竞争对手那里，而是恶意用户的欺诈行为。最高的时侯 Paypal 每个月因为欺诈造成的损失超过 1000 万美元（前面有篇文章我提到 Paypal 现在有 达 0.25% 的资损，我还觉得挺高的，没想到以前更高)，而开始大家对于可能存在的欺诈损失还有些一头雾水，可见摸着石头过河的事情，大家都干过。

与 X.com 合并后，Max Levchin 作为 CTO，而来自 X.com 的"那个家伙"做 CEO 。Paypal 技术架构差点转向 Windows 平台，因为 X.com 是运行在 Windows 上的。工程师的文化对立也比较明显，貌似一场冲突不可避免。问题如何化解呢? Levchin 精心构造了一次测试，对 Unix 、Windows 针对某应用作压力测试，"证实" Windows 扩展性只有 Unix 上的 1%。"那个家伙"闭上了嘴。随之不久，那个家伙离开了 Paypal。如果当初转向 Windows，或许现在的 Paypal 也不是这个样子了...

仅仅因为这篇对 Max Levchin 的采访，就让我要推荐一下这本书。其实，看看其它 Founder 的访谈记录，有趣的东西还有很多，各取所需吧。

--EOF--

又读了一遍这个 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 当前的数据仓库用的是 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--