拜读了关于 LinkedIn 几位工程师写的构建 TB 级的 key-value 系统的经验：Building a terabyte-scale data cycle at LinkedIn with Hadoop and Project Voldemort。具体实现过程有大致的描述，就不鹦鹉学舌了。
其实现在很多公司可能都面临着这个抽象架构图中的类似问题。以 Hadoop 作为后端的计算集群，计算得出来的数据如果要反向推到前面去，用什么方式存储更为恰当? 再放到 DB 里面的话，构建索引是麻烦事；放到 Memcached 之类的 Key-Value 分布式系统中，毕竟只是在内存里，数据又容易丢。Voldemort 算是一个不错的改良方案。
值得借鉴的几点:
关于 key-value 应用的解决方案又多了一种。LinkedIn 对此应用案例也还在发展中。如果业务类型类似，不妨关注一下。
–EOF–
关心 Web 2.0 的朋友对于 LinkedIn 应该都不陌生。我这个 Blog 上以前也介绍过 LinkedIn 的架构信息。最近, LinkedIn 公司的两位工程师在 JavaOne 上做了两个分享。揭示了更多 LinkedIn 架构方面的技术信息。
这是我看到的 Web 2.0 公司中第一个完全拥抱 SOA 的。这个文档中大致描述了 LinkedIn 开发过程上的一些经验。
| ViewNews Service Architecture 对于国内鲜果这样的 RSS 工具网站或许能有点参考价值。另外一个值得注意的地方是架构的变迁，随着业务的增长，后端 DB 的变化非常明显。
这一篇中描述了几次迭代经验，其思路值得借鉴。
| View其中提到了对 CLOB 字段的更新认识。我个人的建议是：不到万不得已，还是别在 Web 应用中用 CLOB 了。
–EOF–
2007 年就快过去了。这一年中， Web 2.0 应用对我的网络生活影响程度更大了一点。回顾一下，除了过去经常用的 del.icio.us、Flickr 等”老一辈“的 Web 2.0 服务外, 今年新熟悉了几个 Web 2.0 服务。
截止到写这篇 Blog 为止，我在 Twitter 上有超过 1000 条更新，Followers 接近 250 个。算得上是个中度用户，中毒还不算深。
Twitter 刚上手不知道怎么玩，但是玩起来还有点容易上瘾。必须要承认 Twitter 是个时间杀手，我过去也担心这东西带来的信息过载，有的时候会有比较大的信息噪音，比如那些绑定了 Feed 到 Twitter 上的朋友，对于 Feed 通知更新太频繁的我都屏蔽掉了，现在尽管每天接收大量 Twitter 的 Updates ，但总体感觉信息还是比较有质量。
顺便说一下，我用 TwitterFox 这个 Firefox 插件。用 IM 收发更新容易受到被动干扰。有些担心有一天 Twitter 会被阻尼，但我不打算用国内的克隆版，使用这些 服务也是为了体验创新的产品设计。
在尝试 LinkedIn 之前，我是若邻 (Wealink.com) 的用户，但若邻的整体用户氛围现在非常让我比较反感，尤其是很多人打着”猎头”的头名来套瓷，还有社区内的很多人一天到晚的转发帖子，信息噪音太大了。LinkedIn 上的用户还是比较规矩的，没事也没人来干扰你。
LinkedIn 是《连线》杂志评选的 2008年十大最值得关注创业公司，符合我要用就用同类站点中最好的习惯，你总不想某天找不到自己辛苦积累的信息吧? 之所以起用 LinkedIn 这样的服务，还是觉得有必要积累一点个人资本，认识一些国内外业内的朋友，互相通通气。我在 LinkedIn 上的 Profile 连接超过了 75 个，估计还能逐渐增加一些，话说回来，LinkedIn 上 Google 的员工，平均每人也只有 47个联系人“。车东在上面有超过 500 个连接，可以作猎头了。
其实面临求职的朋友不妨在 LinkedIn 或者类似的服务上维护一份自己的简历，事半功倍。
其他的 SNS 服务，如 MySpace 或者是 Facebook ，我不打算用。没那个精神头了。
自从 Feedburner 被阻尼了之后，不得不抛弃客户端工具 GreatNews，而起用在线 RSS 阅读工具，另外一个考虑是性能问题，订阅 Feed 超过 1000 个后，GreatNews 更新非常消耗本地资源。虽然抓虾也不错，但我基本上是用抓虾看看热文，大部分的阅读还是在 Google Reader 内，看到不错的文章就 Share 一下，通过 RSS 集成到 CNOUG.net 上，便于 DBA 圈子内的其他朋友也及时看到，共享嘛。
Google Reader 最近的好友间阅读共享功能也很有意思，虽然多数人都在质疑这个功能有泄漏隐私之嫌。我个人觉得可以通过算法来调整这个设计上的漏洞。Google 不是一项强调数据说话麽? 那就来点更智能化的东西吧。
这两天也在尝试 Soup.io 和 FriendFeed 这两个东西，直觉中明年要启用其中的一个。你在去年尝试并喜欢那些 Web 2.0 服务? 说一下吧
–EOF–
现在是 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 : [email protected]). Keep in Touch!。
另外建议正在找工作的同学不妨使用一下这类站点(国内的有联络家和若邻)。一般人我不告诉他~~