Home » Computer » Software » Archive by category "Database" (Page 45)

Zend Framework 的 Zend_Db

這個週末都在研究 的用法,然後套用到新的系統上。

的三個架構裡,Controller 透過 .htaccess 配合,效果還算可以。View 目前是用 ,不過會看情況改用 或是 ,基本上都沒什麼問題。

最大的問題在於 Model: 的功能看起來很多 (在說明文件的份量裡,算是相當厚的一個模組),但實際上有不少缺陷沒辦法光靠 Zend_Db 目前內附的模組解決,需要自己寫 Adapter 處理。在沒時間研究 Zend_Db 的 Adapter 怎麼寫的情況下,只能先把他當作非常小的 使用。

Zend_Db 主要的兩個問題是:Master-Slave 時讀寫必須分開,以及多台時 Failover 及 Load sharing 的處理。雖然這兩個問題都可以用 解決,但我不是很喜歡 MySQL Proxy 的解法,所以...

Anyway,目前該解決的都解決掉了,如果有遇到其他的模組不好用,我再寫文章抱怨好了... XD

Mtron SSD 硬碟

昨天 Mtron SSD 硬碟 3.5" 32GB*2 終於到了,上線後測試發現與之前的 SSD 硬碟完全不同,以 MySQL 的啟動時效率來看,足以殲滅 15KRPM SCSI*4 (RAID10)。(剛啟動時因為 key buffer 還沒有 cache,會需要一段時間速度才會慢慢上來,在 15KRPM 的 RAID10 SCSI 上需要幾分鐘,但 Mtron SSD 幾乎不需要 slow start)

其他的就不多說了,目前是 jnlin 在測試,請參考他寫的「Mtron SSD 在 MySQL (MyISAM) 上跑了兩個小時」這篇,之後應該會有一些數據可以看。目前已經是卡在 CPU bound 了,接下來要期待 Jeff Roberson 對於 FreeBSD 上 pthread_rwlock 的改善。

Ref:「MySQL 在創見 SSD 上跑的情況

一些雜記

如果 bug 愈找愈久,代表那個 bug 一定很笨 XD

像是今天一整天跟 ronnywang 在找一個 Zend_Db 會爛掉的 bug,最後發現是因為 PDO_MYSQL 沒裝... XD

愈來愈多關節打通了,接下來就來衝吧...

缺乏 Model 支援的 Zend Framework

Zend Framework 前陣子釋出 1.5.0 正式版了,與 1.5.0-RC 系列沒有太大差別,所以沒支援的還是得自己想辦法。

Controller 的部份,Zend_Controller 沒什麼問題,最基本的配置方式都已經摸熟了,也覺得算是還蠻好用的。

View 的部份,Zend_View 畢竟是 PHP 語法,看起來就不太討喜,加上我們是使用 Google cTemplate,其實以目前狀況算是還不錯,要另外再學一套的話要先考慮好處夠不夠足以換掉。far 最近在研究這方面,而我則是想使用 Smarty。但不管是哪種方案,View 的部份看起來沒什麼問題。

真正的問題在 Model,你可以在 Zend Framework 的文件裡面看到 "models" 的目錄配置 (像是在 Using a Conventional Modular Directory Structure 裡),但實際上 trace code 發現沒有對 model 支援。如果你自己寫了一個 Model 放到 models 裡,也沒有很方便的方法讓 Controller 裡的 code 使用,目前我想到的 dirty work 是 require_once(dirname(__FILE__) . '/../models/UserModel.php')

有誰用 ZF 開發有遇到同樣問題的嗎?

MyISAM 在 FreeBSD 上效率不好的原因?

Jeff Roberson (也就是目前 FreeBSD 上 SCHED_ULE 的維護者) 的 blog 上說了這樣的話:(原文章連結)

MyISAM performance is terrible in FreeBSD 7.0 due to the user-space pthread_rwlock implementation. Just a word of warning if you intend to deploy a database server based on 7.0. I am certain we will have this fixed in 7.1. It will most likely be in CURRENT in a week or two.

所以不是我在「FreeBSD 上的 MySQL 效率」這裡想的 Filesystem I/O 問題?來等 Jeff Roberson 的 patch 吧...

Twitter

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

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

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

FreeBSD 7.0 的 SCHED_ULE 長期觀察下來 (超過兩個月) 算是相當穩定,這點在目前 PIXNET 的 Web Server 端可以看出來 (在 FreeBSD 跑 apache22 event 是使用 threading,配合 FastCGIPHP),但 gjournalZFS 在效率以及穩定度上都還不堪使用。(指 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,就讓 jnlinDebian 上跑 MySQL 5.1 測試 MyISAM 的效率,測試的結果相當慘,寫入的速度在個位數 qps (對... <10 query per second),而且不是模擬資料,是 Real Data 的 Replication Update...

測過的 Filesystem 包括 ext3XFS,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,這個部份還要到其他機器看看到底是怎麼一回事...

Archives