数据存储和检索从未如此处于令人兴奋的新技术最前缘，并且它是一个早已应该来临的重大更新。让我们细想一下，在过去二十年里，文件系统或关系数据库真正改变了多少?

　　Web 2.0：在新技术里，这是一个被过度使用、被过度宣传并且被赋予过多意义的词汇。现在人们在每个场合都会谈到它。过去，Web 2.0曾被视为年轻的PHP高手玩弄的宝贝玩意儿，现在，从这一概念里已经孵化出各种各样的应用程序。这些大规模分布、社会化传播的系统，为数据存储系统的容量带来了前所未有的压力。在Twitter工程师中，解决数据库方面的压力也成为Twitter技术团队的主要工作。

　　AJAX和其他类似的富客户端技术的出现，让人们期待看到更为敏捷漂亮的用户界面，这对数据访问和低延迟提出更高的要求。此外，随着富媒体(视频、高清图片)的迅速增加，数据容量出现爆炸式增长，并且这一趋势也将继续下去。最终，过去只有在高度专业化的系统中(比如电信和某些军用系统)才会出现的数据可用性需求，随着丰富的移动设备和互相连接平台(比如智能电话、上网本和平板电脑)的增加，现在已普及到更为广泛的应用类型中。

　　令人关注的地方在于，这种类型的互动已经不再局限于社交网站上用户交流，比如在Facebook上跟踪好朋友的漂亮女友。这种充满粘性并具有病毒式传播效果的互动正在慢慢入侵主流应用，因为它能够让用户参与进来，给他们一种“我的地盘我做主”的感觉。SalesForce公司提供的Chatter云协作工具就是一个很好的示例。或者也可以以下事实为例，在很多企业的局域网里已经具备了这种社交化的功能，比如共享书签或分享“心情”。甚至提供金融的公司也开始利用丰富的视觉化机制对基金进行比较，然后还可以将个人的观点与“好友”分享。对于新闻和媒体网站，除了新闻本身，这些网站还可以从用户评论和交流中收集更多有趣的信息。

　　回到技术。这给我们带来了什么?大容量，应用方面的高要求，低延迟访问的需求，数据存储系统不间断的高可用性，那些困扰着传统关系型数据库管理系统(RDBMS)的所有因素。于是，这个世界开始求助于一项名为“内存数据网格”的技术。

　　内存数据网格(In-memory Data Grid)

　　内存数据网格并不是新技术，已经出现一段时间了。随着应用程序不断成长，需要适应快速增加的数据以及满足增加更为快速的预期和要求，内存数据网格被 用于大型或任务重大的应用程序中，以此缓解 RDBMS系统的工作量。你可以会将数据网格的这种应用成为分布式缓存(distributed cache)——逐渐过时的RDBMS系统中附带的一个pacemaker工具。

　　但是，即使使用这种技术仍然不足以解决问题，因为RDBMS 仍会成为的最大的障碍，尤其在具备真正灵活性的云式部署中，在这种部署中，为了能够在任一时刻能够最高效地处理荷载，将按需增加或减少虚拟接节点(virtual node)。正是在这里，NoSQL 出现了。

　　NoSQL的世界

　　目前，NoSQL 这一用语与它所宣传的数据组织方式一样，都是未明确定义和非结构化的。NoSQL 背后的整体理念是非结构化的、灵活性的数据。高可用性、高扩展性，还有最重要的：分布式的。正如 Eric Breawer 的 CAP 原理中所述，在大多数NoSQL系统中，为了获得如此高的可用性，一致性被弱化，这样做的结果是所谓的“最终一致性”(Eventual Consistency)。在过去几年里，也许你已经听说一些比较知名的相关实施，比如Google 的BigTable 和Apache Hadoop。确切来讲，这些实现提高了实际扩展性的门槛并制定了NoSQL标准。但是，当前NoSQL 项目的增加所有带来的超级前缘的解决方案正慢慢地让开发者变得无忧无虑。

　　但是这些解决方案已经足够了吗?在很多情况下，NoSQL 是非常有用的，但大多数基于磁盘的 NoSQL 系统关注的焦点是大容量和处理量而不是低延迟的快速访问。NoSQL 数据和内存数据网格的交叉地带还存在一个“子物种”，这个方案能够快速、地延迟低访问内存数据。这类系统包括 Amazon 的Dynamo和开源项目 Voldemort 和Infinispan。

　　数据云：DaaS

　　现在我们来看看另一个被过度宣传并被赋予过多意义的词汇：云计算。无论是公共还是私人应用，在可扩展、易用性和高度硬件利用率的特种领域，云计算一直很受欢迎。这些特殊要求已经由架构(IaaS)和平台(PaaS)服务实现。这种方式也可应用于数据存储。设想以独立于平台方式连接到一个服务，用于存储和检索数据，与传统的RDBMS 连接没有太多不同。不过，现在你无需了解或担心存储数据所用的系统类型，而且获得低延迟、高扩性和高可用性的保证。对于任何云部署，为了同时获得灵活的、 按需定制的架构和中间件，这种存储系统的虚拟化都是必须的。另外，具备灵活性、低延迟、分布性等理想特征的技术也能够为这种虚拟化提供帮助。通常这会设计 到多种NoSQL解决方案。即使只用于内部的私人云应用，这样的解决方案将需要具备多租户(multi-tenancy)、计量(metering)和状态监控等功能。为了能够将数据从不同的应用中隔离开来，多租户是必需的，也许还会用某些形式的名空间(namespacing)。计量对于正确地分摊运行该服务的共用成本 是至关重要的。为了实现计量需要记录占用的CPU周期、消耗的磁盘和内存空间，甚至还会包括宽带的占用量。

　　Amazon公司提供了一个这样的服务，称为SimpleDB。Google 的AppEngine提供访问BigTable 的 DataStore API接口。但是，除了这两款产品，当前这一市场还是一片空白。出露头家的云服务提供商(或者未云服务提供商提供软件的销售商)应该认真对待这种数据服务，确保它成为其产品的一部分。

　　对于应用程序开发者，这意味着什么?

　　所幸的是，大多数人不再像过于那样多地域数据库进行互动。ORM 工具，如 Hibernate(一种 JPA 标准的实现)已经在RDBMS 上添加了一个抽象层。我期待使用这类ORM工具的插件能够让RDBMS更为容易地转换为灵活性的云存储服务。其中一个是刚刚推出的SimpleJPA项目，它提供构建在Amazon SimpleDB 之上的 JPA 功能;另一个是Infinispa即将推出的JPA接口。虽然更多作为DaaS的插件将出现，但我不认为这些工具是万能灵药，能够现实真正的透明迁移。我认为开发者仍然需要对应用程序数据进行长期认证地思考，理解存储方式的内在原 因。在我们设计的数据模型中，某些RDBMS特有的假设总是时隐时现，这是因为RDBMS技术已经根深蒂固地融入了我们有关数据的思维之中。当我们转而思考非 RDBMS 存储时，这些东西常常称为阻碍或者减低效率。