PostgreSQL 提供 apt 可以用了...

在「apt.postgresql.org」這篇文章裡看到 PostgreSQL 宣佈官方 apt repository 的正式公告:「PGDG apt repository for Debian/Ubuntu」。

目前支援的 OS 包括了:

  • Debian 6.0 (squeeze)、7.0 (wheezy) 與 unstable (sid)
  • Ubuntu 12.04 (precise)

其中 Ubuntu 10.04 (lucid) 還正在進行。而 PostgreSQL 的版本從 8.3 到 9.2 (包括了 8.{3,4} 以及 9.{0,1,2} 這五個版本) 都支援。

比較特別的是居然支援 unstable,大概是因為自己要用?

來測試看看好了...

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) 降低人力維護成本。

Percona XtraDB Cluster (Galera Cluster) 的教學

Percona 將在台灣時間 9/20 清晨 (當地 9/19 10:00AM) 舉辦 Percona XtraDB Cluster (Galera Cluster) 的教學:「Upcoming Percona XtraDB Cluster – Installation and Setup webinar」。

這是偏向營運方面的 Web conference:除了安裝與設定以外,還準備試爆與修復,另外使用 HAProxy 達到 HA 目的... (我是偏好 Heartbeat + 自製的小 script 達到 HA)

有興趣的人可以報名,如果時間上不能配合的人,照慣例事後應該也有 video 與投影片可以看... (不是很確定)

又有一家大的 MySQL distribution 支援 Galera Cluster...

Galera ClusterCodership 所提供的 MySQL master-master 方案,與其他 master-master 方案比起來,最大的好處就在於比較不需要擔心資料同步的問題...

剛剛看到,除了 Percona 外,又有一家 MySQL distribution 支援 Galera Cluster:「MariaDB Galera cluster released」。這次是 MariaDB 宣布支援 Galera Cluster。

MariaDB 是由 MySQL 創辦人 Michael Widenius 發展的版本,算是一個蠻有名的分支... 這樣一來 Galera Cluster 應該會有更多人關注使用...

PostgreSQL 9.2 出版...

PostgreSQL 9.2 放出來了:「PostgreSQL 9.2 released」。

其中一個重要的功能是直接支援 JSON 資料型態。之前看到「Building a MongoDB Clone in Postgres: Part 1」與「Building a MongoDB Clone in Postgres: Part 2」這兩篇,用 PostgreSQL 9.2 (當時還在 beta) 去堆 MongoDB 提供的功能。

另外一個對於效能會有幫助的新特性是 covering index,可以避免額外的 disk access。

COSCUP 2012 的投影片:MySQL System Stability

因為大約只有 25mins 的時間,如果用傳統的方式先用 20mins 講,再用 5mins 開放 Q&A 看起來沒講到東西又沒回答到問題。

所以這次打算用不一樣的方式,先放出投影片,準備 25mins 都是 Q&A 的時間。(而且時間是 12:30 結束,提前結束還可以先吃飯?)

請享用...

對 MySQL 的 VARCHAR 欄位使用 INDEX 時可以增加效率的方法...

MySQL 中,如果你有 VARCHAR(255) 這種欄位,不要對直接對這個欄位下 INDEX。因為 key 會以最大長度 255 chars 為固定大小,而非動態決定 (latin1 的時候 1 char 是 1 byte,utf8 是 3 bytes,utf8mb4 是 4 bytes),當資料有 1M row data 就直接吃掉 1MB/3MB/4MB 的空間。

解決方法是利用「index 可以指定只取前面 n chars」這個功能來做,至於 n 要取多少就是要估算了... 在「Optimal index size for variable text in MySQL」這篇把要怎麼做的過程寫得還蠻完整的。

同樣的道理也可以用在固定寬度的 BINARY(16) 系列上。

AWS 可以開超小台 (t1.micro) 的 MySQL RDS 了...

今天看到 t1.micro 也可以開 MySQL RDS 了:「Amazon RDS MySQL Now Starting at Just $19 a Month」。

拿來堆資料應該還不賴?只要 24 小時可以塞完一天的份,而且不會影響到 t1.micro 的 EBS I/O 就可以用?:p

長野雅廣 (Masahiro Nagano) 的 MySQL Beginners Talk

長野雅廣的「MySQL Beginners Talk で LT してきました」這篇 slide 對不熟悉 MySQL 的人講了兩個幾乎不會錯的觀念:

先討論後面這點,算是任何 database 都通用的法則:當你遇到效能問題時,監控機制可以提供毛線球的線頭,讓你知道慢在哪裡:什麼時間滿載 (於是可以猜測是 cron job 造成,或是對應 MRTG 圖時知道是一般使用者造成的流量造成),另外可以知道瓶頸是在 CPU (是單顆 CPU 滿載,還是整台機器都被吃滿),I/O (是讀取滿載,還是寫入造成滿載),或是網路。

前面這點解釋成「如果你不知道你在做什麼,就用 InnoDB Plugin 吧」,對於初學者 (slide 的標題),就簡化成「既然你是初學者,你就用 InnoDB Plugin 吧」。原因是:

  • InnoDB 是 crash safe engine,MyISAM 不是。
  • 常被用到的 table 其實會被 cache 在記憶體內,用 MyISAM 與 InnoDB 差異不大。
  • 最重要的一點是,InnoDB 有支援 transaction (MVCC),在大量寫入時比起 MyISAM 比較不會產生 table lock。由於 InnoDB 支援 transaction,所以功能也比 MyISAM 多。

slide 不長,但這兩個重點還蠻重要的...

花時間看看 PostgreSQL...

雖然工作上都還是用 MySQL,但還是來看看其他的 database... 印象中對 PostgreSQL 最主要的差異 (與 MySQL 相比較) 是在於 index 的彈性...

PostgreSQL 也是個超大的 open source project,所以除了可以到 PostgreSQL 的官方網站找資料外,英文版維基百科上的資料也是對於熟悉 PostgreSQL 的入口:「PostgreSQL - Wikipedia, the free encyclopedia」。

現在 PostgreSQL 最新的 stable 版本是 9.1。依照 Versioning policy 文件,從第一個 major 版本釋出後,提供五年的軟體支援。現在支援的版本包括 8.3、8.4、9.0 與 9.1。另外最近剛出 9.2 beta1,在「PostgreSQL 9.2 Beta 1 Available for Testing」有些說明可以看。

功能面上,除了本來就很強的功能外,內建 Replication 是從 9.0 開始,其中 9.0 與 9.1 分別支援 async replication 與 sync replication,9.2 則是多了 Cascading replication (應該是指串接)。

商業支援則是常常可以看到 EnterpriseDB。有名的用戶包括了 InstagramHeroku

接下來就是實際玩看看...