Home » 2012 » November

MySQL 中,MyISAM 與 InnoDB 帶來的差異...

標題所提到的兩個 engine 是在 MySQL 中最常用到的兩個 engine。其中 MyISAM 是在 MySQL 5.1 之前的 default engine,InnoDB 則是 MySQL 5.5 之後的 default engine。

這篇主要是講 MySQL 5.1 + InnoDB Plugin,或是 MySQL 5.5 後的情況。

MyISAM 是 Table-level lock,當有寫入時其他人無法讀取 (有少數例外,像是 bulk insert)。而 InnoDB 設計成 Row-level lock,在寫入時有很大機會還是可以讀取。

另外,InnoDB 支援 ACID transaction,對於學過資料庫理論的人 (像是科班出身) 會覺得比較「親切」,比起 MyISAM 有很多東西可以用。

大多數不換 InnoDB 有幾個原因:

InnoDB 佔用的空間比較大

最常見的原因是認為 InnoDB 相對 MyISAM 所佔用的空間會大不少 (看過三倍大的):但在 InnoDB 自從推出壓縮功能後就接近很多 (看過只大 20% 的,甚至有可能比 MyISAM 小)。而資料量的問題可以參考 Mobile01 的 55GB (2012 年 10 月 uid=1 的蔣大在 Mobile01 上揭露的數字)。

當網站夠大時,記憶體與用 15KRPM SAS 硬碟加上 RAID1+0 的一次性成本其實不高。

InnoDB 不好備份

第二個常見的原因是認為 MyISAM 備份比較容易,直接 copy 就可以備份:這種備份方式其實有很高的風險造成 inconsistent backup (「備份的資料損毀」)。以交易的例子來說,有 auction 與 user 兩個表格,按照字母順序先複製了 auction 表格,再複製 user 表格,中間使用者用點數購買了某個物品 (扣 user 表格裡的點數,在 auction 裡建立一筆資料)。這份備份裡就會備份到「user 內的點數扣掉,但 auction 沒有資料」的情況。

比較好的方式是用 InnoDB 提供的 transaction 建立 consistent backup,備份時長時間讀取不會像 MyISAM 無法寫入。另外一種方式是建立 backup 專用的 slave,要備份時可以整台 slave 停掉備份 (還有像是 filesystem snapshot 之類的方式,這邊跳過)。

書上寫 MyISAM 效能比較好...

是的,不過這個前提是「如果你只有讀取」。

MyISAM 讀取效能比較好並不是指 MyISAM query 一次 <1ms 時 InnoDB query 一次就要 100ms 這種程度。兩個都還是在 <1ms,只是當你用到「效率不好的 query」時,MyISAM 在 Table scan 的效能會比 InnoDB 好。

但當網站變大遇到 MyISAM + table scan 時就完蛋了:一個 query 卡 1 秒就代表網站上寫入時遇到這個 query 時最少要卡一秒,InnoDB 反而能救你。(雖然這不是好的方向。好的方向應該是想辦法解決 Table scan 的問題,可能是改 query,也有可能是增加 index 或修改 index)

也因為以上的特性,當使用 InnoDB 時,可以這樣設計:

只對時間敏感 Query 加上 Index

以前用 MyISAM 時為了避免跑報表會造成其他線上服務的 query 卡住,如果用 InnoDB 因為不會卡,報表的 query 沒有 index 而 table scan 也是可以接受的。

有嚴格資料正確性需求的 Query 使用 Transaction

像是金流相關系統,一筆購買紀錄可能要修改好幾個表格。用 MyISAM 時必須對好幾個表格使用 TABLE LOCK (仍然有 atomic 問題),現在可以用 transaction 解決。

資料庫正規化

有可能會因為 MyISAM 卡 query 的問題而設計出非正規化的 schema。用 InnoDB 可能可以正規化,用適當的設備成本 (像是適當使用 JOIN) 降低人力維護成本。

虛擬機內的 Side-channel attack...

前陣子在其他地方看到,不過剛剛在「Stealing VM Keys from the Hardware Cache」看到利用 Side-channel attack 的攻擊:「Cross-VM Side Channels and Their Use to Extract Private Keys」。

實際攻擊的項目是 libgcrypt 實做的 ElGamal 演算法,長度是 4096bits。環境是 Xen,限制是在同一台實體機器上。

對抗 side-channel attack 的幾個方法:實體隔離 (效果最好) 或是改善演算法 (通常是犧牲一些演算法效率,換取難以被外部預測的保護)。前者也就是 AWS 為了符合美國政府要求所建立 AWS GovCloud (US) 的原因之一。

WordPress.com 支援 Bitcoin...

昨天 WordPress.com 宣布支援使用 Bitcoin 購買服務。印象中這應該是第一個大型商業網站支援 Bitcoin 付款:「Pay Another Way: Bitcoin」。

WordPress.com 是跟 BitPay 合作,實際上會依照匯率收到美金,不太需要承擔 Bitcoin 匯率不穩的問題。即使如此,這也是很大的進展... 第一步是有兌換商願意出來收 Bitcoin 付美金,以及有商業公司願意使用這些服務。

AWS 澳洲開台!

AWS 在澳洲雪梨開台:「New Asia Pacific (Sydney) Region in Australia - EC2, DynamoDB, S3, and Much More」,成為目前 AWS 南半球第二個服務區域 (第一個是巴西聖保羅)。

幾乎所有主要服務都開台了... 連 AWS Direct Connect 都開 :p

其中兩個主要服務,EC2 的費用與新加坡相同,網路流量部分是亞洲區裡面偏貴的。而 S3 空間費用跟加州一樣貴... 不過講這麼多,用的到的人應該還是會用,畢竟光的速度還是有極限的,建在本地總是有優勢...

接下來會開在俄羅斯嗎?XD

FreeBSD 預設的 compiler 從 GCC 換成 clang

FreeBSD 預設的 compiler (/usr/bin/cc/usr/bin/c++/usr/bin/cpp) 從 GCC 4.2.1 換成 clang 了:「Revision 242624」。

目前只有 CURRENT 裡的 amd64 與 i386 版本換過去,如此一來,FreeBSD 10.0 會是第一個使用 clang 作為預設編輯器的正式版本 (看起來不像會 back port 回 FreeBSD 9)。接下來是 Ports 大混戰了,應該會有一卡車的 ports 用 USE_GCC=yes 來解?

從 2009 年的努力到現在三年多了 (參考「[ANNOUNCE]: clang/llvm can compile booting FreeBSD kernel on i386/amd64」這封公告信),離拔掉 GCC 4.2.1 又進了一大步...

更寮古道健行...

週日一時興起,想起已經很久沒去爬山健行,就在 Ptt 南港板上翻翻資料,後來在台北市政府網站上翻到「更寮古道親山步道」這條看起來不算長的親山步道,早上八點多把東西收一收就跑去爬了。走過一次後發現還有不少支線沒走到,有機會再去補進度...

一開始是從南港展覽館坐車坐到舊庄派出所 (舊庄站),下車後可以看到親山步道的指示牌,基本上沿著指示牌走不會走錯地方。

比較有趣的是,依照市政府網站上的介紹,入山口是在舊庄街二段 122 巷 (如圖),我在門牌前面狐疑了老半天,這看起來就是往民宅啊,走進去還有狗對我叫 XDDD

硬著頭皮進去後看到有石階可以往上走,地面上可以看到起點標示:(確定沒走錯 XDDD)

因為沒有走到頂,而且樹林還蠻密的,沒看到什麼有趣的風景... 加上幹了不少蠢事,其實還蠻累的 XD

下次不帶平常用的包包去了 (裡面放著一台 MBA + iPad 以及變壓器),之後要爬的話弄個空包包,裡面放水就好... 然後山上 3G 收訊不好,Instagram 傳不上去救回家傳吧。

真的是太久沒運動了,肌肉開始抗議... :/

Archives