NoSQL数据尝试着提供那些关系数据库所不能提供的功能,无论是为了存储简单的键值对(key-value),更短的时间长度,高速缓存,还是保持数据的非结构化集合(比如collections),这些都是在关系型数据库和SQL(Structured Query Language)中很难实现的。
在这篇DigitalOcean的文章中,我们将介绍各种流行的NoSQL数据库系统,介绍他们的作用以及功能,因而帮助你,根据你的易用系统的需求来决定选择哪一个NoSQL数据库。
基于键/值
基于列
基于文档
基于图形
流行的基于键/值的数据库
何时使用
流行的基于列的数据库
何时使用
流行的基于文档的数据库
何时使用
流行的基于图形的数据库
何时使用
何时使用 NoSQL Databases
数据库是为各种不同的信息(数据)提供逻辑上模型化的存储空间。除了无模式以外的每个数据库,都有一个模型为所处理的数据提供结构。数据库管理系统是管理各种形状,大小和类型的数据库的应用程序(或库)。
注: 要学习更多数据库管理系统知识, 请查阅我们的文章: 了解数据库(http://link_to_10_1_understanding_databases).
其它翻译版本 (1) 加载中NoSQL 数据库管理系统
在过去的十年里,针对各种应用,基于各种理由,大部分开发人员或系统管理员都选择了关系型数据。尽管没有足够的灵活性,但是由于非常多的关系型数据库(RDBMS)的强大的特性,允许创建,查询以及使用复杂的数据库,已经足以应对绝大多数的需求。但是一直到不久前,各种不同的需求开始大量上升。
"NoSQL"这个概念是在十年前提出的,很有意思的是NoSQL被认定为另外一种关系数据库,然而在NoSQL背后是有不同的想法的,就是摈弃标准化SQL的使用。把各种其他的非关系型数据库作为NoSQL数据库的这种想法,在未来的几年里,这种思想会持续的增长的。
其它翻译版本 (1) 加载中从设计上,NoSQL 数据库和管理系统都是非关系型(也称非范式型)的。它们并非基于同一种模型(如关系型数据库的关系模型),而是每种数据库依据其不同的功能目标,选择了不同的模型。
NoSQL 数据库不同的操作模型和功能系统几乎有一大把:
键 / 值:
如 Redis,MemcacheDB等。
列:
如 Cassandra,HBase等。
文档:
如 MongoDB,Couchbase等。
图形:
如 OrientDB,Neo4J等。
为了更好地理解每种数据库管理系统的不同角色和底层技术,我们快速地过一遍这4种操作模型吧。
在我们了解 NoSQL 模型的旅程中,第一站先来到基于键/值对的数据库系统,因为这可以说是最基础和最骨干的 NoSQL 实现。
这一类的数据库的原理在于键值对应,类似字典类型(dictionary)。其中没有结构,也没有关系。在连接上数据库服务器(如 Redis)后,应用程序可以声明一个键(如 the_answer_to_life),并且给出对应的值(如 42)。此后只要提供同样的键,就能检索出这个值。
键/值数据库系统一般是用来快速存储基础信息的,有时也用来存储不那么基础的信息——之前经过处理,例如,CPU 和内存的密集计算。这类数据库极其快速,效率很高,并且通常很容易扩展。
注:在计算机术语中,字典类型通常指的是一种特定的数据对象。这种类型由一系列独立的键值对集合组成。
其它翻译版本 (1) 加载中列存储的NoSQL数据管理系统是基于简单的键/值对来实现的。
尽管在网上看起来非常复杂并且难以理解,但这些数据库创建集合却非常简单,它们使用键/值对来匹配一条记录。
不像传统的关系型数据库那样需要定义模式,列存储的NoSQL数据库不需要提前知道数据的结构,它们可以直接插入含有一列或者多列的记录,而且每条记录包含的列属性可以不同。
其它翻译版本 (1) 加载中基本上,基于列的NoSQL数据库就是个二维数组,每个键(即 行/记录)都连接有一个或多个 键/值对,这些管理系统允许非常巨大和非结构化的数据被保存和使用(例如有非常多信息的记录)。
这些数据库通常用在当必须存储大量信息记录,简单的 键/值对 不足以应对时。基于列实现的数据库管理系统,模式自由的模型,扩容性非常好。
基于文档的 NoSQL 数据库系统,就像一波瞬间席卷了许多人的最新潮流。这类数据库系统工作原理与基于列的数据库类似;然而,它们支持更深层的嵌套,能得到复杂的结构(例如,文档包含在一个文档里,而这个文档又包含在另一个文档里)。
文档克服了基于列的数据库中键/值嵌套只能有一级或两级的限制。基本上,无论多么复杂、无论什么形态的结构都能形成一个文档,而文档就可以用这类数据库系统来储存。
尽管它们有这样强大的特性,并且支持以独立的键来查询记录,基于文档的数据库系统相比其他系统仍然有自己的问题和不足之处。例如,检索记录中的一个值就需要牵扯出整个记录,update 也是如此,而这都会严重地影响性能。
最后来看看 NoSQL 数据库系统中的奇葩——基于图形的系统。
基于图形的数据库系统模型表示数据的方式与上文提到的三种模型截然不同。他们使用树形的结构(也就是所说的“图形”),包括结点和通过关系(relation)相互连接的边。
与数学类似,某些特定操作在这类模型上会格外简单。这要感谢树形结构能链接信息、将相关信息(例如相关联的人)分组的本质。
这类数据库通常应用于关系(connection)需要建立明确边界的场景。例如,当你注册随便一个社交网络时,你朋友与你的关系,和他们朋友的朋友与你的关系,使用基于图形的数据库系统来处理会简单很多。
键/值型的数据存储往往表现很好,容易使用,并且通常有很好的扩展性。
一些流行的基于键/值的数据存储如下:
Redis:
内存中的键/值存储,附有可选的持久化功能。
Riak:
高度分布式的,自我复制(replicated)的键/值存储。
Memcached / MemcacheDB:
基于内存的分布式键/值存储。
基于键/值的数据存储一些常见的使用场景有:
缓存:
快速缓存数据,以供将来——可能是频繁地——使用。
用作队列:
部分键/值存储(例如 Redis)支持list,set,queue等类型。
分布式信息 / 任务处理:
可以用来实现观察者/发布订阅(Pub/Sub)模式。
保存活跃状态信息:
需要维护一个状态的应用很适合使用键/值存储。
基于列的数据存储非常强大,它们能够可靠地存储非常大规模的重要数据。尽管在数据的组成方面并不“灵活”,这类数据库仍然功能强大,性能良好。
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。2KB项目(www.2kb.com,源码交易平台),提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务