Category: Database

Twitter

最近很少寫 Blog (程式沒寫幾行，倒是一堆行政上面的事情)，不過 Twitter 上倒是常常念。

最近忙一些事情，像是寫不完的採購簽呈 (還好有一部分交給 slzzp 了)，然後是開不完的會，如果要抽時間寫程式的話，就得在一般人下班後才有空了...

不管怎麼樣，最近看 jnlin 玩，以及我自己玩一些東西，有些有趣的想法，寫下來紀錄起來。

FreeBSD 7.0 的 SCHED_ULE 長期觀察下來 (超過兩個月) 算是相當穩定，這點在目前 PIXNET 的 Web Server 端可以看出來 (在 FreeBSD 跑 apache22 event 是使用 threading，配合 FastCGI 跑 PHP)，但 gjournal 與 ZFS 在效率以及穩定度上都還不堪使用。(指 heavy I/O)

MyISAM 的讀取速度非常快，但不利於大量 Update (因為寫入的動作需要 table lock)。在國外的討論裡，一般都是推薦使用 InnoDB 解決這類 table 的情況，但實際上目前 InnoDB 的備份問題比起 MyISAM 麻煩 (經驗也是一個大問題)，這點可能還要再考慮。

要解決 table lock 的問題，另外一種方式是透過拆 table，而且目前看起來拆 table 撐 performance 的方式似乎相當可行 (在概念上，這是一種 HyperDB 的變形)，所以最近應該會對這個方向大量研究。不過就得做不少 Denormalize 的事情，還是得累積經驗...

如果有想到其他值得提的事情再寫好了...

MySQL 在創見 SSD 上跑的情況

最近進了四顆創見 SSD MLC 顆粒 32GB 硬碟 (連結應該沒錯) 跑 RAID 1+0，就讓 jnlin 在 Debian 上跑 MySQL 5.1 測試 MyISAM 的效率，測試的結果相當慘，寫入的速度在個位數 qps (對... <10 query per second)，而且不是模擬資料，是 Real Data 的 Replication Update...

測過的 Filesystem 包括 ext3 與 XFS，block size 也調整過好幾次，RAID 1+0 的部份是軟體做，這部份的 block size 也調整過，不過不管怎麼測，速度都還是上不去。

在 Mtron SSD 硬碟還沒有開始在台灣代理之前，用一堆 RAM 加上 15K RPM SCSI 硬碟做 RAID 1+0 比較便宜，而且也比較穩定...

Update：我要求 jnlin 將測試的想法丟到網頁上，現在可以在他的 blog 上看到了：「MySQL 在創見 SSD 上的測試」。

memcachedb

memcachedb 是以 Berkeley DB 為 backend 的 memcached-compatible server。

memcached 一開始是 LiveJournal 以大量的 memory 作為 cache 加速用。除了 Perl 本身外，後來在各平台上都有對應的 library 可以用，而且也被證實他的效果很棒，Facebook 甚至弄了兩百台 16GB 的機器來跑 memcached。

最初的版本有一些架構上的問題，像是最原始的 memcached 是先計算 key 的 CRC32，再算餘數而決定是哪一台機器。這使得新增或移除機器時，會造成整個 cache 大洗牌，後來引入 Consistent Hashing 後就解決了，而且 Consistent Hashing 的觀念並不難懂，很多 memcached client library 都有實做。

另外是 cache server 重開後會因為要重新計算，會有一段時間網站變慢，Wikipedia 裡有人試著改了一個以 Berkeley DB 為底層的版本，後來不知道什麼原因又改回 memcached 了。

現在這個 memcachedb 是以 Berkeley DB 4.6 為基礎，利用 BDB 提供的 Replication 提供高可靠度，並想辦法維持相同的效能。另外，因為使用 Berkeley DB，所以 disk 也被當作 storage，也希望可以利用更大的空間提高 cache hitrate。

不過有些地雷還是要注意，如果有要使用的人，應該要訂 mailing list 看上面的討論。目前最常遇到的地雷是可以接受的 key 與 value 的長度異常的小，我在 porting 0.0.x 版到 FreeBSD ports 時有把 key 修正到 128bytes (原來是 16bytes)，不過這點在 1.0.0 beta 應該修掉了，因為我在更新時翻過 header file，裡面沒有再看到這個限制，不過使用上可能還是要注意一下。

另外 memcached 原作者 Brad Fitzpatrick 似乎對於 Berkeley DB 版本的效率感到好奇，有跟 memcachedb 的原作者討論一些架構上的想法，也許這兩位會擦出什麼火花...

MySQL Falcon 的一些事情

在 ZFS 上順便測了一下 MySQL 6.0 (以 6.0.3 版測試) 的 Falcon Engine，紀錄下一些東西：

  • Falcon 與 InnoDB 類似，以一組檔案儲存資料庫的檔案，所以不太容易備份，不像 MyISAM 有 mysqlhotcopy 可以用。
  • 寫入效率上相當差，即使開了 falcon_disable_fsync=1 還是很慢，以四個 client 倒資料進去，寫入速度約 MyISAM 的 1/10 ~ 1/20，以一個 client 倒也是一樣的情況。瓶頸不在 CPU (800% 的量大約用掉 2%) 與 I/O (以 gstat 看約 50% busy)，暫時還看不出問題。
  • SELECT 的最佳化似乎有問題，對有 index 的 column 下了幾次有用到 ORDER BY 的 simple query，看反應速度很像 table scan，但 EXPLAIN 出來的結果都顯示有使用 index。

Replication 與 Transaction 暫時還沒測，也許應該先測 PBXT Engine...

FreeBSD 上的 MySQL 效率

測試的結論是，FreeBSD 現在缺乏穩定而且高效率的 Filesystem 讓 MySQL MyISAM 使用。

先解釋一下現在的環境，有兩台 Tyan Server，上面都是 Dual Quad Core 與 12GB RAM (6*2GB)，接兩顆 73GB SCSI 硬碟，兩台的差異在於 CPU，新進的這台是 E5410 (2333Mhz，2*6144KB L2)，舊的是 E5320 (1866Mhz，2*4096KB L2)。

舊的是目前 PIXNET production 的 MySQL database，跑 Debian/amd64，kernel 是 2.6.22，檔案系統是 XFS。另外一台則是前陣子另外進的，裝了 FreeBSD/amd64 7.0-BETA2，然後透過 make kernel & make world 升級到 7.0-PRERELEASE，跑 SCHED_ULE，檔案系統是 UFS2。依照慣例，noatime 與 nodiratime 之類的參數都會設上去，兩台都是跑 MySQL 5.1.22-rc，都是 MySQL slave。

要複製 slave 很簡單，把 production 停機 (利用使用者比較少的時候，其他的 slave 會負責這台本來的事情)，整個目錄複製一份到新的 FreeBSD 上，改 server_id 後跑起來後 MySQL 會跟 master 更新。

然後用 databases/mytop 看 replication delay 的情況 (原版的 mytop 沒有這個訊息，這是 FreeBSD ports patch 的功能)，發現即使是放著跑 replication sync，某些時候 UPDATE 的速度反而會跟不上 master，跟不上時的 I/O 是滿載的 (透過 gstat 看的)

目前測過最好的情況是這樣跑：gstripe -s 16384 將 da{0,1} 串起來，用 async + noatime。其他的情況包括：

  • gstripe -s 16384 + gjournal + async + noatime：日誌類的 Filesystem 在 DB 這類用法的速度不會提昇，與預料的差不多。
  • gstripe -s 16384 + soft updates + noatime：畢竟要維持 consistent，速度慢一些。
  • 單顆硬碟 + async + noatime：也如同預期的，速度只有一半...

以效率來看，短期內還是會跑 Debian/amd64 養 MySQL...

另外補充一點，本來是在開啟 gjournal 的情況下用 rsync 把資料複製到本機，結果發生 kernel panic，後來是先複製完再使用 gjournal，這個部份還要到其他機器看看到底是怎麼一回事...

Twitter 離開 Joyeur

今天最大的新聞應該還是 Microsoft 向證交所提出併購 Yahoo! 要求的新聞，不過這種事情也只能看他變化，然後依據變化決定在台灣要怎麼因應。

另外一件事情是 Twitter 離開 Joyeur，搬到 NTT America，也就是說，Twitter 將來會自己建立整個網站的底層。可以預期的是，他們會遭遇到一堆問題，然後想辦法解決，然後再遭遇到其他問題，再想辦法解決，然後發現需要在 Application 層將 MySQL 拆開...

這個轉換的動作應該還會有一個月，或是更久的陣痛期吧...

Ref：Twitter Chooses NTT America Enterprise Hosting Services。

用 SSD 當作 MySQL 的儲存空間

Update：原作者拿到硬碟後測試了一天，發現寫入速度不盡理想：24 Hours with an SSD and MySQL。

SSD 硬碟應該要列入耗材...

國外有一些先驅已經在測試把 MySQL 的 data 丟上去跑：Thoughts on SSD and MySQL 5.1，這篇裡建議把 sync_binlog 與 innodb_flush_log_at_trx_commit 保留預設打開的狀態 (用 InnoDB 時，如果為了效率會把這兩個都關掉，尤其是後者，有寫入動作時的速度 (INSERT/UPDATE/DELETE) 會差十倍到三十倍)，不過我覺得為了減少 I/O 還是要開。另外在 OS Filesystem 層的參數也要注意。

寫這篇才想到 FreeBSD 7.0 有 iSCSI 可以測試，來測看看效率...

最近的幾件事情...

累積太久沒寫，有些議題剛好可以合併起來看...

第一個想到的是 被 買下，以及在 上看到有人認為 的 成功是 Computer Science 界的一大退步 ()。

把時間點再往前，拉到 買下 Innobase Oy 及 (Berkeley DB) 兩家公司時一般的反應 (分別是 2005 年十月、2006 二月)，以及買下後的進展...

買下 Sleepycat Software 後推出的 Berkeley DB 4.5 多了 Replication 的功能，並且在 Berkeley DB 4.6 對穩定性及大幅度修正。InnoDB 則是不斷的改進穩定度及效率，仍然是目前 MySQL 裡最常被使用的 Transactional Engine。以現在看起來，其實 Oracle 並沒有打算要以這個手段打擊 MySQL。

話題回到 Slashdot 那篇 MapReduce，其實在 comment 有人講得很清楚了：簡單的東西並沒有什麼不好，重點在於能不能解決問題。如果能用簡單的方法解決問題，就不要拿複雜的方法解決，25 年前就發展出的技術並沒有什麼不好。

另外我提一下，最近寫過後才發現 Berkeley DB 其實相當好用 (支援 Transactional Operation 及 Replication)，沒人用的原因是 PHP/Perl/Python/Ruby 上的 Library 都沒有把實做所有的功能，目前只有標準的 dbm operation 而已。換句話說，如果你要用這些好用的 Operation 得自己刻 C/C++/Java。由於開發上的問題，很多人寧可用 MySQL 放...

由於 Berkeley DB 看起來很棒 (傳言 與 的使用者資料都是用 Berkeley DB 為底層架起來的)，初期的目標是希望有個 Reliable DBM-style Database，類似 的軟體放使用者資料，透過 TCP connection 與 PHP 端溝通...

Firefox Extension for Amazon EC2

在 上看到 這個好用的工具，在 上裝起來測試後發現相當好用，如果要拿來推廣相當棒，不用自己再用 的 操作半天...

PS：剛剛注意到 boto 的作者參與了 的 beta testing，在正式公開那天把 SimpleDB 的 library 加進去了，可以寫一些小玩意測試看看...

Amazon SimpleDB

睡眼惺忪的打開 就看到 又在亂丟炸彈了...

是 以 為基礎的另外一個服務，把 最缺的一塊，Database，補起來了。

不同於 RDBMS (像是 SQL)，SimpleDB 做的事情很簡單，除了 key-value 的儲存以外，另外還可以存放 attribute，並對 attribute 設定條件搜尋，在官方說明文件 裡就有列出搜尋的條件式，可以看到只支援簡單的 >、<、=，以及 NOT 條件，另外可以對多個結果取交集。其實有這個系統就已經可以架一個 Blog 了。

不過還是有容量上的限制 (不像 那樣)，這可能是因為還在 Beta 的關係。在 的頁面裡提到了一個 domain 只能有 250 million attribute，以及 10GB 的資料大小限制。這些必須想辦法在 Application 層自己處理。