关系数据库已经统治数据存储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,数据建模，转载需保留来源！

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。