Tag Archives: Web2.0

FeedLounge 使用 PostgreSQL 的经验

这是我唯一看到的 Web 2.0 公司使用 PostgreSQL 的，可惜还失败了。

FeedLounge 是一个提供在线 RSS Reader 的站点。已经在今年 6 月 1 日黯然宣布失败。这里不去讨论他们失败的各种原因，只说说从他们 Blog 上看来的关于他们选择数据库的经验。

FeedLounge 在数据库的使用上路线是这样的：

MySQL(MyISAM) --> MySQL(InnoDB) --> PostgreSQL

最初是 MyISAM 方式，迁移到 InnoDB ，数据库从大约 1G 膨胀超出了 10G，而且发现引发了新的性能问题，经过尝试发现不能解决后，迁移到 PostgreSQL，总存储从 InnoDB 方式的 34G 缩小到 9.6G,而且，恢复时间也只是原来的大约 1/5 (导出用 Mysqldump,载入用 psql ). 此外，关于内存利用方式上也有一些差异, MySQL : innodb_buffer_pool 6GB + O_DIRECT flush, PostgreSQL 设置上限 2G，只用了 1.2 G。遗憾的是，看不到切换前后性能数据更为详细的对比。

FeedLounge 当时每天要处理的事务量：每天超过 400 万次查询，超过 200 万次的更新/插入操作，高峰期每秒钟有 2000 个更新/插入操作(这应该是批处理阶段)。硬件如何呢? 数据库服务器的硬件：两路 Opteron CPU，8 GB 内存， 6 SATA 7200RPM 16MB 硬盘， RAID 5 ，控制器有 128M. 可以看出来了吧， 7200 转的硬盘 + RAID 5 根本不适合这样的应用。从这一点上说，数据库类型切换其实解决不了本质的问题。

另外看到的有趣参考信息：

FeedDigest 在当时每天有超过 400 万次的查询，超过 200 万次插入，机器硬件只用了双奔四 CPU(2.8GHz) ，1G内存

–EOF–

闲说 Yahoo 中国

深受网民喜爱的 Flickr 这两天被封掉了，不少网友愤怒之余，不知道是否有人产生这样的疑问:雅虎中国会不会把 Flickr 移植到国内来? Flickr 是个好产品，但想到 del.icio.us 的在国内的正宗克隆版: Yahoo! 收藏+ 的发展状况，几乎可以断言，Flickr 进入国内怕也不能有多大作为。

抛开其他的原因不谈，个人觉得雅虎中国(中国雅虎)现在的产品状况有些陷入”焦油坑”，尤其是在技术上，很难真正的施展拳脚。所作的一些产品还是依赖于美国的技术架构，尤其是底层的基础架构，举例来说，对于很多 Web 页面，用户发起的 URL 请求都必须要和美国的服务器发生 IO 交互。有这样的问题存在，无论 UE 工程师怎么在本地改进，都是无济于事的。近日有传言谷歌打算把服务器放到国内一部分，而雅虎中国可是早在 2005 年就把 2000余台服务器搬到了国内。这么久还藕断丝连，只能说已经太过于纠缠，没办法大刀阔斧的调整了。

在另一方面，域名的混乱程度我认为也导致了很多问题。域名是：yahoo.com.cn (跳转到 cn.yahoo.com , 服务大多是三级域名,相册是: gallery.i.cn.yahoo.com, 这么复杂的域名 100个人有 99 不能正确输入，四级域名的服务也有，’博客’, blog.i.cn.yahoo.com…), 搜索 yahoo.cn …… 我一直很好奇 Alexa 怎么正确统计雅虎中国的访问量 :)

雅虎最近的动作不可谓不多，比如新推出的 Omni-Search ，的确让人眼前一亮，可是看业界的反应，总有些怪怪的，对，就是不够轰动，没有神秘感。试想，如果是 Google 发布这样的产品，业界的反响会是怎样的?

对于一些除搜索外的其他老牌产品，比如电子邮件，现在越来越不够重视。我觉得电子邮件是一个很好的突破口，如果可以做到市场第一，为什么偏偏要跑到第二去呢? 电子邮件本身或许不赚钱，但是带来的相关收益可绝对不容忽视。远的不说，腾讯不也是 QQ 一个产品带活了一大片麽 ? 而现在，埋头做社区、SNS 那一套玩意儿，胜算不知几何。

BTW: Blog 首页最下方有文责声明.

–EOF–

Web 2.0 站点扩展性问题随感

最新一期《程序员》杂志上有篇《Web 2.0 构建要素》的文章，里面描述了一些 Web 2.0 的扩展性问题，这可能也是 Web 2.0 站点从小到大必须承受的苦恼。该文简单介绍了有些站点通过 Amazon S3 服务来解决存储扩展带来的压力。有些站点则必须自己动手构建最适合自身业务的技术方案。
很多比较成功的站点，有的时候会透露出一些关于站点扩展性的技术信息，像我收集的 Flickr 的开发者的 Web 应用优化技巧、Technorati 的后台数据库架构、Craigslist 的数据库架构等，往往是蜻蜓点水，看过之后让人心痒难当，可是更细节的东西又很难获取。尽管这些站点基本都是构建在 OpenSource 软件上，但这一点上看，似乎不够 Open ，唯一一个做的比较好的倒是要算 LiveJournal ，他们通过 Danga 站点贡献了几个经典的软件与一些很有参考价值的文档(如这篇对LiveJournal扩展性的介绍)，是为很多后起 Web 2.0 站点必备的参考信息。
在国内，很多 Web 2.0 站点也同样面临着这样的问题，象豆瓣，阿北还需要身兼 DBA, 而抓虾，虽然数据库已经有上亿级别的记录量，就上次我在北京和谌振宇聊天，感觉抓虾在扩展性上也是还有很多细节需要完善，在杭州，Yupoo 也因为日益增长的数据量而不得不着手考虑如何更为成功的实现分布式存储解决方案……
这些似乎表明，Web 2.0 站点扩展性问题越来越突出，已经成为制约 Web 2.0 发展的一个障碍，”多、快、好、省”的构建新型互联网应用，不知道正在让多少人犯愁。
在传统互联网领域，很多技术解决方案往往是软硬件厂商提出来，类似自上而下的推动，而 Web 2.0 站点变化太快，到现在为止，似乎只有 MySQL 一家公司是比较大的赢家，可是因为面对的客户情况各异，解决方案似乎无从说起(比较简略的实现案例倒是能找到几个)，再者，这些站点基本上是把 MySQL 这样的产品当作基本工具，和其他软硬件相互结合，然后在这个上面灵活构建出很多具有创新性的应用。这是一种自下而上的变化。
另一方便，Web 2.0 架构方面的人才还是稀缺，这个架构不是指某一方面(比如Java)的架构，而是整个产品环境的架构，象 Flickr 技术大牛 Cal Henderson 这样的人几乎是可遇不可求。操作系统、网络、数据库、开发语言每样都能那起来并且能够涉及足够灵活的技术方案，这要求，也的确高了一些。或许有人说，一个人不行，那么多几个人分别负责某几个环节不就成了? 这又带来另外一个问题：人力成本。
上一篇 Blog 我提到五月份的”侠客行“大会，我倒是希望能有一群网络技术人才能够就 “Web 站点可扩展性” 这个话题作一番探讨，每个站点如果都说说自己的心得，那么汇集在一起参考价值会对整个 Web 2.0 环境起到很大的促进作用。
最后，还拿 MySQL 说事儿，去年网志年会上，就有人感叹，国内 MySQL 好手太少了，考虑到物以稀为贵，有的 Oracle DBA 已经开始学习 MySQL 啦.
–EOF–

Second Life 的数据拾零

Matrix 似乎提前来到我们身边。从 06 年开始，陆续看到多次关于 Second Life(SL) 的报道。因为自己的笔记本跑不起来 SL 的客户端，所以一直没有能体会这个虚拟世界的魅力。今天花了一点时间，读了几篇相关的文档。
RealNetworks 前 CTO Philip Rosedale 通过 Linden 实验室创建了 Second Life，2002 年这个项目开始 Alpha 版测试，当时叫做 LindenWorld。
2007 年 2 月 24 日号称已经达到 400 万用户(用户在游戏中被称为 “Residents”，居民)。 2001 年 2 月 1 日，并发用户达到 3 万。并发用户每月的增长是 20%。这个 20%现在看起来有些保守了，随着媒体的关注，增长的会有明显的变化。系统的设计目标是 10 万并发用户，系统的复杂度不小，但 Linden 实验室对SL 的可扩展能力信心满满。
目前在旧金山与达拉斯共有 2000 多台(现在恐怕3000也不止了吧) Intel/AMD 服务器来支撑整个虚拟世界(refer here)。64 位的 AMD 服务器居多。操作系统选用的 Debian Linux，数据库是 MySQL。通过 Tim O’relly 的这篇 Web 2.0 and Databases Part 1: Second Life ，可以了解到一点关于 SL 数据库建设的信息。在 Second Life 中每个地理区域都是运行在服务器软件单一实例上的，叫做”模拟器”或者简称是 “sim”，每个 Sim 负责 16 英亩的虚拟土地。当用户在相邻的 Sim 间移动，实际上是从一个处理器(或是服务器)移动到另一个。根据这篇访谈，用户当前所在 Sim 的信息，以及用户本身的账户信息是存储在一个中心数据库上的。

SL 的客户端软件的下载使用了 Amazon 的 S3 服务。
一点感想：MySQL 真是这波 Web 2.0 大潮中最大赢家之一啊
–EOF–