NoSQL详解:如何选择合适的数据库产品

日期: 2015-04-02 作者:Craig S. Mullins翻译:陈洪钰 来源:TechTarget中国 英文

虽然关系型数据库系统RDBMS在安装和使用上仍然占有主要地位,但毋庸置疑,非关系型数据库NoSQL技术已经成为今天发展最快的数据库技术。

NoSQL是对数据库系统的总称,在某种程度上,它的性能和用途可能完全不同。NoSQL一词最早产生于上世纪九十年代,意思是No SQL(没有SQL语言),后来随着时间和技术的发展,SQL界面仍然作为处理数据的方式存在,所以NoSQL又有了新的诠释,即Not Only SQL(不只是SQL语言)。今天,NoSQL数据库凭借着其非关系型、分布式、开源和横向扩展等优势,被认为是下一代数据库产品。

四种主要的NoSQL数据库和它们主要的应用场景

键值数据库:当数据以键的形式访问时,比如通过国际标准书号ISBN找一本书,键值数据库是最理想的。在这里,ISBN是键,书籍的其他信息就是值。必须知道键才能查询,不过值是一堆无意义的数据,读取之后必须经过翻译。

文档存储数据库:该数据库以文档的形式管理和存储数据。有点类似于键值数据库,但文档数据库中的数据有结构。与键值数据库中值是一堆无意义的数据不同,文档数据库中数据以文档的结构被描述,典型的是JavaScript Object Notation (JSON)或XML.文档存储数据库中的数据可以通过定义的任何模式进行查询,但键值数据库只能通过它的键进行查询。

列式数据库:也被称为列式存储或宽列存储,一改之前行式存储的方式,对数据进行列式存储。在传统关系型数据库中,数据经常以行来访问。以列式管理记录的NoSQL数据库可以管理大规模的动态列。因为没有固定的模式,所以列名和键可以变换。列式数据库适用于不经常写的情况,要满足ACID(原子性、一致性、隔离性和持久性)的要求并不难,而且模式是变化的。

图型数据库:图型数据库关注值与值之间的关系,用图型的数学概念存储数据。图型数据库用带有点、边缘和属性的图的结构表示和存储数据。在图型数据库中,每一个元素都包含一个直接的指向它毗邻元素的点,所以也就不需要索引查找。

NoSQL数据库在网页扩展、大数据和分析部署等方面越来越流行。每一个种类的NoSQL数据库都有适用的不同类型的应用程序和用例,这就涉及到一个NoSQL社区常用的一个话题,即多样持久性,或者说根据数据库处理应用程序需求的不同,使用不同的数据库系统,用于不同的应用程序和用例。

因此,使用NoSQL最重要的是使用正确的数据库,满足具体的需求,哪怕是要引入一种新的数据库系统。

NoSQL的优势和劣势

那么,为什么考虑用NoSQL数据库替代传统数据库呢?也许,前者最大的有点在于它的去中心化、可扩展、容错能力等属性。很多公司应用NoSQL数据库技术是考虑了它的可扩展能力。

用NoSQL数据库,你可以为每一个特殊的用例定制化你的数据管理解决方案。关系型数据库可以通过不同的用例广泛地应用于实践。通过考虑多样持久性,组织可以选择最能适应特殊应用场景的数据库技术。

另外,大多数NoSQL产品都是轻量级的,因此花费比较少。自从NoSQL产品被设计用来满足特殊的用例和解决特殊的问题,它的功能也就比大多数关系型数据库少,因为后者要应用于更广泛的领域。因此,NoSQL数据库需要的代码更少,这也是和复杂的关系型数据库相比具备的一项优势。

当然,NoSQL也有它的缺点。ACID协议是关系型数据库的标准,但很多NoSQL数据库做不到。如果ACID支持很关键,你必须要确定你选的NoSQL数据库是否提供ACID。

NoSQL数据库的另一个缺点是不支持SQL语言。经过40多年的发展,SQL已经成为访问数据的通用语言。一套数据库系统不支持SQL语言就意味着要求开发者学习不同的访问数据的语言。不过,像有的NoSQL支持ACID一样,有的NoSQL数据库也支持SQL语言,但不像传统关系型数据库那样全面。总之,想要不做重大更改就在NoSQL数据库中运行SQL查询是不可能的。

今天的NoSQL市场依然很混乱。严格来讲,有上百种不同的NoSQL数据库可供选择。而且没有像关系型数据库一样正规的数据模型,因此NoSQL数据库之间也是各不相同的,即便是同一种类也有所不同。这种混乱给NoSQL的广泛应用带来了阻碍,如果没有深度的投资和研发,它很难成功。

NoSQL 数据库用例

让我们分别看一下不同NoSQL数据库的用例:

键值。键值数据库可以满足游戏、零售和移动等应用程序的高可用性、低延迟需求。它的模式比较灵活,在会议管理、服务广告内容和管理用户或产品文件方面有卓越的表现。总之,当数据不是按一定模式,而是包含很多种代码的时候,可以使用键值数据库。

但如果要管理不同数据集之间复杂的关系,或使用非限定的键进行查询,键值数据库的表现就欠佳了。

文档数据库。这种数据库特别适合用于为每一个文档存储不同种类的数据,可以实现跨数据的弹性的搜索。如果你的模式不是网格式的,你又需要指定键之外的东西进行查询,那么文档存储绝对是一个不错的选择。文档数据库适合应用于事件日志,线上购物,内容管理和深度分析流程。对于要求快速原型的项目来说,文档数据库的模式灵活性也是一大亮点。

不过,文档数据库不适合复杂的事务处理。对于要求数据压缩的应用程序来说,文档数据库并不是一个很好的选择,因为弹性模式意味着跨文档的数据不一致,也不可能被有效压缩。

列式存储。这种数据库以列的方式存储数据。与一个键(或识别符)相关的有很多列。和其他NoSQL数据库一样,它的模式很灵活,一个列式家族可以由不同的列组成。另外,列式存储中的数据可以通过列访问,而不是键。

列式存储并不是一个新概念,它的变体过去作为一种概念应用于关系型数据库中(比如SAP Sybase IQ和IBM DB2 BLU)。虽然关系型列式存储也聚焦与列,但它不允许跨行的列有所不同,这是它与NoSQL列式存储不同之处。

对于不经常写,但要频繁地一次读取很多行的几列的情况下,列式存储是很有效率的。对于时间日志、内容管理、分析的计算和分类,列式存储都很有效。如果你有要过期的数据,列式存储非常有用,因为你可以建立一列,让它自动过期。

如果是跨度很广的查询,不要用列式存储,因为你可能不得不重新设计列。另外,列式存储不是很适合ACID事务。

图型数据库。这种数据库可能是和传统数据库以及其他NoSQL数据库区别最大的。图型数据库适用于数据元素之间相互关联,而且彼此之间关系的数量不确定的情况。

图型数据库最常用于社交媒体网络,比如LinkedIn和Facebook。当然也有一些其他的应用程序,比如分配路线和调度、定位系统、公共交通连接、地图、课程计划和网络拓扑结构等。图型数据库的另一个实践在于推荐引擎,常用语在线零售商。

图型数据库不适合用于数据经常改变,常发生大规模数据之间实时更新的情况。另外,如果你计划跨网络分区数据库的话,图型数据库很可能会性能下降。

六大考虑因素

NoSQL数据库之间的很多不同给技术选择带来了难度。不同的数据库类型和产品有不同的架构。即使同样是NoSQL数据库,不同类型之间也有所不同,没有统一标准,即便是访问数据的标准也不相同。这意味着在不同的数据库中访问数据,有不同的工具和应用程序需要采用和学习。以下是需要考虑的一些方面。

快速变化。NoSQL领域是持续变动的,特性不断提升、功能不断增加、甚至会产生新产品。在选择NoSQL数据库时,很难跟上最新最好的功能和产品。

对ACID的支持能力越来越强。NoSQL的一个早期卖点是它支持不要求全部ACID支持的事务。取代ACID,NoSQL提升了最终一致的基本可用软件状态服务(BASE)。虽然如此,很多应用程序依然依赖ACID,NoSQL对ACID事务的支持是用户的需求,也是它自己在不断完善的。

缺少对多平台的支持。大多数NoSQL数据库起源于开源运动,因此基本上都运行在Linux上,(或者Unix的变体)。如果你需要在Windows或者主机上部署数据库,你需要考虑商业产品,因为商业产品对多平台部署的支持性更好。

增加对SQL的支持。没有SQL,查询通常非常基础,可能要求使用高级语言的复杂的代码。当然,产品与产品之间也有所不同,不过最好选择支持SQL的NoSQL数据库,因为很多开发者熟悉的还是SQL语言。

开发多种类型数据库的能力。一些NoSQL数据库允许你用键值对、文档和图型的弹性的组合建模和部署数据。另外,关系型数据库开始采用NoSQL能力。使用能够开发多种类型数据库存储的数据库系统能帮助你的组织获得普适的持久性。

注意技术的版本。很多开源项目运行了很多年,但也没有第一版。这些软件可能很好用,但慎重的公司一般不会选择没有发行第一版的技术。

理解NoSQL数据库

虽然NoSQL数据库现在发展的很火,但该领域仍然面临激烈竞争,日新月异。真正理解NoSQL数据局,需要深入了解不同数据库引擎及其用例。选择了错误的技术很可能导致整个项目的失败。

今天,有很多NoSQL数据库系统得到了成功的应用,一旦应用到正确的地方,它将发挥出无穷的力量。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

作者

Craig S. Mullins
Craig S. Mullins

数据管理策略研究人员,拥有超过30年的数据库系统经验

相关推荐