DBA notes

翻看以前的 Twitter 记录，把这三句话检了出来：

GFW 第一定律：只要是 “用户产生内容”(User-generated content, UGC) 的国外网站都会被和谐。

GFW 第二定律：只要是被和谐的网站，国内一定会有个克隆版。

GFW 第三定律：没有被和谐的网站一定不是同类竞争者中最出色的。

今天是几个月来非常郁闷的一天。是以为记。

--EOF--

Posted by Fenng at 8:47 PM | Permalink | Comments (18)

现在是 SNS 的春天，最近又有消息传言新闻集团准备收购 LinkedIn。有趣的是，LinkedIn 也是 Paypal 黑帮 成员创建的。在最近一个季度，有两个 Web 2.0 应用我用的比较频繁。一个是Twitter，另一个就是 LinkedIn。

LinkedIn 的 CTO Jean-Luc Vaillant 在 QCon 大会上做了 ”Linked-In: Lessons learned and growth and scalability“ 的报告。不能错过，写一则 Blog 记录之。

LinkedIn 雇员有 180 个，在 Web 2.0 公司中算是比较多的，不过人家自从 2006 年就盈利了，这在 Web 2.0 站点中可算少的。用户超过 1600 万，现在每月新增 100 万，50％ 会员来自海外(中国用户不少，也包括我).

开篇明义，直接说这个议题不讲"监控、负载均衡”等话题，而是实实在在对这样特定类型站点遇到的技术问题做了分享。LinkedIn 的服务器多是 x86 上的 Solaris ，关键 DB 用的是 Oracle 10g。人与人之间的关系图生成的时候，关系数据库有些不合时宜，而把数据放到内存里进行计算就是必经之路。具体一点说，LinkedIn 的基本模式是这样的：前台应用服务器面向用户，中间是DB，而DB的后边还有计算服务器来计算用户间的关系图的。

问题出来了，如何保证数据在各个 RAM 块(也就是不同的计算服务器)中是同步的呢? 需要一个比较理想的数据总线(DataBus)机制。

第一个方式是用 Timestamp . 对记录设置一个字段，标记最新更新时间。这个解决方法还是不错的---除了有个难以容忍的缺陷。什么问题？就是 Timestamp 是 SQL调用发起的时间，而不是 Commit 的确切时间。步调就不一致喽。

第二个办法，用 Oracle 的 ORA_ROWSCN (还好是 Oracle 10g). 这个伪列包含 Commit 时候的 SCN(System Change Number)，是自增的，DB 自己实现的，对性能没有影响。Ora_ROWSCN 默认是数据库块级别的粒度，当然也可做到行级别的粒度。唯一的缺点是不能索引(伪列). 解决办法倒也不复杂：增加一个 SCN 列，默认值"无限大"。然后用选择比某个 SCN 大的值就可以界定需要的数据扔到计算服务器的内存里。

ORA_ROWSCN 是 Oracle 10g 新增的一个特性，不得不承认，我过去忽略了这一点。我比较好奇的是，国内的 Wealink、联络家等站点是如何解决这个关系图的计算的呢?

--EOF--

一点题外话：我的 LinkedIn Profile (Mail : dbanotes@gmail.com). Keep in Touch!。 另外建议正在找工作的同学不妨使用一下这类站点(国内的有联络家和若邻)。一般人我不告诉他~~

Posted by Fenng at 9:58 PM | Permalink | Comments (4)

本周有幸听了阿里巴巴首席顾问关明生(Savio) 的一次演讲分享。记住了几句很有意思的话：

1）创新不是在"家里"发生的

2）今天最高的表现只是明天最低的要求

3）年轻人要的是前途，而不是钱途

这几句真的有"可意会不可言传"的那么一点感觉在内。当然，有意思的话往往不是绝对正确的。慢慢琢磨才有意思。

如果错过这次讲座，不妨阅读一下Savio 过去的一次演讲提要。内容或许类似，但是缺乏现场互动，怕是很难得到深刻的印象。比如同样是那个 “狗、野狗、小白兔、牛、明星” 的坐标系描述，不同的人就是能讲出来不同的理解来。

--EOF--

今天洋节是感恩节，嗯，要常感恩之心。

Posted by Fenng at 6:47 PM | Permalink | Comments (0)

旧金山举行的 QCon 会议带给我们很多新鲜的信息。虽然没机会参加，但是看看各个网站"晒架构"也是个比较过瘾的事情。请参观并收藏这个页面：Architectures you've always wondered about。

eBay 的架构和去年相比基本是换汤不换药，倒是 Yahoo! 的 Ian Flint(这位老兄是 Bix 的运营总监. Bix 已被雅虎收购) 这个 PPT Yahoo! Communities Architecture: Unlikely Bedfellows 挺有意思，披露了一些鲜为人知的信息。

Yahoo! 社区包括我们比较熟悉的 del.icio.us、Flickr、Yahoo!群组、Yahoo! Mail、Bix等。相当于 Yahoo！把这些属性相近的应用放到一起运营。这个思路倒是和盛大对游戏的运营有些相近。

架构特点

有两点值得注意：1）层次化 2）模块化。这也是大规模作业下的比较经济的途径。

软件架构

首先是操作系统已经从 FreeBSD 逐渐迁移到 RHEL。这怕是雅虎不得已作出来的决定吧。FreeBSD 的开发力量的确不如 Linux，这也是不争的事实。数据库上 MySQL 与 Oracle 都有。Yahoo! 在 DW/BI 用的是 Oracle，构建了一个超大数据库。诸如 yapache、yts(反向代理服务器)、yfor(提供快速失败接管)、 ymon（监控），还有还有ysquid、ypan(cpan的 Yahoo! 克隆) 这些组件都是通过 yinst 来统计部署。关于 Yapache，请参考我以前写的 Yapache-Yahoo! Apache 的秘密

这是 Bix 与 DB 有关的部署架构:

数据放在 Netapp NAS 上(所以有的时候应用之慢也可以理解了)，通过快照复制到其他数据中心。

Yahoo! Mail 架构：

这里面居然部署了 Oracle RAC，用来存储 Mail 服务相关的 Meta 数据。非常有趣。

运营维护

监控工具主要用的是 Nagios，用以监控集群。使用标准插件，另外也有自行定制的插件。Nagios 这东西太棒了。主动、被动检查的消息转发是通过 Ymon 来做到。网管上针对 SNMP 的解决方案是用 Yahoo！自己 Y 字头的 Ywatch。这些 Y 字头的东西基本上外面都是找不到的。Yahoo！的技术其实并不那么开放。Google 在运营这方面也好不到什么地方去。趋势图用 Drraw 展现。Drraw 是基于 RRDtool 的 Web 展现工具。

应用服务器的监控是被动的。整个监控系统模块化部署。Nagios 的警告信息转发到 Ywatch 中心控制台。

Note: 上面所有截图版权都属于 Ian (Image COPYRIGHT@IAN) 。如果去看那个 PDF 文件，你或许比我收获更多。我只是让你知道我的想法而已。

--EOF--

Posted by Fenng at 10:01 PM | Permalink | Comments (6)