補「MySQL 在 Mtron SSD 上的測試」這篇的說明。
價位上,Mtron SSD Pro 7000 系列 32GB 的單顆進價大約在 $40K (含稅),兩顆就 $80K 了,相較 15K RPM 73GB SCSI 硬碟四顆只要 $40K 的價錢偏高不少。
效率上,MyISAM 的 real data 測試發現不論是 Mtron SSD 32GB*2 跑 RAID0,還是 15K RPM 73GB SCSI*4 跑 RAID10,都是 CPU 先到瓶頸,I/O 都沒有問題。至於 InnoDB 的結果在 Kevin Burton 的 Blog 上可以看到不少 real data 的資訊。
不過,如果你的資料庫遇到 I/O 瓶頸的話 (用 RAID 1+0 都還解決不了) 可以考慮用多顆 Mtron SSD RAID 把效率換出來,不過比較治本的方法應該是改寫程式,想辦法 partition。另外看看是不是因為大量的 Table scan 造成效率低落…
對了,Mtron SSD 硬碟台灣有代理商了,曜紅科技。
在 MySQL Proxy 作者的 Blog 上看到一些關於 transaction 時有趣的用法:
話說回來,最近 lighttpd 又有一陣子沒什麼動作了,看起來心力都花在 MySQL 上面了…
InnoDB Barracuda (InnoDB Plugin 提供的新格式) 有測試結果了,在「Testing InnoDB “Barracuda” format with compression」這篇裡面以一個 30GB 的 mysqldump 檔案測試 (看他文章的內容,應該是 real data),在裡面提到幾個重點:
- 目前的 MySQL 有個與 UTF-8 有關的 bug 會影響測試結果 (「mysql_alter_table() unnecessarily does full table copy」),所以測試時以 latin1 測試。
- 為了測試 fast index,他用兩種不同的方式測試。第一種是把所有 DB scheme 與 index 都建立好,再將資料匯入;第二種是只先建立 primary key,等到匯入資料後再下 index。測試的結果發現,後者的總時間遠遠超越前者。
- 如果使用壓縮格式,匯入的速度會慢 30% ~ 50%,但是檔案大小只有原來的 1/3,讀取的速度不在這次測試的範圍裡,不過 comment 有人期待對於偏 I/O 的 query 效能會有提昇。
好幾天沒寫 Blog 了,主要是星期五六日去員工旅遊 (參考「員工旅遊 (2008/04/18~20) 」這邊),然後星期日晚上與星期一狂看 Bloglines 與新番,於是就好幾天沒寫 Blog 了…
說變天的原因是因為很多單位在 MySQL Conference & Expo 2008 這段時間發表了一堆東西,就管理與政策面來看,這是 Sun 買下 MySQL AB 後第一次的 MySQL Conference,很多人都在看 Sun 對於 MySQL 這套 Open Source Software 到底會有什麼大計畫。
另外一方面 (技術上),Oracle 推出的 InnoDB Plugin 所列出的優點讓人相當驚豔,解決了不少問題,不過可惜在目前最新版 5.1.24-rc 上無法運作。
再來是 Kickfire 用硬體的方式大幅增加 transaction 的速度,站上 Non-cluster 100GB data 的王座,實際上機器也很便宜,才 USD$35K。(如果你真的需要用到這麼快的 transaction 速度,百萬台幣應該不是什麼問題)
結果玩回來後發現一堆計畫都要再重新思考…
The 2008 MySQL Conference & Expo 幾個比較大的消息:
其他比較小的消息還包括了 MySQL 6.0、MySQL 5.1 Maria 之類的新聞,不過上面這兩個消息丟出來就讓人感覺很兇暴,其他的新聞就… (Kickfire 的 C/P 表現相當漂亮,在 100GB 的地方徹底殲滅 HP 與 Dell)
OSDC.TW 2008 第一天我是中午才到的。在技術方面,大多數的題目都已經在網路上看過資料研究過,沒有什麼特別的感想,不過可以感覺到有些講者可能因為經驗與時間的關係,有些重要的地方都沒講清楚。
先是我們自己家介紹的 Berkeley DB,jnlin 沒有提到為何要避免使用 LEFT JOIN 的原因,然後在測試的部份數據也少說明了很多東西。
另外 Vivek Ratan 講 Hadoop 的部份,有些地方沒有講清楚,像是要怎麼因應 Namenode 故障時的處理 (在「Metadata Disk Failure」這邊的說明可以參考)。另外我回來查了以後發現跑 Hadoop 後,所需要的時間變成原來的 66%,而不是效率變成原來的 66%,所以我在台下問了一個笨問題…
第一天結束後倒是到樓下的咖啡廳聊了很久,儘講些有的沒的…
幾天前就一直有消息,Google 打算要把 BigTable 的服務拿出來給大家用。結果拿出來的餅比預期的更大,直接幫你 Hosting 整個服務:Google App Engine。
Google App Engine 目前以 Python 為語言 (更仔細的說,是以 Django 為參考的標準,所以有用過 Django 的人會蠻熟悉的),後端則是以 GFS 與 BigTable 支撐整個系統。Hosting 的服務以 appspot.com 這個獨立域名避免 Cookie 與 XSS 安全性的問題,看起來是呼應 blogspot.com。
昨天一睡醒看到有一萬個人的註冊限制,就先丟進去註冊,出門到公司就發現已經申請到了。
另外,這個系統有一些限制:500MB storage、200M CPU cycle/day、10GB bandwidth/day,這個量對於自己玩看起來是沒什麼問題,等到收費後要看看價錢到底如何。
在開始玩之前,看看 The Datastore API 可以知道 BigTable 可以做到的事情,其實還蠻有趣的,像是不支援「!=」… XD
Update:在「TechCrunch Labs: Our Experience Building And Launching An App On Google App Engine」這篇裡面有後台的畫面,可以看到相當多資訊!
參考:Google App Engine。