大数据挑战与NoSQL数据库

什么是大数据？多大的数据量可以称为大数据？不同的年代有不同的答案[2]。20世纪80年代早期，大数据指的是数据量大到需要存储在数千万个磁带中的数据；20世纪90年代，大数据指的是数据量超过单个台式机存储能力的数据；如今，大数据指的是那些关系型数据库难以存储、单机数据分析统计工具无法处理的数据，这些数据需要存放在拥有数千万台机器的大规模并行系统上。大数据出现在日常生活和科学研究的各个领域，数据的持续增长使人们不得不重新考虑数据的存储和管理。

　　随着社会计算的兴起，人们习惯于在网上分享和交流信息。比如，社交网站Facebook拥有庞大的用户群，而且在不断增长。这些用户每天发出的日志以及分享的资料更是不计其数，其数据量已经达到PB级别，传统的解决方案已经不能很好地处理这些数据。Facebook自己开发了Cassandra系统，现在又采用HBase，这些针对海量数据的管理系统能够较好地为用户提供服务，而且具有可扩展性和容错性，这是解决大数据问题所需要的性能。微博服务商Twitter也面临大数据的挑战，消息的发送量达到每天数亿条，而查询量则达到每天数十亿次，这要求存储管理系统不仅能够存储大规模数据，而且能够提供高吞吐的读/写服务。Twitter原先使用MySQL数据库，之后由于用户暴增便将数据迁移到NoSQL系统上，尽管NoSQL系统还未成熟，但却是解决海量数据的较为有效的方案。其他的互联网公司同样面临着大数据带来的问题，如Goolge搜索引擎需要处理大规模的网页信息，YouTube则需要存储和提供用户分享的视频数据，维基百科提交用户分享的知识等，这些都涉及大规模数据信息存储与管理。

　　随着电子商务的发展，越来越多的人在网上选购商品，商务网站需要存储大量的商品信息和用户的交易信息，涉及大规模的数据。同时网站需要提供迅速的请求响应，以提高用户体验来吸引客户。而且网站还要对这些海量数据进行处理和分析，以便更有针对性地向用户推荐商品，海量数据成为系统构建和业务成败的关键因素。中国商业网站淘宝使用HBase来存储数据，同时不断探索自己的解决之路，开发了支持大数据的数据库系统OceanBase来实现部分在线应用。全球最大的线上拍卖和购物网站eBay也积极寻求海量数据的解决方案，其基于Hadoop建立了自己的集群系统Athena来处理大规模数据，同时开发了自己的开源云平台项目Turmeric来更好地开发和管理各种服务。同时，各大零售公司无论是在线销售还是实体销售，都会注意收集客户的消费信息以便有针对性地提供服务或推荐商品，这些都涉及大规模数据的应用。

　　各个领域的科学研究同样面临海量数据的挑战，从生物基因到天文气象，从物理实验到临床医学，得益于测量技术和设备的发展，这些领域在实验或实践中产生了大量的数据，而人们需要对这些数据进行处理分析从而挖掘出有价值的信息，但这不是容易的事情。随着下一代基因测序技术的发展，基因中所蕴含的信息逐渐被人们所发掘，人们获得更多更准确的基因数据，但是如何匹配基因数据，如何从这些数据中挖掘出所需要的信息，这是生物信息学遇到的新挑战。在环境气象研究中，科学家已经收集了数十年甚至上百年的气象环境数据，在这些数据中分析气候的变化需要海量数据处理技术的支持。在医学药物研究中搜集的大量的病人生理数据和药物测试数据，这些数据的规模很大，需要从中分析出有用的信息。在人文社会科学中，社会学家开始注意互联网社交网络上的人际交往和社会关系，其涉及的数据量也是非常巨大的，从海量数据中找出社会学家感兴趣的内容是富有挑战性的。人工智能研究方面，人们希望计算机拥有人类的学习能力和逻辑推理能力，这就需要机器存储大量的经验数据和知识数据，还需要从这些大量数据中迅速获得所需要的内容，并对其进行分析处理，从而做出正确有效的判断。

　　如今传感器的广泛使用，数据采集更加方便，这些传感器会连续地产生数据，如实时监控系统、网络流量监测等。除了传感器源源不断地产生数据外，许多领域都会涉及流数据，如经济金融领域中股票价格和交易数据、零售业中的交易数据、通信领域中的数据等都是流数据，这些数据最大的特点就是海量，因为它们每时每刻连续不断地产生，但与其他的海量数据不同，流数据连续有序、变化迅速，而且对处理分析的响应度要求较高，因此对于流数据的处理和挖掘往往采用不同的方法。经济金融领域各个方面都产生海量数据，如证券价格变化和股票交易形成的流数据，企业或个人各种经济活动而产生的数据等。现代经济已经步入海量数据时代，在新时代下可以带来创新和生产率增长，并可能出现新的商业模式。利用好经济生活产生的海量数据，可以发挥重要的经济作用，不仅有利于企业的商业活动，也有利于国民经济，提高国家的竞争力。面对大规模的经济数据，人们除了需要提高获取、存储和分析数据的能力，同时需要保障数据的安全和隐私，但这仍然是巨大的挑战。

　　传统的关系型数据库并不能够很好地解决海量数据带来的问题，单机的统计和可视化工具也变得力不从心。一些新的数据管理系统如并行数据库、网格数据库、分布式数据库、云平台、可扩展数据库等孕育而生，它们为解决海量数据提供了多种选择。

　　1.3 大数据的存储和管理

　　任何机器都会有物理上的限制：内存容量、硬盘容量、处理器速度等等，我们需要在这些硬件的限制和性能之间做出取舍，比如内存的读取速度比硬盘快得多，因此内存数据库比硬盘数据库性能好，但是内存为2GB的机器不可能将大小为100GB的数据全部放入内存中，也许内存大小为128GB的机器能够做到，但是数据增加到200GB时就无能为力了。

　　数据不断增长造成单机系统性能不断下降，即使不断提升硬件配置也难以跟上数据的增长速度。然而，当今主流的计算机硬件比较便宜而且可以扩展，现在购置八台8内核、128GB内存的机器比购置一台64内核、TB级别内存的服务器划算得多，而且还可以增加或减少机器来应对将来的变化。这种分布式架构策略对于海量数据来说是比较适合的，因此，许多海量数据系统选择将数据放在多个机器中，但也带来了许多单机系统不曾有的问题。

　　下面我们介绍大数据存储和管理发展过程中出现的四类大数据存储和管理数据库系统。

　　1.3.1 并行数据库

　　并行数据库[1]是指那些在无共享的体系结构中进行数据操作的数据库系统。这些系统大部分采用了关系数据模型并且支持SQL语句查询，但为了能够并行执行SQL的查询操作，系统中采用了两个关键技术：关系表的水平划分和SQL查询的分区执行。

　　水平划分的主要思想就是根据某种策略将关系表中的元组分布到集群中的不同节点上，这些节点上的表结构是一样的，这样就可以对元组并行处理。现有的分区策略有哈希分区、范围分区、循环分区等。例如，哈希分区策略是将表T中的元组分布到n个节点上，可以使用统一的哈希算法对元组中的某个或某几个属性进行哈希，如hash(T.attribute1) mod n，然后根据哈希值将元组放置到不同的节点上。

　　在分区存储的表中处理SQL查询需要使用基于分区的执行策略，如获取表T中某一数值范围内的元组，系统首先为整个表T生成总的执行计划P，然后将P拆分成n个子计划{P1,…,Pn}，子计划Pi在节点ni上独立执行，最后每个节点将生成的中间结果发送到某一选定的节点上，该节点对中间结果进行聚集产生最终的结果。

　　并行数据库系统的目标是高性能和高可用性，通过多个节点并行执行数据库任务，提高整个数据库系统的性能和可用性。最近一些年不断涌现一些提高系统性能的新技术，如索引、压缩、实体化视图、结果缓存、I/O共享等，这些技术都比较成熟且经得起时间的考验。与一些早期的系统如Teradata必须部署在专有硬件上不同，最近开发的系统如Aster、Vertica等可以部署在普通的商业机器上，这些数据库系统可以称得上准云系统。

　　并行数据库系统的主要缺点就是没有较好的弹性，而这种特性对中小型企业和初创企业是有利的。人们在对并行数据库进行设计和优化的时候认为集群中节点的数量是固定的，若需要对集群进行扩展和收缩，则必须为数据转移过程制订周全的计划。这种数据转移的代价是昂贵的，并且会导致系统在某段时间内不可访问，而这种较差的灵活性直接影响到并行数据库的弹性以及现用现付商业模式的实用性。

　　并行数据库的另一个问题就是系统的容错性较差，过去人们认为节点故障是个特例，并不经常出现，因此系统只提供事务级别的容错功能，如果在查询过程中节点发生故障，那么整个查询都要从头开始重新执行。这种重启任务的策略使得并行数据库难以在拥有数以千个节点的集群上处理较长的查询，因为在这类集群中节点的故障经常发生。基于这种分析，并行数据库只适合于资源需求相对固定的应用程序。不管怎样，并行数据库的许多设计原则为其他海量数据系统的设计和优化提供了比较好的借鉴。

　　1.3.2 NoSQL数据管理系统

　　NoSQL[5]一词最早出现于1998年，它是Carlo Strozzi开发的一个轻量、开源、不提供SQL功能的关系型数据库（他认为，由于NoSQL悖离传统关系数据库模型，因此，它应该有一个全新的名字，比如“NoREL”或与之类似的名字[6]）。

.　　2009年，Last.fm的Johan Oskarsson发起了一次关于分布式开源数据库的讨论[7]，来自Rackspace的Eric Evans再次提出了NoSQL的概念，这时的NoSQL主要指非关系型、分布式、不提供ACID的数据库设计模式。  
　　2009年在亚特兰大举行的“no:sql(east)”讨论会是一个里程碑，其口号是"select fun, profit from real_world where relational=false;"。因此，对NoSQL最普遍的解释是“非关系型的”，强调键值存储和文档数据库的优点，而不是单纯地反对关系型数据库。    
　　传统关系型数据库在处理数据密集型应用方面显得力不从心，主要表现在灵活性差、扩展性差、性能差等方面。最近出现的一些存储系统摒弃了传统关系型数据库管理系统的设计思想，转而采用不同的解决方案来满足扩展性方面的需求。这些没有固定数据模式并且可以水平扩展的系统现在统称为NoSQL（有些人认为称为NoREL更为合理），这里的NoSQL指的是“Not Only SQL”，即对关系型SQL数据系统的补充。NoSQL系统普遍采用的一些技术有：  
　　简单数据模型。不同于分布式数据库，大多数NoSQL系统采用更加简单的数据模型，这种数据模型中，每个记录拥有唯一的键，而且系统只需支持单记录级别的原子性，不支持外键和跨记录的关系。这种一次操作获取单个记录的约束极大地增强了系统的可扩展性，而且数据操作就可以在单台机器中执行，没有分布式事务的开销。  
　　元数据和应用数据的分离。NoSQL数据管理系统需要维护两种数据：元数据和应用数据。元数据是用于系统管理的，如数据分区到集群中节点和副本的映射数据。应用数据就是用户存储在系统中的商业数据。系统之所以将这两类数据分开是因为它们有着不同的一致性要求。若要系统正常运转，元数据必须是一致且实时的，而应用数据的一致性需求则因应用场合而异。因此，为了达到可扩展性，NoSQL系统在管理两类数据上采用不同的策略。还有一些NoSQL系统没有元数据，它们通过其他方式解决数据和节点的映射问题。  
　　弱一致性。NoSQL系统通过复制应用数据来达到一致性。这种设计使得更新数据时副本同步的开销很大，为了减少这种同步开销，弱一致性模型如最终一致性和时间轴一致性得到广泛应用。  
　　通过这些技术，NoSQL能够很好地应对海量数据的挑战。相对于关系型数据库，NoSQL数据存储管理系统的主要优势有：  
　　避免不必要的复杂性。关系型数据库提供各种各样的特性和强一致性，但是许多特性只能在某些特定的应用中使用，大部分功能很少被使用。NoSQL系统则提供较少的功能来提高性能。  
　　高吞吐量。一些NoSQL数据系统的吞吐量比传统关系数据管理系统要高很多，如Google使用MapReduce每天可处理20PB存储在Bigtable中的数据。  
　　高水平扩展能力和低端硬件集群。NoSQL数据系统能够很好地进行水平扩展，与关系型数据库集群方法不同，这种扩展不需要很大的代价。而基于低端硬件的设计理念为采用NoSQL数据系统的用户节省了很多硬件上的开销。  
　　避免了昂贵的对象-关系映射。许多NoSQL系统能够存储数据对象，这就避免了数据库中关系模型和程序中对象模型相互转化的代价。  
　　NoSQL向人们提供了高效便宜的数据管理方案，许多公司不再使用Oracle甚至MySQL，他们借鉴Amzon的Dynamo和Google的Bigtable的主要思想建立自己的海量数据存储管理系统，一些系统也开始开源，如Facebook将其开发的Cassandra捐给了Apache软件基金会。  
　　虽然NoSQL数据库提供了高扩展性和灵活性，但是它也有自己的缺点，主要有：  
　　数据模型和查询语言没有经过数学验证。SQL这种基于关系代数和关系演算的查询结构有着坚实的数学保证，即使一个结构化的查询本身很复杂，但是它能够获取满足条件的所有数据。由于NoSQL系统都没有使用SQL，而使用的一些模型还未有完善的数学基础。这也是NoSQL系统较为混乱的主要原因之一。  
　　不支持ACID特性。这为NoSQL带来优势的同时也是其缺点，毕竟事务在很多场合下还是需要的，ACID特性使系统在中断的情况下也能够保证在线事务能够准确执行。  
　　功能简单。大多数NoSQL系统提供的功能都比较简单，这就增加了应用层的负担。例如如果在应用层实现ACID特性，那么编写代码的程序员一定极其痛苦。  

 

转自：http://product.china-pub.com/3800167

　　没有统一的查询模型。NoSQL系统一般提供不同查询模型，这一定程度上增加了开发者的负担。