甲骨文NoSQL數(shù)據(jù)庫第一印象
對NoSQL的先行者而言，甲骨文推出NoSQL數(shù)據(jù)庫可以被解讀為：“模仿是最真誠的贊賞”。
過去幾年間，NoSQL數(shù)據(jù)庫領域充滿了令人興奮的新項目、雄心勃勃的聲明，當然也有盲目的自信。NoSQL的支持者稱，通過拋棄傳統(tǒng)的結(jié)構(gòu)和偏執(zhí)的三次檢測，新的NoSQL軟件包可以提供大量性能優(yōu)勢。那么可靠性呢？即便是那些并不是為華爾街銀行運行重要業(yè)務應用，而只是處理人們生活中瑣碎而易忘數(shù)據(jù)的新程序員也認為，NoSQL的可靠性被高估了。表結(jié)構(gòu)呢？它們又過于死板且局限性太大。如果我們忽略這些事情，我們的數(shù)據(jù)庫將更為自由，并且速度更快。
但是在熱情消退，人們開始正視現(xiàn)實。NoSQL數(shù)據(jù)庫的無邊界實驗慢慢的開始回歸現(xiàn)實。正在這時，甲骨文這個一貫開發(fā)***SQL數(shù)據(jù)庫的專家?guī)砹怂腘oSQL數(shù)據(jù)庫服務器，而這個新的數(shù)據(jù)庫秉承了甲骨文一貫的堅固、實用，標準的開發(fā)風格。盡管狂熱的夢想家能夠繼續(xù)創(chuàng)建NoSQL數(shù)據(jù)倉庫，但是務實的人希望能夠看一下甲骨文的版本。因為它提供了許多功能，這些功能夠讓NoSQL非常有趣，同時也符合嚴格的大型工程的手筆。NoSQL的先鋒們希望告訴他們自己，模仿是最真誠的贊賞。
甲骨文NoSQL數(shù)據(jù)庫的出現(xiàn)絕對讓NoSQL粉絲感到吃驚，因為他們經(jīng)常聽到資深的數(shù)據(jù)庫工程師在自豪地談論甲骨文數(shù)據(jù)庫。不過，甲骨文已經(jīng)悄悄的在NoSQL數(shù)據(jù)庫這條路上走了一段時間了。五年之前，甲骨文收購了開源伯克利數(shù)據(jù)庫（BerkeleyDB）的開發(fā)商Sleepycat，為C語言和后來的Java程序員提供了靈活的鍵值存儲。而Berkeley DB的技術據(jù)說就是甲骨文NoSQL數(shù)據(jù)庫的核心，雖然看上去像是被完全重寫了一遍。
甲骨文NoSQL：實用的ACID
甲骨文NoSQL數(shù)據(jù)庫最有趣的地方就是它的鍵值結(jié)構(gòu)。你不需要再去定義大綱，或者把自己鎖在表結(jié)構(gòu)中。你只需要創(chuàng)建關鍵字，然后把數(shù)據(jù)關聯(lián)給它們就可以了。你可以給關鍵字連上一個字符串，也可以連上一個圖像文件。什么都可以，數(shù)據(jù)庫接受字節(jié)碼，不去理會內(nèi)容是什么。
甲骨文把關鍵字分為主次兩個部分，你可以認為主部分是對象的指針，次部分是記錄的各種字段。例如，你可以把姓名和社會保障卡號放在主部分里，把住址和郵編等等其他的字符串放在次部分里。這和一些NoSQL數(shù)據(jù)庫工具使用一個對象多個字段的做法不同。
甲骨文NoSQL數(shù)據(jù)庫中重要的地方是針對ACID遵從而做的近似工程，這讓甲骨文NoSQL達到了SQL數(shù)據(jù)庫所能夠提供的嚴格標準。ACID的意味著事務所具備的四個特性：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation，又稱獨立性）、持久性（Durability）。
不過，目前對于如何解釋其具體含義還存在著很大的爭議。而大多數(shù)的NoSQL系統(tǒng)走的是另一條路：BASE，即基本可用（Basically Available）、軟狀態(tài)（Soft State）和最終一致性（Eventually Consistent）。換句話說，你可能會得到正確的答案，除非你不做。關于甲骨文NoSQL數(shù)據(jù)庫是否真正提供ACID遵從還有不少爭論，但甲骨文NoSQL數(shù)據(jù)庫確實可以做出這樣的承諾。
***爭論：最終一致性
耶魯大學計算機科學教授Daniel Abadi在博客提出了自己的質(zhì)疑。他說，在某些情況下，甲骨文NoSQL數(shù)據(jù)庫向主服務器寫入的關鍵字匹配會丟失。比如在主服務器宕機，同時備份服務器又沒有準備好的情況下。
很快，哈佛大學計算機科學教授Margo Seltzer就最初了回應。Seltzer現(xiàn)在是甲骨文的員工，她參與創(chuàng)建了Sleepycat。Seltzer認為這并不是甲骨文NoSQL數(shù)據(jù)庫的問題，如果要達到真正意義上的“最終一致性”，數(shù)據(jù)中心需要在準備好備份服務器的前提下才開始寫入數(shù)據(jù)。而可以想見的是，要讓這一爭論有個最終結(jié)果是非常困難的。
為了測試甲骨文NoSQL數(shù)據(jù)庫的速度，我們進行了如下測試：在一臺低端的Mac計算機上開啟了單點NoSQL服務器，然后往里面塞入358400條關鍵字，都是長度大約30的字符串。在這臺老掉牙的Mac電腦上，甲骨文NoSQL數(shù)據(jù)庫共用了119秒的時間。比較而言，把相同的記錄插入***版的Voldermort數(shù)據(jù)庫，在這個LinkedIn癥狀使用的開源Java NoSQL數(shù)據(jù)庫上，耗時為180秒。
如此看來，甲骨文NoSQL數(shù)據(jù)庫似乎領先不少。創(chuàng)建關鍵字需要建立字符串數(shù)組，而對象的實例化經(jīng)常成為Java的瓶頸。在這一測試中，甲骨文NoSQL數(shù)據(jù)庫似乎沒有碰到這方面的問題。
總體而言，甲骨文NoSQL數(shù)據(jù)庫值得一試。因為它提供了許多嚴謹?shù)墓δ?，又是來自這樣一家嚴謹?shù)臄?shù)據(jù)庫廠商。在許多方面，與簡單的NoSQL工具相比，甲骨文NoSQL數(shù)據(jù)庫的設計相當周到并且精巧。此外，當面臨節(jié)點崩潰，或是面臨要速度還是持久性的問題時，你還有許多選擇，這些選擇都可以增強持久性。文檔具有一致性，它們由在企業(yè)客戶數(shù)據(jù)存儲方面擁有豐富經(jīng)驗的工程師所編寫。
甲骨文NoSQL數(shù)據(jù)庫可能不會提供令人興奮的趣味性，以及許多純開源NoSQL項目所具有的“隨意創(chuàng)建”體驗。不過，這并不是它的真正用處。甲骨文從這些團隊那里借鑒到了***的理念，創(chuàng)建了能夠向企業(yè)市場最適當?shù)牡胤教峁└研阅艿臄?shù)據(jù)庫產(chǎn)品。
原文鏈接：http://www.cnw.com.cn/software-open-source/htm2011/20111129_238323.shtml
【編輯推薦】
