先睹為快：甲骨文NoSQL資料庫

在過去的幾年裡，NoSQL資料庫的世界裡充滿了各種有趣的新專案，雄心勃勃的聲明和大量信誓旦旦的承諾。 有傳聞稱最新的NoSQL資料庫軟體套裝通過調整所有的結構和資料庫建立者多年來一直希望增加的三倍校驗來實現大幅度的性能提升。 可靠性如何呢？ 據那些沒有使用NoSQL資料庫來運行大規模企業級應用軟體而只是從事一些瑣碎交易的華爾街銀行程式設計人員表示，可靠性是被高估了。 製表結構如何呢？ 過於死板和有限了。 如果我們將這些問題忽略的話，那麼資料庫的優勢是免費，且運行速度很快。

NoSQL資料庫的面世也十分緩慢。 甲骨文-高級NoSQL資料庫的頂尖研發廠商推出了一款可靠的實用的和與甲骨文非常類似的NoSQL伺服器。 儘管瘋狂的夢想家們還在繼續構建著NoSQL資料庫的存儲庫，但認為還是希望能關注甲骨文版本。 它不僅能提供很多讓NoSQL資料庫更加有趣的特性，但是可靠的性能號稱來自大型的工程師團隊。

&HTTP://www.aliyun.com/zixun/aggregation/37954.html">nbsp;

這款產品的面世可能會讓NoSQL資料庫的擁躉者們（那些一直對甲骨文資料庫引以為傲的守舊派們）倍感驚喜，但是甲骨文公司會暫時沿著這條路緩慢前進。 五年前，甲骨文收購了Sleepycat軟體公司，這家公司是開源貝克利資料庫的建立者（這是一款為C和後來的JAVA程式設計人員設計的靈活性索引碼存儲上有著悠久且豐富傳統的工具）。 同樣的貝克利資料庫技術據稱是甲骨文NoSQL資料庫的核心，雖然看起來還需要全部重新編寫代碼。

甲骨文NoSQL資料庫：實用的ACID

甲骨文NoSQL資料庫的有趣之處是索引碼結構。 你不需要定義一個計畫或者拘泥于大型的表格式體系結構中。 你只需創建索引碼並關聯到位元組上。 你可以將你的索引碼連接到字串或者映射檔或者任何東西上。 資料庫可以接收位元組而且無需考慮太多內容。

甲骨文公司將索引碼劃分為主要部分和次要部分。 你可以將主要部分看做是目標指示器，將次要部分看做是記錄裡的域。 這樣你可以將名字和社會保障號碼放在索引碼的主要部分裡，像街道位址和郵遞區號這樣的其他字串放在次要部分裡。 和其他的一些NoSQL工具是可以進行對比的，説明使用者將多個域的目標物體的價值對比考慮。 甲骨文只是使用「次要索引碼」這個資料來作為域的名稱。

甲骨文NoSQL資料庫重要的部分是實用的ACID，NoSQL資料庫可能提供的標準版。 ACID指的是「細微的，相容的，獨立的，持久的處理」，對於這方面的細節展開了一場激烈的爭論。 多數NoSQL資料庫承諾是「BASE」，即「基本的可用性，軟狀態和最終的一致性」的首字母縮寫。 換句話說，你可以得到正確的答案，除非你不需要的時候。

對於甲骨文NoSQL資料庫是否能提供真正的ACID存在著大量的爭論。 當你編寫關聯到同一個索引碼的主要部分的資料時你只能得到ACID的承諾。 舉例來說，由於兩部分都被存儲在同一個主要索引碼裡，所以你可以更改同一個人的位址和郵遞區號並得到ACID的保證。 但是不擔保兩個獨立人的改變將保持一致。 換句話說，已將銀行可以使用甲骨文NoSQL資料庫來存儲個人記錄，但是不會用於帳戶間現金的安全交易，因為沒有不會導致金錢損失的ACID擔保。

甲骨文NoSQL資料庫能夠做出這種承諾，因為它可以保證一台主機能存儲所有關聯到主要索引碼的次要索引碼。 將任何域的集合關聯到定義一個人的主要索引碼上，這個資料的所有將集中在集群的同個節點上。 但是來自不同主要索引碼的資料會放置在不同的伺服器上，甲骨文NoSQL資料庫沒有一個機制來確保資料被同時寫入主要索引碼和次要索引碼。

你還能增加複製和碎片，甲骨文將其稱為「分區」。 本質上來說就是安排矩陣中發生碎片的節點。 如果你需要更多的可靠性和更快的讀取速度，你需要沿著複製軸增加更多的系統。 如果你希望減少爭議，你可以沿著分區軸增加更多的系統。 甲骨文NoSQL資料庫能為你應對更多此類配置。

這不止是個二進位的判斷。 你可以讓甲骨文NoSQL資料庫終止寫入，或者多數節點已經完成了資料到硬碟的發送。 檔將這個特性稱之為持久力協定。

這種靈活性也可以供程式設計人員使用，如果你有時間來為此擔心的話。 所有的索引碼配對都伴隨著一個版本號。 如果你想在修改記錄時提高性能這種方式是有説明的。

持續性：備受爭議

耶魯大學計算科學系教授丹尼爾.阿巴迪的博客引發了有關最終持續性的爭議。 阿巴迪指出在某些情況下，寫入到主索引碼的新配對可能會在主索引碼被切斷後丟失。 美國哈佛大學電腦科學教授，同時也是甲骨文的員工馬格.賽爾查則持不同的觀點。 她加入了被收購的Sleepycat公司。

賽爾查認為一切都要取決與你對「最終持續性」的理解。 資料庫擁有者會選擇利用他們對持續性協定的機會。 如果擁有者希望確保一個配對不會丟失，他們必須所有寫入的資料要等到所有副本被升級以後。

為了測試甲骨文NoSQL資料庫的速度，筆者採用給了一種低端測試，將更多的壓力放在資料庫引擎上而不是網路上。 筆者從單節點NoSQL伺服器開始，然後嘗試了358400個關聯到索引碼的索引碼（恰紅包含了大約30個字元的串），在老型號的Mac電腦上的速度是119秒。 使用小容量隨機儲存體的老型號設備是測試有限資源下性能的一種方式。

作為對比，筆者有同樣的配對測試了Voldemort的新版本，這是一款來自于Linkedln的用JAVA開發的開源NoSQL資料庫。 在同款設備上花費了180秒。

由於在甲骨文NoSQL資料庫裡存儲資料看起來會涉及到一些管理費用，因此筆者只進行了一些簡單的測試。 創建需要構建串序列的索引碼，目標實例通常是JAVA代碼的瓶頸。 看起來在這些測試都沒有構成問題。

總的來說，甲骨文NoSQL資料庫很願意進行嘗試，因為它能提供如此豐富的特性，可以進行更加深入的資料管理。 工具比簡單的NoSQL專案要更加的徹底和久經考驗。 在面對節點故障時，你有各種不同的選擇來提高耐久力。

甲骨文NoSQL資料庫可能無法提供給你驚喜，只能積累對於開源NoSQL專案的經驗，但是這確實不是它的角色。 甲骨文從中吸取了最好的想法來向企業市場傳遞最佳的性能。

甲骨文NoSQL資料庫會從甲骨文悠久的傳統中分離出來。 筆者發現安裝和運行甲骨文主要資料庫比較困難。 對比之下，開源社區能做的更好。 有使用者表示最重要的MySQL在測試和重新測試安裝配置上要做的更好。

甲骨文NoSQL資料庫顯然是來自擁有開源傳統經驗的研發團隊。 唯一的問題是在將本地主機更改為127.0.0.1時遇到的。 這是一個很大的改進。

(責任編輯：蒙遺善)