关系数据库已经统治数据存储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
这种对象持久存储方法很有效，但容易看出，如果您频繁使用票据实体 —例如，如果您正在各种 servlet 中创建(或查找)它们，那么这种方法将变得令人厌烦。使用一个公共 servlet(或 Groovlet)来为您处理这些任务将消除其中一些负担。一种更自然的选择——我将稍后展示——将是建模一个 Ticket对象。
返回比赛
我不会重复 Gaelyk 简介中的那个票据示例，相反，为保持新鲜感，我将在本文中使用一个赛跑主题，并构建一个应用程序来展示即将讨论的技术。
如图 1 中的 “多对多” 图表所示，一个 Race拥有多个 Runner，一个 Runner可以属于多个 Race。
图1. 比赛和参赛者
如果我要使用一个关系表结构来设计这个关系，至少需要 3 个表：第 3 表将是链接一个 “多对多” 关系的联接表。所幸我不必局限于关系数据模型。相反，我将使用 Gaelyk(和 Groovy 代码)将这个 “多对多” 关系映射到 Google 针对 Google App Engine 的 Bigtable 抽象。事实上，Gaelyk 允许将 Entity当作 Map，这使得映射过程相当简单。
无模式数据存储的好处之一是无须事先知道所有事情，也就是说，与使用关系数据库架构相比，可以更轻松地适应变化。(注意，我并非暗示不能更改架构;我只是说，可以更轻松地适应变化。)我不打算定义我的域对象上的属性 —我将其推迟到 Groovy 的动态特性(实际上，这个特性允许创建针对 Google 的 Entity对象的域对象代理)。相反，我将把我的时间花费在确定如何查找对象并处理关系上。这是 NoSQL 和各种利用无模式数据存储的框架还没有内置的功能。
Model 基类
我将首先创建一个基类，用于容纳 Entity对象的一个实例。然后，我将允许一些子类拥有一些动态属性，这些动态属性将通过 Groovy 的方便的 setProperty方法添加到对应的 Entity实例。setProperty针对对象中实际上不存在的任何属性设置程序调用。(如果这听起来耸人听闻，不用担心，您看到它的实际运行后就会明白。)
清单2展示了位于我的示例应用程序的一个 Model实例的第一个 stab：
清单2. 一个简单的 Model 基类
packagecom.b50.nosqlimportcom.google.appengine.api.datastore.DatastoreServiceFactoryimportcom.google.appengine.api.datastore.EntityabstractclassModel {def entitystaticdef datastore = DatastoreServiceFactory.datastoreServicepublicModel(){super()}publicModel(params){this.@entity=newEntity(this.getClass().simpleName)params.each{ key, val ->this.setProperty key, val}}def getProperty(String name) {if(name.equals("id")){returnentity.key.id}else{returnentity."${name}"}}voidsetProperty(String name, value) {entity."${name}"= value}def save(){this.entity.save()}}