持續(xù)性：備受爭議
耶魯大學(xué)計(jì)算科學(xué)系教授丹尼爾.阿巴迪的博客引發(fā)了有關(guān)最終持續(xù)性的爭議。阿巴迪指出在某些情況下，寫入到主關(guān)鍵值的新配對可能會在主關(guān)鍵值被切斷后丟失。美國哈佛大學(xué)計(jì)算機(jī)科學(xué)教授，同時也是甲骨文的員工馬格.賽爾查則持不同的觀點(diǎn)。她加入了被收購的Sleepycat公司。
賽爾查認(rèn)為一切都要取決與你對“最終持續(xù)性”的理解。數(shù)據(jù)庫所有者會選擇利用他們對持續(xù)性協(xié)議的機(jī)會。如果所有者希望確保一個配對不會丟失，他們必須所有寫入的數(shù)據(jù)要等到所有副本被升級以后。
為了測試甲骨文NoSQL數(shù)據(jù)庫的速度，筆者采用給了一種低端測試，將更多的壓力放在數(shù)據(jù)庫引擎上而不是網(wǎng)絡(luò)上。筆者從單節(jié)點(diǎn)NoSQL服務(wù)器開始，然后嘗試了358400個關(guān)聯(lián)到關(guān)鍵值的關(guān)鍵值（恰紅包含了大約30個字符的串），在老型號的Mac計(jì)算機(jī)上的速度是119秒。使用小容量隨機(jī)存儲器的老型號設(shè)備是測試有限資源下性能的一種方式。
作為對比，筆者有同樣的配對測試了Voldemort的新版本，這是一款來自于Linkedln的用JAVA開發(fā)的開源NoSQL數(shù)據(jù)庫。在同款設(shè)備上花費(fèi)了180秒。
由于在甲骨文NoSQL數(shù)據(jù)庫里存儲數(shù)據(jù)看起來會涉及到一些管理費(fèi)用，因此筆者只進(jìn)行了一些簡單的測試。創(chuàng)建需要構(gòu)建串序列的關(guān)鍵值，目標(biāo)實(shí)例通常是Java代碼的瓶頸?？雌饋碓谶@些測試都沒有構(gòu)成問題。
總的來說，甲骨文NoSQL數(shù)據(jù)庫很愿意進(jìn)行嘗試，因?yàn)樗芴峁┤绱素S富的特性，可以進(jìn)行更加深入的數(shù)據(jù)管理。工具比簡單的NoSQL項(xiàng)目要更加的徹底和久經(jīng)考驗(yàn)。在面對節(jié)點(diǎn)故障時，你有各種不同的選擇來提高耐久力。
甲骨文NoSQL數(shù)據(jù)庫可能無法提供給你驚喜，只能積累對于開源NoSQL項(xiàng)目的經(jīng)驗(yàn)，但是這確實(shí)不是它的角色。甲骨文從中吸取了最好的想法來向企業(yè)市場傳遞最佳的性能。
甲骨文NoSQL數(shù)據(jù)庫會從甲骨文悠久的傳統(tǒng)中分離出來。筆者發(fā)現(xiàn)安裝和運(yùn)行甲骨文主要數(shù)據(jù)庫比較困難。對比之下，開源社區(qū)能做的更好。有用戶表示最重要的MySQL在測試和重新測試安裝配置上要做的更好。
甲骨文NoSQL數(shù)據(jù)庫顯然是來自擁有開源傳統(tǒng)經(jīng)驗(yàn)的研發(fā)團(tuán)隊(duì)。唯一的問題是在將本地主機(jī)更改為127.0.0.1時遇到的。這是一個很大的改進(jìn)。