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

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?)

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 裡面。

Archives