在 Bringing up the baby 看到 MySQL Maria 把 feature 都實做出來,開始要針對 bug 修正的階段了。
Maria 是 MySQL 以 MyISAM 為基礎所改良的的 storage engine。對於 Web 服務的使用者來說,與 MyISAM 最主要的差異在於 crash-safe,以及簡單的 transaction。
等暑假的時候再來玩看看...
幹壞事是進步最大的原動力
在 Bringing up the baby 看到 MySQL Maria 把 feature 都實做出來,開始要針對 bug 修正的階段了。
Maria 是 MySQL 以 MyISAM 為基礎所改良的的 storage engine。對於 Web 服務的使用者來說,與 MyISAM 最主要的差異在於 crash-safe,以及簡單的 transaction。
等暑假的時候再來玩看看...
昨天晚上幫人「測試」網站,發現速度卡在 MySQL 的 CPU bound,先用 httperf 丟在背景跑,再用 mytop 抓幾個比較明顯的 slow query,補了幾刀 INDEX 後,速度快了不少,不過還是不太滿意。
印象中 MySQL 除了可以紀錄 slow query 外,還可以紀錄沒用到 INDEX 的 SQL query,花了不少時間才找到。這些指令是可以線上改,不需要重開 (如果你堅持要改設定檔重開也 ok),不過請不要在 production 的機器上開,以免 SQL query 寫的很爛,產生大量的 log:
mysql> SET GLOBAL log_queries_not_using_indexes = 1;
Query OK, 0 rows affected (0.00 sec)
mysql> SET GLOBAL slow_query_log = 1;
Query OK, 0 rows affected (0.00 sec)
PS:這只是告訴你問題在哪裡,而非解決的方法。要知道為什麼會慢,你需要讀不少資料,像是 High Performance MySQL 這類的書籍,以及網路上 MySQL 資料庫長輩們的討論。
Update:翻到 Arjen's Journal - Finding useless indexes 這篇,可以檢查過度 index 時造成效能降低的問題 :p
接下來的幾個禮拜應該都是跟 PHP、MySQL、jQuery 戰鬥了...
PS:說到 MySQL,最近看到的 MySQL Workbench Community 版還蠻好用的,有興趣的人可以下去玩看看 :p
以往 MySQL + memcached 的作法是由 application 端「拉」資料後再塞到 memcached 上,這會產生幾個問題:
這兩個問題都有在 MySQL UDF + memcached 出來之前都有解法:前者可以在更新 MySQL 時順便更新 memcached 裡的資料;後者可以靠 memcached lock 的技巧避免突然有大量 Query 造成後端 MySQL 負荷過重。這兩個方法需要 application (client) 配合,不是很完美,但在實際應用上還算堪用。(一個很簡單的場景:如果公司內同時使用 PHP 與 Perl,那麼就必須維護這兩個 library)
除了 client 自己推資料到 memcached 上,也有人研究,當 MySQL 上的資料更新時,由 MySQL server 自動到 memcached 上更新資料,也就是把資料「推」到 memcached 上的方法。資料更新時的觸發動作可以用 MySQL Trigger 做到,而寫入到 memcached 的部份透過強者的 libmemcached 處理:Memcached Functions for MySQL。
btw,Jan Kneschke 也用 libmemcache 寫過類似的東西:UDF_LUA 這篇的下方 (「MySQL and memcached」的部份)
補「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 時有趣的用法:
InnoDB Barracuda (InnoDB Plugin 提供的新格式) 有測試結果了,在「Testing InnoDB "Barracuda" format with compression」這篇裡面以一個 30GB 的 mysqldump 檔案測試 (看他文章的內容,應該是 real data),在裡面提到幾個重點:
好幾天沒寫 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 速度,百萬台幣應該不是什麼問題)
結果玩回來後發現一堆計畫都要再重新思考...