|
關系數據庫已經統治數據存儲30 多年了,但是無模式(或NoSQL)數據庫的逐漸流行表明變化正在發生。盡管 RDBMS 為在傳統的客戶端服務器架構中存儲數據提供了一個堅實的基礎,但它不能輕松地(或便宜地)擴展到多個節點。在高度可伸縮的 Web 應用程序(比如 Facebook 和 Twitter)的時代,這是一個非常不幸的弱點。
盡管關系數據庫的早期替代方案(還記得面向對象的數據庫嗎?)不能解決真正緊急的問題,NoSQL 數據庫(比如 Google 的 Bigtable 和 Amazon 的 SimpleDB)卻作為對 Web 的高可伸縮性需求的直接響應而崛起。本質上,NoSQL 可能是一個殺手問題的殺手應用程序—隨著 Web 2.0 的演變,Web 應用程序開發人員可能會遇到更多,而不是更少這樣的應用程序。
在這期 Java 開發 2.0 中,我將向您介紹無模式數據建模,這是經過關系思維模式訓練的許多開發人員使用 NoSQL 的主要障礙。您將了解到,從一個域模型(而不是關系模型)入手是簡化您的改變的關鍵。如果您使用 Bigtable(如我的示例所示),您可以借助 Gaelyk:Google App Engine 的一個輕量級框架擴展。
NoSQL:一種新的思維方式?
當開發人員談論非關系或 NoSQL 數據庫時,經常提到的第一件事是他們需要改變思維方式。我認為,那實際上取決于您的初始數據建模方法。如果您習慣通過首先建模數據庫結構(即首先確定表及其關聯關系)來設計應用程序,那么使用一個無模式數據存儲(比如 Bigtable)來進行數據建模則需要您重新思考您的做事方式。但是,如果您從域模型開始設計您的應用程序,那么 Bigtable 的無模式結構將看起來更自然。
非關系數據存儲沒有聯接表或主鍵,甚至沒有外鍵這個概念(盡管這兩種類型的鍵以一種更松散的形式出現)。因此,如果您嘗試將關系建模作為一個 NoSQL 數據庫中的數據建模的基礎,那么您可能最后以失敗告終。從域模型開始將使事情變得簡單;實際上,我已經發現,域模型下的無模式結構的靈活性正在重新煥發生機。
從關系數據模型遷移到無模式數據模型的相對復雜程度取決于您的方法:即您從基于關系的設計開始還是從基于域的設計開始。當您遷移到 CouchDB 或 Bigtable 這樣的數據庫時,您的確會喪失 Hibernate(至少現在)這樣的成熟的持久存儲平臺的順暢感覺。另一方面,您卻擁有能夠親自構建它的“綠地效果”。在此過程中,您將深入了解無模式數據存儲。
實體和關系
無模式數據存儲賦予您首先使用對象來設計域模型的靈活性(Grails 這樣的較新的框架自動支持這種靈活性)。您的下一步工作是將您的域映射到底層數據存儲,這在使用 Google App Engine 時再簡單不過了。
在文章“Java 開發 2.0:針對 Google App Engine 的 Gaelyk”中,我介紹了 Gaelyk ——一個基于 Groovy的框架,該框架有利于使用 Google 的底層數據存儲。那篇文章的主要部分關注如何利用 Google 的 Entity對象。下面的示例(來自那篇文章)將展示對象實體如何在 Gaelyk 中工作。
清單1.使用 Entity的對象持久存儲
def ticket =newEntity("ticket")ticket.officer = params.officerticket.license = params.plateticket.issuseDate = offensedateticket.location = params.locationticket.notes = params.notesticket.offense = params.offense
清單7.查找程序的實際運行
def nrace = Race.findByName("Charlottesville Marathon")assertnrace.distance ==26.2def races = Race.findAllByName("Charlottesville Marathon")assertraces.class== ArrayList.class
it知識庫:IBM,DW,NoSQL,數據建模,轉載需保留來源!
鄭重聲明:本文版權歸原作者所有,轉載文章僅為傳播更多信息之目的,如作者信息標記有誤,請第一時間聯系我們修改或刪除,多謝。