刺激 1995 ＝ 肖申克的救贖？

「刺激 1995」這部電影一直都名列我最喜愛的電影的前 5 名，今天在網路上找資料時，無意間逛到一個大陸人的 BLOG，裡面出現了這部電影的海報，但仔細一看電影名稱卻非常的不一樣...

原來這部電影在大陸被翻譯成「肖申克的救贖」...

去查了 WIKI 之後，發現原來台灣的片名翻得比大陸更爛...
以前就一直搞不懂為甚麼要叫「刺激1995」...哪裡有刺激到了？

這部電影的英文原名叫做「The Shawshank Redemption」，單依電影名稱最貼切的翻譯應該是「鯊城監獄的贖罪」吧。



Wiki 相關資料：

肖申克的救贖

MySQL View 效能堪慮

MySQL View 效能堪慮，使用前請三思...


自從上個 CASE 開始使用 MySQL 5，感受到 MySQL 真的有在慢慢進步了，其中 MySQL 5 終於開始支援 VIEW 就是一個重點，但是上一個 CASE 中不敢冒然使用。

今天早上在規劃目前手上 CASE 的 資料庫規格，突然心血來潮想要用 VIEW 來減低 QUERY 的複雜度，在開始實做前照慣例，先上 GOOGLE 搜尋一下相關的資訊。

結果不搜還好，一搜就給我發現大問題，那就是 MySQL 5 的 VIEW 似乎效能不好...主因來自於 MySQL 5 伺服沒有對 VIEW 做最佳化...

這件事對我這個完美主意者來說真是一個天大的災難...等於是叫我不准用 VIEW...看來只好繼續寫落落長的 QUERY 了...




MySQL VIEW 效能相關文章，都是出自「www.mysqlperformanceblog.com」：

MySQL VIEW as performance troublemaker

Derived Tables and Views Performance

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」上面發生，我期待著所有有能力開發程式的人都可以簡單的取得一個良好的環境，為這個世界盡一份小小的力量，讓大家的生活更美好！