Java开发2.0: NoSQL - 编程入门网

将一个新的 Runner添加到 race并添加对 Race的 save的调用后，这个数据存 储已使用一列 ID 更新，如图 3 中的屏幕快照所示：

图 3. 查看一项比赛中的多个参赛者的新属性

Java开发2.0: NoSQL(8)

通过仔细检查 Google App Engine 中的数据，可以看到，一个 Race实体现在 拥有了一个 Runners 的 list，如图 4 所示。

图 4. 查看新的参赛者列表

同样，在将一个 Race添加到一个新创建的 Runner实例之前，这个属性并不存 在，如图 5 所示。

图 5. 一个没有比赛的参赛者

但是，将一个 Race关联到一个 Runner后，数据存储将添加新的 races ids 的 list。

图 6. 一个参加比赛的参赛者

无模式数据存储的灵活性正在刷新 —属性按照需要自动添加到底层存储。作 为开发人员，我无须更新或更改架构，更谈不上部署架构了！

Java开发2.0: NoSQL(9)

NoSQL 的利弊

当然，无模式数据建模也有利有弊。回顾上面的比赛应用程序，它的一个优势 是非常灵活。如果我决定将一个新属性（比如 SSN）添加到一个 Runner，我不必 进行大幅更改 —事实上，如果我将该属性包含在构造函数的参数中，那么它就会 自动添加。对那些没有使用一个 SSN 创建的旧实例而言，发生了什么事情？什么 也没发生！它们拥有一个值为 null的字段。

快速阅读器

在 “NoSQL 与关系模型孰优孰劣” 的争论中，速度是一个重要因素。对于一 个为潜在的数百万用户传输数据的现代 Web 站点（想想 Facebook 的 4 亿用户 和计数）来说，关系模型的速度太慢了，更不用说其高昂的成本。相比之下， NoSQL 的数据存储的读取速度非常快。

另一方面，我已经明确表明要牺牲一致性和完整性来换取效率。这个应用程序 的当前数据架构没有向我施加任何限制 —理论上我可以为同一个对象创建无限个 实例。在 Google App Engine 引擎的键处理机制下，它们都有惟一的键，但其他 属性都是一致的。更糟糕的是，级联删除不存在，因此如果我使用相同的技术来 建模一个 “一对多” 关系并删除父节点，那么我得到一些无效的子节点。当然 ，我可以实现自己的完整性检查 —但关键是，我必须亲自动手（就像完成其他任 务一样）。

使用无模式数据存储需要严明的纪律。如果我创建各种类型的 Races —有些 有名称，有些没有，有些有 date属性，而另一些有 race_date属性 —那么我只 是在搬起石头砸自己（或使用我的代码的人）的脚。

当然，也有可能联合使用 JDO、JPA 和 Google App Engine。在多个项目上使 用过关系模型和无模式模型后，我可以说 Gaelyk 的低级 API 最灵活，使用最方 便。使用 Gaelyk 的另一个好处是能够深入了解 Bigtable 和一般的无模式数据 存储。

结束语

流行时尚来了又去，有时无需理会它们（明智的建议来自一个衣橱里满是休闲 服的家伙）。但 NoSQL 看起来不太像一种时尚，更像是高度可伸缩的 Web 应用 程序开发的一个新兴基础。NoSQL 数据库不会替代 RDBMS，但是，它们将补充它 。无数成功的工具和框架基于关系数据库，RDBMSs 本身似乎没有面临过时的危险 。

总之，NoSQL 数据库的作用是向对象 - 关系数据模型提供一个及时的替代方 案。它们向我们展示，有些事情是可行的，并且 —对于一些特定的、高度强制的 用例 —甚至更好。无模式数据库最适用于需要高速数据检索和可伸缩性的多节点 Web 应用程序。它们还有一个极好的副作用，即允许开发人员从一个面向域的视 角、而不是关系视角进行数据建模。

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!