[周报全文]超越传统:NoSQL横空出世

2009-09-29 |  作者:本报特约撰稿人 王翔 |  来源:独家 |  查看原文

摘要看似已经“成熟稳重”的数据库领域,居然再次掀起一轮新的浪潮。更确切地说,是数据库领域中最为稳固的关系数据模型最近遭遇到NoSQL支持者的尖锐质疑。

【CNW.com.cn 专稿】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的方案解决。

而在整个架构中,关系型数据库仍然是信息管理的核心,保存着最重要的、最控制商业价值的数据信息。总之,只要把握住关键商业环节和关键商业价值,关系型数据库现在看来依然会活得有声有色。(更多内容详见http://www.cnw.com.cn/P/1785)

编看编想

“与敌同行”是正道

网界网 于翔

NoSQL的首届全球大会被比作现代IT版的“波士顿倾茶”事件。后者是美国民众反抗垄断、挑战权威的一次经典事件。与之类似的是,NoSQL此次的高调出场也是以挑战权威、质疑传统为基调的。毫无疑问,NoSQL的出现让数据库市场不再“风平浪静”,凭借着颠覆性的技术理念,以及与用户在Web 2.0环境中数据管理需求的合拍,NoSQL让大众看到了数据库技术变革的希望。面对传统的关系型数据库阵营,NoSQL的领袖们从不吝惜自己的质疑与批评。

的确,站在传统力量的对面是新兴势力彰显个性、确立根基的有效方法。但正如本文作者所写的,传统的关系型数据库不会死去。撇去概念炒作的内容,对数据库用户而言,NoSQL的实际价值在于其对大容量数据写入操作处理能力。这一特性虽然难以动摇关系型数据库在商业应用领域的统治地位,但却能够拓展数据管理的全新应用空间,同时成为关系型数据库的有益补充。因此,背负着“颠覆”之名的NoSQL,未来的日子里需要“与敌同行”。

相关文章