對 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

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

PHP 長期計畫:廢除 ext/mysql,改用 pdo_mysql 或 mysqli

Hacker News 上看到的長期計畫,要廢除 ext/mysql:「deprecating ext/mysql」。

主要的原因是 security 習慣問題。因為 ext/mysql 不支援 prepare 與 execute 這類不需要自己處理 escape 的函式,所以使用 ext/mysql 的人必須自己處理 escape 的問題,也就是透過 mysql_escape_string 或是 mysql_real_escape_string。而很多書籍為了讓初學者容易了解,會給出很糟的範例,像是:

mysql_query("SELECT * FROM `user` WHERE `username` = '$username';");

$username 沒有先檢查過。

依照提議,目前只會在文件上建議改用 PDO 或是 mysqli,不會對目前版本有任何改變。接下來是 5.5 與 6.0 時會看情況決定要不要加上 E_DEPRECATED

目前的提議還沒有提到何時要拔掉 ext/mysql,不過看起來 6.0 之前應該是不會做...

MySQL HandlerSocket 的情況...

前幾天 jnlinOSDC.TW 2011 上面講了「HandlerSocket – A NoSQL Plugin for MySQL」,剛好 Percona 的 Ryan Lowe 也提到了「What’s up with HandlerSocket?」,試著分析 (並猜測) HandlerSocket 為什麼沒有被廣泛使用。

除了技術的問題外,最主要在於運作:Open Source 不是把程式丟出來就覺得沒事了,要僅可能讓使用者容易使用。

比較好運作方式是在重大的 bug 修掉之後就推出 minor version release,一方面讓一些願意整合的單位有「基準」可以整合 (像是 Percona 這樣的公司),另外一方面可以讓 community 感覺是個有在動的 project...

像是文章裡提到的兩個 bug,一個在今年年初已經修正 (write invalidate),另外一個大約兩個禮拜前修正了 (insert auto-increment),只是很多人不太清楚而已。

目前這個專案的感覺跟 Facebook 丟出來的 memcached 還蠻像的:「facebook / memcached」,Facebook memcached 的情況是很明顯「老闆說要 open source,我就丟出來吧」的感覺,原來的 community 也懶的理他,看一看有沒有可以用的 code 可以整合,然後繼續發展自己的...

AWS RDS 的 INSERT 效能...

PerconaBaron SchwartzAWS RDS 能提供最大台的 database (68GB memory + 26 ECUs) 上測試 insert 的效能:「MySQL on Amazon RDS part 1: insert performance

數字是 Per Minute,換算成常用的 Per Second 要記得除以 60。大約是 4k~5k 40k~50k queries/sec 的數量。這個效能不知道能不能算「好」...

Pinboard (書籤網站) 被 Yahoo! Sunset 影響的情況...

雖然現在跑到台東玩,不過還是趁著在民宿休息的時候來寫一些東西好了...

剛剛看到 Pinboard 寫了一篇關於去年 12 月時 Yahoo! 內部簡報被流出時 (參考去年寫的「Yahoo! 要關閉 Delicious」) 所帶來的流量,以及對他們的影響:「Anatomy of a Crushing」。

裡面包括了架構,兩台 DigitalOne 的 server 當作主力,以及一台 ServerBeach 的 server 當作 slave (看起來是順便當作異地備份以及一些雜物服務):

另外也提到了 MySQL 的 varchar index 的老問題...

用 Plack 提供的 CGI 跑 Adminer...

在「用 Plack 跑 CGI」提到用 Plack 跑 CGI,目的是把 PHP 寫的 Adminer (一個取代 phpMyAdmin 的工具) 跑起來。

文章裡提到 PHP 沒辦法以 CGI mode 執行,主要有兩個原因。一個是 PHP 本身有安全機制,php-cgi 必須在有 REDIRECT_STATUS 這個環境變數下才能執行,另外一個是 php-cgi 需要用到 SCRIPT_FILENAME 這個非 CGI/1.1 標準 (RFC 3875 - The Common Gateway Interface (CGI) Version 1.1) 的環境變數。

由於我只打算跑 Adminer,而 Adminer 的程式都放在同一個檔案裡,所以可以把這兩個環境變數設死惡搞:

env -i REDIRECT_STATUS= SCRIPT_FILENAME=/path/adminer.php /usr/local/bin/plackup -MPlack::App::CGIBin -e 'Plack::App::CGIBin->new(root => "/path")->to_app'

這樣就跑起來了...

MySQL 5.5 GA (General Availibility)!

Oracle 的公告:「MySQL 5.5 is GA!」,以及 Oracle 的新聞稿:「MySQL 5.5 Now Generally Available」。

MySQL 5.5 比起之前的版本,除了 InnoDB 的改善以外,最重要的是 Semi-Replication 成為內建功能,這個功能使得需要 Read-after-write consistency 的 query 可以不用強制綁在 master 上做...

對於開發者,MySQL 5.5 把本來用的 autotools 換成 CMake 了:「MySQL 5.5: CMake replaces autoconf/automake on all platforms, support for autotools has now been removed」。

接下來就等 Percona 出對應的版本了...