15 March 2010

昨天看了一篇 Cassandra 的 modeling 範例

WTF is a SuperColumn? An Intro to the Cassandra Data Model

這一篇我看兩次了,現在終於看懂一半了... NoSQL 號稱 schema free ,可以自由設計,可是遠比 Relational 還難設計很多。設計 Cassandra 的 'schema' 時,我們必需先想好要怎麼 query (你的 use case) ,然後才能下手。然後幾乎是一個 query 就要生一個專用的 'table' 給他用。

用比較的方式來想:如果我們在 RDBMS 裡有一個 table ,然後對這個 table 有三種 use case,在 RDBMS 裡我們就寫三個 SQL,然後加加 index 改進效能。這樣的需求在 cassandra 就變成要生出三個 'table' 專門來應付這三個 use case,而且,想當然爾,這三個 table 的資料全部 denormalize。

Cassandra 這樣做與 relational 相比有什麼缺點呢?最直接的是:我們得事先知道這三個 use case,不然設計不出來。而軟體的專案特性是什麼?需求只會一直改!而且還會隨時間不斷冒出來!Relational 可以讓我們在 '事後' 需求出現後,寫個 SQL 補個 index 就搞定了。 Cassandra 可不行啊,我們得為那個 query, clone 一整份 table 的資料, 然後如果有其他地方 update 的話,也要通通一起改 (都 denormalized 了嘛....)

NoSQL 這樣的概念完全無法適應客製軟體的開發,尤其是在 enterprise 裡,那種瞬息萬變的各種專案大小需求,用這篇 blog 的範例舉例:例如本來的用戶需求是:"我要列出某個有 sports tag 的所有 blog 文",當時我們用 nosql 設計好了。然後之後 woods 事件爆發,他跑來說,我要改成 "列有 sports tag, 但是沒有 woods 的 blog 文"

哇咧!用 Cassendra 是要怎麼改?只能再做一個 sports minus woods 的 'table' ,然後 insert 到 sports 的程式通通再改寫一遍。暈倒,想到就沒力!

但是!如果 blog 系統是給一億人用,那又是另外一回事了,我想RDBMS根本跑不起來。Cassandra 再難用也得用了。也許適合用 NoSQL 的 project 都有類似的特質:

  • 用戶超多,使用時間也長

    因此用戶其實也很抗拒改變,想想 facebook 改版多少人在叫了

  • 改變的動機來自於平台商內部,而不是用戶

    一般軟體是 "付錢的" 用戶不斷提需求的,所以要不斷的改,但 facebook/twitter 感覺就是平台商施捨給用戶的,我 (平台) 給多少功能,你 (用戶) 就用多少功能,誰叫你沒付錢呢?需求改變的頻率變成由平台商主導,所以改變數也可以大大減少吧。

想到這裡,我就覺得 NoSQL 並不會改變 IT 界的日常生態,也完全無法取代 SQL。只有在 mega web apps 這個圈子的人才有機會碰到,也許未來這會變常態,也許不會。


回響

可以用 Tag <I>、<B>,程式碼請用 <PRE>