2008年7月3日 星期四

Google App Engine 之 Python 與 BigTable 心得


上星期 5 (2008/06/27) 從朋友那裡得知有「Google App Engine」這個新的服務後,就開一連串對這個新服務的研究與測試。結果發現使用 Python 的問題不算大,而 BigTable 這個非關聯資料庫對於已經熟悉傳統關聯資料庫開發的技術人員來說,應該才是個真正的門檻。





首先來說說 Python。

在這次研究「Google App Engine」之前,我對 Python 的瞭解都只限於「是一種直譯式程式語言,跟 JAVA 有點像,可以用於 WEB 與 APPLICATION」,直到這次才有機會比較深入的去試試看 Python 到底是個什麼東西。

我得到 3 點心得:

1.結構鬆散
因為我一直都習慣使用 C 與 C++,而網頁程式也大都使用 PHP 開發,因此 Python 給我的第一個感覺是「很鬆散」...Python 並沒有像 C 語言的大括號 { } 可以用來切割程式碼的層級,因此只要程式碼比較長一點或是層級比較多一些,閱讀上就會變得很吃力...


2.格式限制
Python 的每個層級「一定」要用「兩個空格」做間隔,多了或少了都不行!這其實也是起因於 Python 沒有像 C++ 的大括號 { } 可以用來切割程式碼的層級,因此 Python 無法知道每個層級的開始與結束位置在哪裡,所以就必須要強制規定每個層級都是以「兩個空格」做間隔...

這對於程式設計師來說真是個惡夢!我在測試的期間就曾經因為不小心多按了一個 SPEACE 而跳出一個「怵目驚心」的花花綠綠錯誤警告頁面...當最後發現止是多按了一個 SPEACE 時,心裡著實有用力的喊了一聲「靠...」。


3.其實沒那麼難
基本上只要會寫 PHP 5(物件導向)、C++ 或 JAVA 的人,對於 Python 應該都會能夠快速的上手,因為 Python 用起來的感覺是「十分簡化後的 C++」,因此要使用「Google App Engine」這個服務的門檻其實沒有想像中的這麼高。





再來講講 BigTable。

這是我第一次聽到 BigTable 的名號,雖然經過閱讀一堆文件之後發現 Google 的很多產品都是使用這個資料庫,例如有名的 Google Analizy、Google Earth....等等,真是一個令人驚訝的事實阿!

而這更是我第一次接觸「非關聯式資料庫」,其實也不能這樣說,因為又經過閱讀一堆文件之後,我發現其實「非關聯式資料庫」的典型就是 EXCEL...也就是說,只要用過 EXCEL 的人,都可以自稱使用過「非關聯式資料庫」,只是使用深度上的差異罷了。

我得到以下 3 點心得:

1.丟掉正規化
要使用 BigTable 之前,首先要做的工作就是「把所有正規化的方法與技巧全部丟掉」,因為 BigTable 就像是一個 EXCEL 表格一樣,基本上是沒有必要正規化的,因為正規化的目的是在於「節省資料儲存空間」,而這個目標其實是「關聯式資料庫」的主要目標。

BigTable 的訴求完全不是這樣,BigTable 一開始設計時的主要目標就擺在「處理速度」,對於 Google 的服務來說,反應時間是首要考量,而反應時間要快就要使用叢集平行處理的技術,但正規化過後的資料大部分都只剩下「代號」,這對於叢集平行處理來說是個大問題!因為單一主機中所儲存的資料在沒有其它主機的表格做相互參照的情況下,會變得根本就沒有意義。試想今天你將數個已經正規化過後的表格,分別交給多個人持有,然後個別問他們表格中資料所代表的意義,大概就是那種況!

因此 BigTable 的設計,就像是一個「超大號」EXCEL 工作表,每一筆資料擁有超多的欄位。但在 Google 的眼裡,我們所謂的「超多」對他還說是「少量」,而且 Google 所說的是「欄位家族」(我自己翻的)會有數百個。(Google 的論文「Bigtable: A Distributed Storage System for Structured Data」中提到「It is our intent that the number of distinct column families in a table be small (in the hundreds at most)」)

欄位家族不是欄位,而是欄位的群組,也就是說一個欄位家族中會有很多個欄位...因此你可以想像,在 Google 眼中的「少量」到底有多少...

因此在這樣的架構下,一定要丟掉「所有正規化的想法」,回歸「自然」,然後你就會瞭解該要怎麼把資料儲存在 BigTable 裡面了,就像使用 EXCEL 一樣簡單!


2.不用 JOIN 好像也不錯
因為 BigTable 就像是 EXCEL 一樣,所以沒有 JOIN 這一回事!請試想在 EXCEL 裡面儲存正規化的資料,然後每看一筆資料就要去查另外的一堆表格才知道意義,那是一種何等痛苦的事?
在接受了 BigTable 就像 EXCEL 這個事實之後,我突然發現「不用 JOIN 好像也不賴」,因為取得資料變得超直覺,再也不用思考哪些資料存在什麼表裡面,需要怎麼 JOIN 近來效率才會好,因為取得的資料永遠都是「值」而不再會有「代號」了!


3.空間換取時間的優勢
Google 目前的伺服器數量與儲存空間在世界上是赫赫有名的!在這個儲存空間極度便宜的時代,我們真的還需要斤斤計較正規化所省下來的那一點點的儲存空間嗎?而且在叢集平行處理的加持之下,處理速度快得嚇死人的非關聯式資料庫真的有可能變成接下來的趨勢,至少 Google 帶起了這個可能性,不是嗎?





得到了這些心得之後,再回頭看「Google App Engine」好像也變得比較沒有這麼難搞了。接下來應該會有越來越多的應用在「Google App Engine」上面發生,我期待著所有有能力開發程式的人都可以簡單的取得一個良好的環境,為這個世界盡一份小小的力量,讓大家的生活更美好!





7 意見:

James blog 提到...

你寫的資訊很詳細,推一個!!

FIRCH TSAI 提到...

那是您不嫌棄^_^
謝謝你的推~

匿名 提到...

路人, 只是想和你說, python 並沒有限制"要幾個空格"這回事
只是要"同一層級的空格相同"

例如:

if True:
# 4 spaces here.
a = [1,2,3,4]

if True:
# 2 spaces here.
b = [1,2,3,4]

幾個空格你爽就好, 反正只要在同一個 block 裡一樣多就行

匿名 提到...

認同路人先生,
另外,BigTable其實也是有代號的
ReferenceProperty..

^^ 一點小意見。

匿名 提到...

拜託一下,節省空間並不是正規化的「主要目的」好嗎! 錯的這麼離譜,要寫這種東西前請先真正的去修一下資料庫相關的學分,不要到處用「自己以為」的方式亂掰亂寫

班圖西撰史者 提到...
作者已經移除這則留言。
班圖西撰史者 提到...

的確節省空不是正規化的主要目的,不過,樓上的您可能斷章取義作者的意思了,而且文中也沒提及主要目的是在於節省空間。

常常見到一些過度正規化的資料庫設計,過度的正規化很多時候會造成資料維度增加,而且過度緊密的關聯,對於資料庫系統,增加額外複雜的運算消耗以及低彈性的維護。

而且,其實Big Table的主要目的不是在於更新創建資訊,而是負責將既有的資訊集中,供給"查詢"