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 層自己處理。

MySQL 在 NetBSD 上的效率說明

MySQL 在 NetBSD 上的效率 這篇提到的效率差別已經確認是 7-CURRENT 的 malloc() debugging code 所造成,拿掉以後就接近了:Re: Thread benchmarks - FreeBSD corrections

這兩張圖分別是 / 的 SCHED_4BSD 與 SCHED_ULE/SCHED_MSVR 效率差異:

MySQL 在 NetBSD 上的效率

參考:Thread benchmarks,因為 被廣泛應用,所以大家都拿他當作 Thread/Lock/... 的實際效率測試指標。

這個測試結果顯示 輸了一屁股,一定會讓 src committer (大光頭與 Jeffrey Roberson?) 測試 在 AMD64 上跑 的效率,這陣子應該可以在 的 mailing list 上看到相關的討論...

InnoDB 的重大修正

MySQL InnoDB 的 auto-increment 會造成 INSERT 時使用 table-level lock 的 bug 終於修正 (從 2006 年一月就進 MySQL 回報系統的 bug),下個 5.1 的版本 (預定是 5.1.22) 就會包括在裡面:InnoDB auto-inc scalability fixed

這個 bug fix 目前介紹了新的變數:innodb_autoinc_lock_mode,目前有三個數值可以用:

  • 其中 0 是原來的 table level lock 架構 (主要是因為其他原因而需要升級到 5.1.22,但是又不想上這個 patch)。
  • 1 是預設值,在 simple insert 時會改用新的 row level lock,但 bulk insert 時會使用新的 table level lock (要與 row level lock 配合)。
  • 而 2 目前不保證在 statement-based replication 下能夠正常運作 (預設是 statement-based + row-based 混和使用),但現在用 不搞 replication 的很少了吧 :/

無論無何,這是一個重大修正,在大量 INSERT 卻不能 bulk 時會造成的問題終於解決了。雖然最近我都用 開發... XD

WWW SQL Designer

上看到這個用 JavaScript 做出來的介面,拿來畫 SQL 關係圖還不錯:

要注意的是他產生出來的 SQL 指令並沒有把 FK 放進去 (至少 都是),所以畫完後要自己轉成 SQL CREATE TABLE 的指令。雖然如此,但對於拿來釐清一些複雜的架構還不錯...

HyperDB

的 Blog 看到 所使用的 MySQL Database Partition 及 Replication 程式碼 (在 app 層實做):

程式碼不長,在 http://svn.wp-plugins.org/hyperdb/trunk/ 可以看到他把許多 function 包成一個 class,另外有剛成立的 可以參與討論。

不過切 Server Farm 之後要做一些比較特別的 JOIN 就沒辦法做了。另外 Blog 本身也比較單純,可以透過 BlogId 切 Server Farm。

MySQL 5.0.37 的 semisync patch

先前 放出 4.0.x 的 patch,並且放出會做 5.0 patch 的消息,本來以回要等上一陣子的,結果剛剛在 Semi-sync replication for MySQL 5.0.37 這裡看到 semisync replication 的 patch 已經在 trunk/ 裡面的消息了,這個 patch 目前指支援 ,不過據他的說法,應該蠻容易 porting 到別的 storage 上:mysql-5.0.37_semisync.patch

另外在 Wiki 上也註明了:

PS:不知道前陣子 幹的事情的人,請參考 寫的兩個 MySQL 的舊「新」聞

PrimeBase XT Storage Engine for MySQL

上的另外一個支援 Transaction 的 Storage Engine。

上對 進行了一番測試,主要的比較對象是

除了 SELECT BETWEEN 的部份有些問題 (看起來是 lock 的問題,只能用到一顆 CPU 的資源) 而輸了不少外,其他的部份看起來都不錯。整體看起來比 好,不過並沒有好到有強烈的慾望換掉 :o

買下 後,不知道會不會又出手買這些公司 XD (如果真的這樣做,陰謀好像很明顯...)