小隔間裡的人生

資料庫在 Web 2.0 的發展上到底扮演怎樣的角色 ?

Tim O’Reilly 在他發表 MySQL User Conference keynote speach 之前，曾經問過一些應用到 web 2.0 的公司，詢問他們如何把資料庫應用在他們的程式裡面；而在會議結束後，他決定把他訪談到的這些東西給寫成一個系列 (共有 9 篇)…

第一篇是訪問 Second Life 的 Cory Ondrejka 和 Ian Wilkes；他們現在的作法是把資料散在一堆資料庫裡，然後查詢時要進主要的資料庫去看看該去哪裡撈… “不夠用就加機器” 這種型的。我覺得重點在這一段話：

I think the biggest lesson we learned is that databases need to be treated as a commodity. Standardized, interchangeable parts are far better in the long run than highly-optimized, special-purpose gear.

第二篇是訪問 bloglines 的 Mark Fletcher 和 memeorandum 的 Gabe Rivera；相對於 Second Life，這篇的這兩家公司可以說都是 “男子漢” 型的玩法，他們都是 “flat file 派” 的忠實擁護者：memeorandum 用了 600M 的記憶體存放資料，而 bloglines 則是自己寫了個分散式檔案系統。

bloglines 目前只有使用者資料和 Feeds 資訊是存在資料庫裡面 (不是常見的 relational database 喔… 他們的選擇也是很硬漢的… 用 Sleepycat !!)，而真正的文章本身則是丟進自製的分散式檔案系統，再加上 memcached 的快取機制。下面這段話值得大家思考：

Sure, we could have just gone with Oracle running on a big SAN, but that would have been very expensive overkill, both on the hardware and on the software licenses (and features, for that matter). And relational databases oftentimes are not the most efficient mechanism to store data, so we’d still most likely have to resort to using memcacheds.

至於 memeorandum，它們把所有資料都放進記憶體裡面，反正只吃 600M 的記憶體，雖然在啟動的時候會慢點，但是在搜尋的時候賺到的時間似乎也值回票價了。下面這段話真的是只有真男人才說得出來：

eval and Data::Dumper (a sort of “reverse eval” for data) are a handy way to read / write data certain kinds of data when you’re not using a database. I do wish eval ran a little faster though. I wonder how much optimization effort has been put into that.

PS. 後面的 comment 是 “flat file 派” 和 “RDBMS 派” 的大亂鬥 (flame war)，看看就好，沒事不要去插嘴 :p

第三篇是訪問 flickr 的 Cal Henderson；在這篇訪談中解決了我的多年疑惑，那就是那些 free format 的 tag 到底是以怎樣的型式存在資料庫中的 ? 答案是 “denormalization”。他們的資料庫約是 935G (對，沒錯，光資料庫的部份就快要 1T，還不包括圖檔…)，但是資料庫真正的大小約達 3T，等於多花了兩倍的空間；denormalization 是要付出代價的，他們要寫額外的程式去產生這些資料，而且還要有額外的程式來確保資料間的一致性。下面這段話應該是他的感想：

tags are an interesting one. lots of the ‘web 2.0′ feature set doesn’t fit well with traditional normalised db schema design. denormalization (or heavy caching) is the only way to generate a tag cloud in milliseconds for hundereds of millions of tags.

第四篇是訪問 NASA World Wind 的 Patrick Hogan；目前他們的作法是 flat file 和資料庫混用，在 cilent 端用 flat file 增加效率，在 server 端用資料庫吐圖片出來。這篇好像沒什麼經典名句，所以我就跳過吧…

第五篇是訪問 craigslist 的 Eric Scheide；他講了很多有關於他們的系統配備和資料庫現況的資訊，但是最重要的架構問題似乎一句也沒提到 XD 惟一一句比較中肯的話大概是下面這句：

databases are good at doing some of the heavy lifting, go sort this, give me some of that, but if your database gets hot you are in a world of trouble so make sure can cache stuff up front. Protect your db!

另外他也提到升級很重要，明明 change log 沒寫什麼，但是速度硬是可以快上許多 :p

第六篇則是訪問 O’Reilly 公司自己人，Roger Magoulas；不過我覺得這篇訪談和資料庫似乎不能算是有什麼關係，倒是和怎樣處理 “資訊” 比較有關。

第七篇是訪問 Google 的 Jeff Dean，他是發展 BigTable 和 Google File System 的成員之一；不過很可惜的是他也是惜言如金，想了解的人只好從他去年的一場公開演講去推敲。

第八篇是訪問 Findory 和 Amazon 的 Greg Linden；他們用 Sleepycat 的 BerkeleyDB 來做 read-only 的資料庫，如果是需要寫入的資料 (例如使用者的紀錄) 就丟 MySQL。這裡面臨了一個問題：在 server 很多的情況下、這些 read-only 的 BerkeleyDB 該怎麼放 ? BerkeleyDB 在 read-only 的時候是很棒沒錯，但是如果透過 NFS 來分享的話就必需要考慮到 NFS 的不穩定性；在其他的替代方案都還不成熟的情況下，他們最後決定每一台 server 都放一份 read-only 的 BerkeleyDB 檔 XD

第九篇是最後一篇了，是 MySQL 的 Brian Aker 對前幾篇文章的回應；他說他覺得大家在開發系統的時候碰到的問題都很類似，而解決的方法也都很類似…

There are very common design patterns for how to scale a database, and few sites really turn out to be all that original. Everyone arrives at certain truths, flat files with multiple dimensions don’t scale, you will need to partition your data in some manner, and in the end caching is a requirement.

Tim O’Reilly 對這點持同意的態度，但是在另一方面，他說大型站台在碰到 scale 問題的時候，通常的解法並不是從 flat file 改成用 SQL，而是從 flat file 改成用自己搞的專屬系統。關於這部份，comment 裡面有很不錯的回答，是 PostgreSQL 的 Josh Berkus 提出來的，他說 RDBMS 是一個一般性的工具，你拿一般性的工具去和特製的工具比較，這樣是不公平的；如果你對未來要做什麼事情很有把握的話，當然是自己搞一套專用的才能發揮最大的效能，但是如果你不確定的話，RDBMS 還是你最好的選擇。