- 易迪拓培训,专注于微波、射频、天线设计工程师的培养
云计算推波助澜 非关系数据库蓄势待发
录入：edatop.com 点击：
这个项目还有一些限制的。项目的首页称之为"一种分布式，容错，自由面向文档模式的数据库，"没有一些人工干预你是不会获得分布式和容错功能的。CouchDB有一个好看的AJAX用户界面，包含了一个form表单，能让你复制数据库。但是还不是自动的。
CouchDB计划会增加存取控制和安全模式，但是没有以文档的形式展示出来，在API中也没显示。他们设计的初衷就是使用纯JavaScript，取代SQL,或者其他的语言，这是一个好的主意，你不会获得或者失去权限阅读文档，你能写JavaScript函数来返回true或者false结果。
使用纯JavaScript也并非坏事。当我使用这些数据库的时候，我很快发现有人能够在客户端开发一个安全模型层，使用一些不错的加密技术。在客户端加强安全控制，就能减少服务器端的工作，我在《半透明数据库》一文中有一些介绍。
这个特点正在驱使一些极端用户使用CouchDB作为整个服务器栈。J. Chris Anderson，项目的委托人之一，写了一篇文章，证明CouchDB是一个应用程序服务器的全部所需。用于显示和与数据交互的业务逻辑是用JavaScript编写的，从CouchDB下载后是一个JSON数据包。
在Anderson的眼里，当所有的功能都能用JavaScript实现，在服务器上使用Ruby、Python、Java、 PHP没有什么大的意义。这种看法或许有些极端，因为总会遇到一些情况，客户机器不能保证能正确的实现一些功能，客户端的客户比我们知道的东西少。像CouchDB这种轻量级的工具使得人们开始考虑完成一项工作真正需要多少代码。
Persevere数据库
初一看，Persevere数据库像其它大多数数据库一样。将键值对录入进去，它就将其存储起来。但是，这只是一个开头。Persevere提供了完善的对象分级结构，使得用户可以给数据库增加更多的结构，提供比上一代传统数据库更多的form。Persevere更多的表现出是一种JavaScript对象的后端存储设备，JavaScript对象由像Dojo这样的AJAX工具包创建。
Persevere引以为自豪的是它的"schema-free"，这一特点使得它与其它数据库有很大的区别。Persevere可以让你随心所欲的增加schema。Persevere并非把分级结构的顶层称为一个domain(SimpleDB这么称呼),也不称之为文档(CouchDB这么称呼)，Persevere称之为对象，它甚至可以让你创建对象的子类。如果你想违背规则，你也能坚持某些字段使用某一类型，但是这是不推荐的。Schema规则是可选的。
由于Persevere与Dojo连接紧密，Persevere提供了大量的连通性。你可以创建网格，树形窗口小部件，接着将其直接链接到JsonRestStore，窗口小部件让你编辑数据。 你可以通过20行的JavaScript代码就能远程访问一个数据库。
我遇到过许多的小的误操作，这些误操作可能是由于我缺乏经验导致，而不是潜在的Bug。当我准确的弄清楚如何做的时候，一些操作就会正确启动。Persevere本身并不是特别需要掌握，但是AJAX框架是你直接面对的。来自Dojo的文档比大多数AJAX框架要好，但是你得花一些时间来学习Dojo，才能掌握隐藏在Persevere表面后的潜在复杂性问题。
云技术和群集
尝试了这些数据库之后，我能明白为什么有人会一直称它们为"玩具"。它们功能有限，即便有新的功能，但是这些新的功能会约束你的选择。许多次我意识到SQL世界的标准功能让生活更加简单。许多基于标准SQL的工具，如报表引擎，不能连接这些新兴的数据库。使用MySQL或者Oracle这些数据库能够完成许多重大的功能。
但是，这不代表将来在我的项目中我不去使用这些新兴的数据库。它们是固态数据存储，与AJAX集成得如此紧密，使得开发更加容易。另外，多数Web站点不需要MySQL或者Oracle的所有功能，JOIN-free模式对许多普通数据结构仍旧非常有用，包括一对多关，一对一关系型数据，甚至多对一关系。
另一个问题是是否使用云技术或者构建你自己的群集。Google和Amzon都提供多机服务承诺，CouchDB和Persevere是不能匹敌的。Persevere团队声称在将来将会扩展。但是很难预料Amazon和Google的承诺有多好。如果Amazon和Google丢失了一个硬盘怎么办?如果它们丢失了一个机架怎么办?他们还没有做出很清晰的承诺和使用期限所负的责任。
举个例子，Amazon的条款重复声明了很多次："我们对于为授权的访问、改变、删除、损害、丢失任何你的内容、应用程序，或者你提交的数据、服务帐号都不负责任。"
我不是说在责备Amazon或者是Google，因为谁都不知道谁应该对丢失的事务负最终的责任。有可能是任何一个程序员，实际上也很难判断谁破坏的。但是，我们知道更多信息会更好。SimpleDB中的数据是存储在RAID磁盘中吗?当同一地区发生地震，飓风或者火灾时别的地区另外的备份吗?在线备份社区正准备开始提供这类服务的细节了，但是云技术还没有计划这样做。
所有这些顾虑让我们清楚的认识到他们仍旧是玩具数据库，打破了传统数据库的规则，对那些可以忍受数据丢失的应用程序是合适的。它们很有趣，有快，在价格方面也很合适，你的注意力可以不用放在选择数据库提供商，而是放在如何解决没有JOIN操作怎么办的问题上。
CouchDB计划会增加存取控制和安全模式，但是没有以文档的形式展示出来，在API中也没显示。他们设计的初衷就是使用纯JavaScript，取代SQL,或者其他的语言，这是一个好的主意，你不会获得或者失去权限阅读文档，你能写JavaScript函数来返回true或者false结果。
使用纯JavaScript也并非坏事。当我使用这些数据库的时候，我很快发现有人能够在客户端开发一个安全模型层，使用一些不错的加密技术。在客户端加强安全控制，就能减少服务器端的工作，我在《半透明数据库》一文中有一些介绍。
这个特点正在驱使一些极端用户使用CouchDB作为整个服务器栈。J. Chris Anderson，项目的委托人之一，写了一篇文章，证明CouchDB是一个应用程序服务器的全部所需。用于显示和与数据交互的业务逻辑是用JavaScript编写的，从CouchDB下载后是一个JSON数据包。
在Anderson的眼里，当所有的功能都能用JavaScript实现，在服务器上使用Ruby、Python、Java、 PHP没有什么大的意义。这种看法或许有些极端，因为总会遇到一些情况，客户机器不能保证能正确的实现一些功能，客户端的客户比我们知道的东西少。像CouchDB这种轻量级的工具使得人们开始考虑完成一项工作真正需要多少代码。
Persevere数据库
初一看，Persevere数据库像其它大多数数据库一样。将键值对录入进去，它就将其存储起来。但是，这只是一个开头。Persevere提供了完善的对象分级结构，使得用户可以给数据库增加更多的结构，提供比上一代传统数据库更多的form。Persevere更多的表现出是一种JavaScript对象的后端存储设备，JavaScript对象由像Dojo这样的AJAX工具包创建。
Persevere引以为自豪的是它的"schema-free"，这一特点使得它与其它数据库有很大的区别。Persevere可以让你随心所欲的增加schema。Persevere并非把分级结构的顶层称为一个domain(SimpleDB这么称呼),也不称之为文档(CouchDB这么称呼)，Persevere称之为对象，它甚至可以让你创建对象的子类。如果你想违背规则，你也能坚持某些字段使用某一类型，但是这是不推荐的。Schema规则是可选的。
由于Persevere与Dojo连接紧密，Persevere提供了大量的连通性。你可以创建网格，树形窗口小部件，接着将其直接链接到JsonRestStore，窗口小部件让你编辑数据。 你可以通过20行的JavaScript代码就能远程访问一个数据库。
我遇到过许多的小的误操作，这些误操作可能是由于我缺乏经验导致，而不是潜在的Bug。当我准确的弄清楚如何做的时候，一些操作就会正确启动。Persevere本身并不是特别需要掌握，但是AJAX框架是你直接面对的。来自Dojo的文档比大多数AJAX框架要好，但是你得花一些时间来学习Dojo，才能掌握隐藏在Persevere表面后的潜在复杂性问题。
云技术和群集
尝试了这些数据库之后，我能明白为什么有人会一直称它们为"玩具"。它们功能有限，即便有新的功能，但是这些新的功能会约束你的选择。许多次我意识到SQL世界的标准功能让生活更加简单。许多基于标准SQL的工具，如报表引擎，不能连接这些新兴的数据库。使用MySQL或者Oracle这些数据库能够完成许多重大的功能。
但是，这不代表将来在我的项目中我不去使用这些新兴的数据库。它们是固态数据存储，与AJAX集成得如此紧密，使得开发更加容易。另外，多数Web站点不需要MySQL或者Oracle的所有功能，JOIN-free模式对许多普通数据结构仍旧非常有用，包括一对多关，一对一关系型数据，甚至多对一关系。
另一个问题是是否使用云技术或者构建你自己的群集。Google和Amzon都提供多机服务承诺，CouchDB和Persevere是不能匹敌的。Persevere团队声称在将来将会扩展。但是很难预料Amazon和Google的承诺有多好。如果Amazon和Google丢失了一个硬盘怎么办?如果它们丢失了一个机架怎么办?他们还没有做出很清晰的承诺和使用期限所负的责任。
举个例子，Amazon的条款重复声明了很多次："我们对于为授权的访问、改变、删除、损害、丢失任何你的内容、应用程序，或者你提交的数据、服务帐号都不负责任。"
我不是说在责备Amazon或者是Google，因为谁都不知道谁应该对丢失的事务负最终的责任。有可能是任何一个程序员，实际上也很难判断谁破坏的。但是，我们知道更多信息会更好。SimpleDB中的数据是存储在RAID磁盘中吗?当同一地区发生地震，飓风或者火灾时别的地区另外的备份吗?在线备份社区正准备开始提供这类服务的细节了，但是云技术还没有计划这样做。
所有这些顾虑让我们清楚的认识到他们仍旧是玩具数据库，打破了传统数据库的规则，对那些可以忍受数据丢失的应用程序是合适的。它们很有趣，有快，在价格方面也很合适，你的注意力可以不用放在选择数据库提供商，而是放在如何解决没有JOIN操作怎么办的问题上。
