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