Category: Database

MySQL 在 FreeBSD 與 Linux 上的效率

之前在 FreeBSD 的 ULE 2.0 提到要拿 測試 的 ULE 2.0，初步的測試結果出爐了：Benchmarking with sysbench.

綠色的是 FreeBSD 7-current CVS 版本，而紅色的是 Fedora Core 6 (沒有說明 kernel 版本)，跑的是 MySQL 5.0.x (也沒有講真正的版本)，所以這份數據... 先看過就好，要有詳細的測試環境資訊才能決定要不要催眠色 far 把 的 換掉...。(對 Fedora Core 比較熟的人可以說明一下 Fedora Core 6 的 default kernel 是 2.4 還是 2.6？)

Jim Gray 失蹤

1998 年因 Database & Transaction Processing 而獲得 的 James N. Gray 搭著小船在 San Francisco 外海失蹤，目前沒有收到求救呼叫，也找不到他的船隻：Jim Gray Is Missing。

在台灣應該有不少人看過 Jim Gary (James Gary) 本人，因為去年 有邀請三位 得主 (、、) 來台灣參加 『21世紀的運算』學術研討會，當時在圓山飯店舉辦。

FreeBSD 的 ULE 2.0

這陣子 在改寫 上的 SCHED_ULE，也就是 。

據他在 ULE cpu selection. 這篇的說法，在 8 core CPU 的 上跑 測試，ULE 2.0 比 4BSD 快了 300%。(不過據下面 comment 的數字，應該是快 200%，30k v.s. 10k)

然後他就想要弄個 出來測試，但他對於 與 的 tuning 不熟，所以就寫了一篇 Linux vs bsd database shootout! Sort of.，希望找到人幫他 tune，結果 魔頭之一 跳出來說他可以幫忙 的部份。

Anyway，很多人都很期待這次的 benchmark，畢竟 發展的重點是在多 CPU 環境 (尤其是 2 core 與 4 core)，而非單 CPU 環境。

之前幫 far ( 站長，很糟糕的學弟 XD) 弄 search 功能的時候就聽到他在抱怨對 不熟，可是不得不在上面跑 ... 我想他應該頗高興的 :p

MySQL 裡的 Falcon

在 把 Falcon Storage Engine 放進 source tree 後 (MySQL Falcon Storage Engine Open Sourced)，有人就在 上跑起來，同時對 MyISAM 與 InnoDB 做了一些簡單的 benchmark：InnoDB vs MyISAM vs Falcon benchmarks - part 1，跑出來的結果是 Falcon 大敗... :p

這陣子的測試都還說不準，要等到把一些整合上的問題修掉後再回來看。

PS：在 Falcon Storage Engine Design Review 這篇有些 Falcon 設計上的解釋，也許可以稍微解釋為甚麼 Falcon 跑起來這麼慢...

MySQL 將不會使用 GPLv3

決定將 MySQL 5.0 與 5.1 的版權宣告從 "GPLv2 或之後的版本" 改成 "GPLv2"，換句話說，避免使用 GPLv3 授權：MySQL Changes License To Avoid GPLv3。

這避免了如果有人拿 的 source code 改出另外一個版本後使用 GPLv3 所產生的問題：如果這個新的版本有很好的功能， 想要 porting 回 MySQL tree 裡時會產生 GPLv3 感染的問題。

MySQL 的使用

參加了在 總部辦的 ，他記錄了一些重點可以參考：MySQL Camp Google Notes。

除了一般簡單的分散技巧外 (所謂的二十六台 密技？:p)，另外還講了使用 master/slave 時應該要注意的問題，以及修改原始程式碼配合極短的 DNS TTL 達到很短的 downtime。

Slashdot 的 Comment 數超過 MEDIUMINT 的限制

在 上看到這則讓人 XD 的報導：Slashdot Posting Bug Infuriates Haggard Admins。

的後端是 ，Comment 都放在同一個 Table 裡面。一開始他們用 MEDIUMINT (224) 來放 Comment ID，在五年前的時候他們改成 Unsigned Integer (232)，但是忘了改 Index 的部分，於是昨天就出問題了...

在 裡把 Index 改好其實也很簡單，只是一個 ALTER 指令，但是在一千多萬筆資料的 Table 裡重建 Index 最少要三個小時，所以只好發一篇文章跟大家道歉，因為為了轉換會關掉一些功能... XD

Database

問個資料庫的問題。現在是否有符合下面這些條件的資料庫：

  • 只要有 (key,value) 即可，不需要到 SQL 那種複雜的架構
  • 可以用多台機器 Cluster，並且有 Replication，不受到單一機器的 Bottleneck
  • 不存在 Single Point of Failure
  • 可線上擴充機器

的 Replication (即 Single Master, Read-only Slave) 最後會卡在 Writing，而且空間的消耗讓人不是很滿意。 的架構仍然有 Single Point of Failure (我想他們應該是用 Layer 4 Switch 或是其他配合硬體的方式解決)，所以我想問的是，有沒有數學方法就可以滿足上面要求的資料庫？

Update：我希望每個 node 都是 1TB，初期大約三十台到六十台機器，以後可以擴充到上千台，每個 key 都會有四份資料放在 DB 裡面。

INSERT ... ON DUPLICATE KEY UPDATE

把放很久的文章整理出來。

在 這裡看到 4.1 之後的版本可以有 INSERT ... ON DUPLICATE KEY UPDATE 這種用法：MySQL Counters。引用的原文在 INSERT ON DUPLICATE KEY UPDATE and summary counters. 這篇。

如果你對於 race condition 有瞭解，你可以在文章裡看到這種用法將本來要自己做的檢查交給 處理：

INSERT INTO ipstat VALUES(inet_aton('192.168.0.1'), 1, now()) ON duplicate KEY UPDATE hits = hits + 1;

這個功能在 4.1 以及之後的版本有提供。