Tag Archives: S3

37Signals 架构

如果没有 37signals ，恐怕也没有 RoR 的如此流行。37signals 对于很多 Geek 来说，是一家非常迷人的公司。他们是网络上的另类新星。

37Signals 在 Signal vs. Noise 上披露了比较详细的运营数据，Ask 37signals: Numbers?

存储数据量

截止到 2007 年 11 月，总存储量统计：

  • 5.9 T 用户上传的数据
  • 888 GB 上传文件 (900,000 请求)
  • 2 TB 文件下载 (8,500,000 请求)

这包括 Basecamp、Highrise、BackPack、Campfire总的数据统计。总的用户量其实并不多，只有 200 万。

这些数据存放在 Amazon S3 上，37Signals 用了这个服务已经一年多了，他们对此比较满意。事实上，Amazon S3 已经成为 Web 2.0 分布式存储的既定事实的解决方案。

服务器状况

37Signals 当前正在部署虚拟化软件产品，当然不用 VMware，而用开源的 Xen。当前大约有 30 台服务器，从单 CPU 的文件服务器到 8 CPU 的应用服务器都有，总共 100 颗 CPU、200GB 内存。预计 XEN 部署完毕后，服务器数量降低到 16 台，92 颗更快的 CPU、230GB 的内存量。这样做的主要目的是管理起来更方便(至于性能是否更好，我个人还是有点怀疑的–Fenng)。

关心 ROR 以及具体一些策略具体实现的朋友不防去看看那个帖子下面的留言。

之前还真的很少有听说哪家 Web 2.0 公司部署 XEN 的，37signals 的这个动作或许是个积极的信号。2007 年也是个”虚拟化”年，相信随着虚拟化的技术成熟，开源力量的壮大，会有更多的公司收益于 XEN 虚拟化架构.

–EOF–

Amazon 的新服务：SimpleDB™

Amazon 真是酷到家了。在 S3 和 EC2 之后又搞出来一个 SimpleDB™ 。Amazon 一手构造的计算环境中现在又加上了数据库，真是很有想象力的项目。

在 Web Service 上，Amazon 可以说是身体力行，领跑多年。S3 解决海量数据(非结构化)托管问题(虽然当下也是赔本赚吆喝)，EC2 解决企业计算问题，SimpleDB™ 则针对结构化数据查询的解决方案，目前已经能够提供数据库的一些核心功能。对用户来说，你不再需要针对数据库的复杂的维护工作，也就是可以不用数据库管理员( DBA ) 了 。当然，DBA 也不用担心，这个工种不会消失，SimpleDB™ 针对的买方是那些只需用简单的关系型数据的 Web 项目，传统的 RDBMS 功能复杂，但是很多小项目其实只是用到一些核心的功能而已，如大家常说的增、删、改、查，这或许也是帕累托法则的运用吧。

RDBMS 当然不会消亡，SimpleDB™ 是 RDBMS 的竞争对手，也是 RDBMS 的一个补充(我非常奇怪为什么不叫做 WebDB，嘿)。从这一点上说，SimpleDB™ 还是开启了一片蓝海，只是海水比较深，没有足够技术船也过不去。

–EOF–

BTW: 虽然这个消息已经被很多人写了，我还是想写一下，毕竟这也是关于 DB 的事情

Updated: 小道消息，”SimpleDB stuff is Erlang on top BerkleyDB“，如果这么说，或许 Oracle 偷着乐呢

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–