昨天看到一则报道，继 Twitter之后，社交新闻网站Digg决定跟 MySQL说再见，并替换掉它的大部分基础设施组成，Digg将从LAMP（Linux、 Apache、MySQL和Perl/PHP/Python）架构迁移到基于Cassandra的NoSQL架构。
随着Web2.0和云计算的兴起，和一些反SQL的倡导，越来越多的大公司加入到NoSQL阵营。Digg、Twitter、Google、微软等等公司已经开始研究NoSQL，并在一些项目中进行实施。许多人甚至抛弃了MySQL开源数据库这个长期以来Web 2.0的宠儿，而改由NoSQL的方案来替代，因为优势实在是引人注目。
例如Facebook建立了自己的Cassandra数据商店并且在其网站上重点推出一项新的搜索功能，没有使用到现有的MySQL数据库。据 Facebook的工程师Avinash Lakshma介绍，Cassandra仅用0.12毫秒就可以写入50GB的数据，比MySQL快了超过2500倍。Google也开始公测他们的云数据库Fusion Tables，这是一个和传统数据库完全不同的数据库，主要优势能够简单的解决关系型数据库中管理不同类型数据麻烦，以及排序整合的常见操作的性能问题等。
那么什么是NoSQL？
以下仅仅从技术角度来说明什么是NoSQL。
不要叫它们数据库。Amazon.com的首席技术官Werner Vogels将他们的重要的Dynamo系统称作“高可用性的键值商店”。Google将自己的BigTable称作“管理结构化数据的分布式存储系统”，在51CTO.com之前的外电《云服务颠覆开发传统观念》中曾提到，Google的Big Table不是SQL数据库，原因是SQL数据库支持的一些功能实在难以进行分割，这与我们跨机器存储数据的想法无法结合。它们都是许多NoSQL追随者的效仿模式。
它们可以处理超大量的数据。比如Zvents公司以BigTable模式搭建的开源数据库Hypertable，据Zvents工程师Doug Judd介绍，它可以每天在搜索引擎中写入10亿单元数据。
另外，BigTable与其姊妹技术MapReduce相结合，每天可以处理多达20PB的数据。
“毫无疑问，数据量越来越巨大也让人们寻找其他的数据库替代技术，”SpringSource的Travis说。
它们运行在便宜的PC服务器集群上。PC集群扩充起来非常方便并且成本很低，避免了“sharding”操作的复杂性和成本。
Google曾表示一个BigTable的大集群可以管理数千台服务器上多达6PB的数据。
“Oracle会告诉你需要购买一些硬件然后正确配置Oracle RAC，然而用其他的神奇软件你也可以达到相同的可扩展性。但是两者的开销可是天差地别。”SpringSource首席技术官Javier Soltero说。
它们击碎了性能瓶颈。NoSQL的支持者称，通过NoSQL架构可以省去将Web或Java应用和数据转换成SQL友好格式的时间，执行速度变得更快。
“SQL并非适用于所有的程序代码，”数据库分析师Curt Monash说。对于那些繁重的重复操作的数据，SQL值得花钱。但是当数据库结构非常简单时，SQL可能没有太大用处。
Adobe公司资深计算机科学家Raffaele Sena说，当一年半前Adobe准备重新更新ConnectNow网络协作服务时，正是由于上面的理由，他们决定不采用关系型数据库。
Adobe决定使用Terracotta 提供的Java集群软件，管理Java格式的数据，Sena说，这使ConnectNow的性能提高到前一版本的2至3倍。
没有过多的操作。虽然NoSQL的支持者也承认关系数据库提供了无可比拟的功能集合，而且在数据完整性上也发挥绝对稳定，他们同时也表示，企业的具体需求可能没有那么多。
以Adobe的ConnectNow为例，Sena说，当用户在线时它会不通过数据库而制作三份会话数据，在离线后删除。“因此我们并不需要数据库，因为具体所需要的数据是在内存中的，”他说。
NoSQL横空出世
2009年6月，NoSQL运动成员的一次全球性聚会引爆了一场“数据库革命”的导火索。在此次会议上，热衷于NoSQL的人们分享着推翻缓慢而昂贵的关系型数据库，用更有效和便宜的方法来管理数据的创新构想。NoSQL之所以备受瞩目，与用户对传统关系模型和关系型数据库的负面看法直接相关。在这些质疑声中，有很多的确是用户在数据库应用过程中所遇到的实际问题。而这些问题与Web 2.0应用的风行息息相关。
NoSQL的支持者认为，关系模型人为地扭曲了目标对象的本质内容，过于僵化，尤其不利于Web 2.0应用的操作。现有的关系数据库产品，似乎都对数据的写入增加过多负载，以至于难于适应Web 2.0环境下大量非结构化内容信息的入库，包括博客、视频、音效等。
从技术体系上看，关系数据库更多强调集中或者有限节点集群的架构，而没有对信息内容面向大量廉价的分散计算单元进行设计，以致于无法支持类似Google BigTable、Amazon Dynamo这样的世界级信息管理技术。
显而易见，NoSQL运动将矛头直指传统数据库的主宰者。虽然这在短期内无法动摇关系型数据库帝国，但是它所掀起的湍流却在数据库领域拍打出阵阵鸣响。
技术差异解读
除了以Web 2.0为代表的应用潮流的涌动，以及用户行为习惯的因素外，NoSQL的提出者们有着非常明确的技术特征考虑。具体如下。
1．读写方式的差异
以往的关系数据库更多地是面向“多读少写”（Read heavy）、读写并重（Read and write heavy）的情况。因为信息是从商用的角度来收集和汇总的，用户之所以会访问某个站点，也是因为对其内容优势类别的选择。信息写入后，在相对少的修改情况下，被大量的受众访问和阅读。
Web 2.0环境把这种情况彻底改变了。“站点搭台您唱戏”，内容的提供者是一个个分离的个体。他们把自己的信息贡献到站点，但信息却不如前者那样会被密集地访问，即便有个别的明星博客、SNS焦点神秘嘉宾，但总体上是形成了“少读多写”（Write heavy）的局面（其中的差异如图1和图2所示）。
反观现有的关系数据库，主要面向前者模式而设计。而且为了实现数据驱动、内容驱动，以及预定式信息处理，往往要对“写”赋予过多的额外内容。其中包括生成重做日志、检查各类锁控制、激发触发器并对触发的内容作出响应等。
不仅如此，在数据写入后，关系型数据库还要提供复杂的分布式处理。这包括信息复制、内容归档、触发信息CDC准实时抓取和分发、通知外围监控系统等。总之，关系型数据库在自我束缚的同时,并没有提供“少读多写”信息应用模式所需要的良好处理性能。
NoSQL的思路则正好相反。他们认为，只给用户“必要的”功能，而且这些解决方案是可以开源的，让大家可以“自助式”地进行读写处理，进而将数TB、甚至PB的信息加以管理。所有的读写操作也都是直入主题的，运行环境不要求、也不提供多余的操作，最终加速用户的“少读多写”的性能。
那么，是否真的要按照NoSQL的思路扔掉企业的各种商用关系型数据库呢？显然不行。
对于数据库用户，尤其是企业用户而言，建立信息系统的目的往往不是为了吸引眼球，而是为了能解决特定领域的商业流程自动化，或者半自动化。从整体商业环境看，大部分行业的商业流程主干趋于固定化。而且为了实现不同信息所有者、商业合作伙伴间的信息集成，信息格式和表达方式也趋于规范。
因此，这些信息依然是“多读少写”或者“多读多写”的。而且伴随BI（商业智能）的兴起，这些结构化程度很高的信息不仅仅用于流通环节和操作环节的OLTP（联机事务处理），还会用于或被用于ODS（操作型数据存储）、联机分析、数据挖掘等。从这个角度看，企业中的关系数据库（商用或开源）仍然非常重要。
2．开源和成本约束
是否“开源”，也是NoSQL被关注的一个重点，主要原因同样在于，过度的商业化有形或无形中会导致关系数据库的复杂化。两个技术特征的差异是互为因果的。
和超市搭售一样，用户往往会因为价格因素买一个相对“成熟”、“全面”的关系数据库产品。因为那样除了显性成本的优势外，还包括消除了出现问题时厂商间相互推诿等隐忧。这就要求商用产品自身扩充功能，扩充那些在每个用户的情境下都可冗余的功能。
不过，一旦购买了这种“包治百病”的产品后，因为产品特性间的相互制肘，本应更快地读/写操作，尤其是写入操作变得慢了。这也就不难理解，为什么NoSQL大会的矛头最后指向了曾经的开源领袖——MySQL。NoSQL的支持者认为，曾经可以在巨量廉价设备上使用的MySQL，在被商用化后增加了一些他们用不到的功能。虽然每个许可看起来都是小钱，但如果乘以一个庞大的基数就无法承受了。
那么，NoSQL所提出的开源理念能否获得用户的认可呢？很有可能。
随着技术门槛的降低，以及开源运动的深入，越来越多以往只有通过严密技术转让合同才能了解的技术领域，现在可以通过互联网就可免费学习和使用了。而开源软件的大多数常用的功能领域也趋于强健。同时，围绕开源产品也形成了一个新的技术生态圈，企业用户可以从这些圈中获得所需的技术支持和第三方服务。尤其在关系型数据库领域，已经有很多企业开始采用或尝试使用开源产品。虽然受到企业技术战略的影响，质疑之声在所难免，但很多非核心系统采用开源关系型数据库配合开源框架成为越来越多企业的共同选择。
NoSQL提出的分布式设计对很多企业而言暂时还用不到，或者说企业IT环境暂时还没有演变到这个阶段。但分布式非数据库信息系统会在类似Google、Amazon这样的互联网厂商的催化下渐渐催生出新的综合性应用产品，而届时一些IT演进快速的企业也正好到了适用阶段。所以，NoSQL旗手们的开拓之路很有可能被普通用户或者是企业用户接受。
3．加工对象容量设计的分歧
NoSQL强调“大”数据量，那么这些TB，甚至PB级的写入对于绝大多数的用户有多少实际的意义呢？
经典的关系数据模型并没有对数据容量有明确的限制，但现实环境下用户（尤其是Web 2.0产品的运营商们）却不得不考虑数据容量的限制问题。借助各种信息平台，掩盖在互联网下面的海量用户无时无刻地不在制造或者拼凑着大量的信息，这些信息可能小到Twitter上的一句“Hi！”，也可能大到一张蓝光电影。如果继续用关系型数据库来处理他们，运营商不仅仅是赔本赚吆喝了，很可能是卖血也听不到吆喝声。NoSQL的领袖们正是看到了这一点，尝试自主策划全新的技术实现手段。
在正视大容量数据情景的同时，我们是否应该立即扔掉传统的关系型数据库，转向“大小通吃”的NoSQL环境呢？也不是。
现实中，绝大部分应用并没有这么大的信息量，尤其当信息是来自用户输入和登记的情况下。而且，即便是图片信息，大多数情况下，在现有显示设备支持下也没必要个个都异常细致。随着一个个行业信息标准的推出，很多行业的数据容量不仅可以评估，甚至可以较为准确地预测。而NoSQL虽然提供了很好的写入效率，但并没有对查询操作提供兼具关系数据库丰富功能和NoSQL写入效率优势的解决方案。甚至很多方案在检索相同信息的时候，效率还会远远低于关系型数据库。从这个角度分析，关系型数据库尽管提供的容量支持有限，但对于绝大多数的商业数据处理，它则更好地兼顾了读取和写入，而且功能更符合绝大部分商业情景的需要。
数据库的用户应该如何看待这个问题呢？笔者认为，关系型数据库和NoSQL的差异性反而有利于用户根据自己的应用情景灵活选择，我们不仅要利用NoSQL的快速写入能力，更要两者兼融并蓄，取长补短。
向NoSQL学习
NoSQL的理念固然尖锐，它质疑关系型数据库的积弊和不足。那么，从这些批评声中，传统的关系数据库应该学习点什么呢？
首先，产品需要补课。关系型数据库不仅要着眼传统的商业信息处理，还要照顾到伴随Web 2.0而来的全新用户使用场景。要满足这些特征，需要数据库厂商苦练内功。以写入操作为例，需要根据不同类型的数据容量提供多种写入策略。让那些需要严加管控的能“管得住”，没有附加条件的写入就要迅速完成。
其次，要赋予用户更多的自由裁量权，提供更多的版本选择余地。尽管在商业上捆绑销售对于用户，尤其是大型企业用户是非常有效的营销手段，但也要看到IT领域中开源软件强劲的竞争势头。传统数据库厂商应该在产品“减肥”上多下功夫。
除此之外，网格也好，云数据服务也好，在确保集中式一站管理的前提下，都要把单纯的集中式接入控制变成满足更丰富分布式接入的体系，减少现有数据库的应用瓶颈。避免即便采用数十个高端服务器节点的集群也难于承载应用负荷的情况。从某种程度看上，必须要提供线形、可预测的投入/产出绩效。
关系型数据库未死
每一次技术变革都会催生出一批新的产品和开发工具。关系型数据库也许因为太过“四平八稳”了，所以多年来从“现代应用的中心”演变成厂商薄利多销的传统市场。NoSQL的出现不仅对促进传统数据库厂商改进技术有所帮助，对用户也会带来更多启示。尤其是在大部分企业拥有自己专业IT队伍的情况下，与SOA类似，借助NoSQL的思想和成果，企业可以更加灵活地设计自己的IT建设框架。笔者认为，在未来一个更好的解决方案或许是归于以下的架构：
1．结构化程度很高、结构相对稳定的数据信息继续采用关系模型管理；
2．虽然结构化程度不高，但信息内容仍然可以通过水平、垂直关系关联，并明确表示的数据信息采用以XML为代表的层次化模型管理；
3．对于较大的流式信息、无结构信息，如果需要“多读少写”或者“多读多写”，就采用传统的分布式文件系统，以共享磁盘阵列的方式保存；
4．对于非常巨大的文件，而且“少读多写”的信息，可以借鉴或采用NoSQL的方案解决。
而在整个架构中，关系型数据库仍然是信息管理的核心，保存着最重要的、最控制商业价值的数据信息。总之，只要把握住关键商业环节和关键商业价值，关系型数据库现在看来依然会活得有声有色。