今天看到一個文章，談到Berkeley DB與eXtreamDB的性能對比，可惜兩者的數據集不同，沒多大可比性，以後有時間，我把那個程序修改一下，使用相同的數據集對比下，把結果貼出來給大家看看。我很有信心：Berkeley DB不會輸給eXtreamDB. 看了官網才發現，eXtreamDB是如此的與Berkeley DB相似，但是它不是開源產品，所以從使用者的規模來看，我相信無法與Berkeley DB相比。
聰明的公司會發現，現在開源不僅僅是被迫而爲，而是一種競爭優勢，開源和雙license 讓Berkeley DB受益匪淺。上OTN你會發現在免費使用Berkeley DB的人非常多，Oracle公司收購了Berkeley DB後，也很支持開源社區，不僅有專門的支持工程師在線回答基礎的使用問題，我們很多同事包括我自己都時常上去回答一些免費用戶的問題，常常涉及到複雜功能的用法、性能調優、bug報告、feature請求，等等。 這樣，我們可以清楚地知道用戶需要什麼樣的產品，當前產品有什麼樣的長處和短處，於是可以清晰地把握產品的發展方向，保證了每一個Release新出來的產品總是有不少人想要的；這一大批用戶偶爾報告的一些bug，特別是出現在一些罕見的平臺上面的，或者在極端情況下出現的bug報告，是極其珍貴的，雖然有時候會讓組內若干個人忙乎好幾天，但是對於產品品質的提升是非常有益的，而且我們都很樂此不疲。
例如9月份AL公司報告的那個bug就屬於這種情形。那次，起初用戶很着急，因爲產品馬上要發佈，於是我們趕緊研究解決方法，及時給用戶提供瞭解決方法。然後，用戶已經有了我們提供的Workaround，沒那麼着急了，但是我們比他們着急，想要找到問題的癥結來解決問題，所以組內的高手紛紛追着用戶瞭解情況，懇請他們仔細描述問題，reproduce bug(因爲我們使用相同的機器和系統和配置並沒有重現問題)，並把bug出現時候的Berkeley DB的各種狀態報告結果送給我們，等等。最終我們找到了問題的原因---沒有完整地使用Solaris系統的新的版本的多CPU時的並行控制功能---並解決了該問題。
類似這樣的例子還有很多，從源代碼註釋和內部SR歷史中，我就曾經注意到好幾個這樣的例子。有的用戶會在閱讀源代碼的時候發現一些不影響程序正確性的文字性錯誤並OTN上面給我們指出，也是讓我們很高興而欣慰的，一是有這麼認真的用戶在關注、使用Berkeley DB，二是我們的源碼有不少人有興趣閱讀。當然，這也提醒了我們，每一行代碼都要認認真真寫，不止關乎正確性、可讀性----還有很多人在看着呢，呵呵。
有無數開源用戶在真實使用環境和真實用例下的測試的幫助，我們才得以不斷地完善產品，使它最貼近和滿足實際用戶需求。我想這是包括Berkeley DB在內的優秀開源產品可以如此成功的重要原因。
下一篇我會說說我從Berkeley DB源代碼中的所學和感受，以及對計算機專業學生、新入行的軟件工程師的建議。
下面是那篇文章的鏈接，有興趣的可以改一下程序，做個性能測試，把結果貼出來 ：）
http://blog.csdn.net/johnlya/archive/2006/05/20/747089.aspx