NoSQL数据尝试着提供那些关系数据库所不能提供的功能,无论是为了存储简单的键值对(key-value)，更短的时间长度，高速缓存，还是保持数据的非结构化集合(比如collections)，这些都是在关系型数据库和SQL（Structured Query Language)中很难实现的。
在这篇DigitalOcean的文章中，我们将介绍各种流行的NoSQL数据库系统，介绍他们的作用以及功能，因而帮助你，根据你的易用系统的需求来决定选择哪一个NoSQL数据库。
基于键/值
基于列
基于文档
基于图形
流行的基于键/值的数据库
何时使用
流行的基于列的数据库
何时使用
流行的基于文件的数据库
何时使用
流行的基于图形的数据库
何时使用
何时使用 NoSQL Databases
数据库是为各种不同的信息（数据）提供逻辑上模型化的存储空间。除了无模式以外的每个数据库，都有一个模型为所处理的数据提供结构。数据库管理系统是管理各种形状，大小和类型的数据库的应用程序（或库）。
注: 要学习更多数据库管理系统知识, 请查阅我们的文章: 了解数据库（http://link_to_10_1_understanding_databases）.
在过去的十年左右中，关系数据库管理系统因为各种各样的理由已被开发人员和系统管理员选择用于各种各样的应用程序中。尽管并不完全灵活，许多关系数据库管理系统的强大的性质允许复杂的数据库体制被创建，查询和使用。这甚至超过许多需求的要求，直到不久以前，不同的需求开始上升才发生逆转。
术语“NoSQL”一词是在十年前被创造的，有趣的是，它是作为另一个关系数据库的名称。然而，该数据库在背后有一个不同的想法：消除标准化的SQL的使用。在接下来的几年，别人拾起并通过借鉴其他各种非关系型数据库继续发展了这一思想成为 NoSQL 数据库 。
从设计上，NoSQL 数据库和管理系统都是非关系型（也称非范式型）的。它们并非基于同一种模型（如关系型数据库的关系模型），而是每种数据库依据其不同的功能目标，选择了不同的模型。
NoSQL 数据库不同的操作模型和功能系统几乎有一大把：
键 / 值:
如 Redis，MemcacheDB等。
列:
如 Cassandra，HBase等。
文档:
如 MongoDB，Couchbase等。
图形:
如 OrientDB，Neo4J等。
为了更好地理解每种数据库管理系统的不同角色和底层技术，我们快速地过一遍这4种操作模型吧。
基于键值
我们将要开始我们的NoSQL模型之旅，它是基于键值的数据库管理系统，因为可以把它视为是实现NoSQL的基础和骨架。
该类型的数据库通过关键字与值的映射来工作，有点类似字典。没有结构也没有关系。连接到数据库服务器（例如Redis）以后，应用程序陈述一个关键字如the_answer_to_life并提供也这对应的值如42，这个值随后可以通过提供的关键字以相同的方式搜索。
键值数据库通常用于快速的存储基本信息，有时是一些处理过的非基本的，例如CPU和内存密集的计算。它们的表现非常好，性能高，且通常易于扩展。
注意：在计算机领域，字典通常指特定类型的数据对象。它们由键值对数组构成。
基于列
基于列的NoSQL数据库管理系统通过提升基于键值的简单本质来工作。
虽然在互联网中它们难于理解，但是这些数据库的工作机制相当的简单，通过创建一个或者多个键值对的集合来与记录相匹配。
不像传统的关系数据库定义了模式，基于列的NoSQL解决方案不需要预定义表结构就可以处理数据。每条记录有一列或者多列，这些列包含了信息，每个记录的每列都可能是不相同的。
基本上，基于列的NoSQL数据库就是个二维数组，每个键（即 行/记录）都连接有一个或多个 键/值对，这些管理系统允许非常巨大和非结构化的数据被保存和使用（例如有非常多信息的记录）。
这些数据库通常用在当必须存储大量信息记录，简单的 键/值对 不足以应对时。基于列实现的数据库管理系统，模式自由的模型，扩容性非常好。
基于文档的 NoSQL 数据库系统，就像一波瞬间席卷了许多人的最新潮流。这类数据库系统工作原理与基于列的数据库类似；然而，它们支持更深层的嵌套，能得到复杂的结构（例如，文档包含在一个文档里，而这个文档又包含在另一个文档里）。
文档克服了基于列的数据库中键/值嵌套只能有一级或两级的限制。基本上，无论多么复杂、无论什么形态的结构都能形成一个文档，而文档就可以用这类数据库系统来储存。
尽管它们有这样强大的特性，并且支持以独立的键来查询记录，基于文档的数据库系统相比其他系统仍然有自己的问题和不足之处。例如，检索记录中的一个值就需要牵扯出整个记录，update 也是如此，而这都会严重地影响性能。
最后来看看 NoSQL 数据库系统中的奇葩——基于图形的系统。
基于图形的数据库系统模型表示数据的方式与上文提到的三种模型截然不同。他们使用树形的结构（也就是所说的“图形”），包括结点和通过关系（relation）相互连接的边。
与数学类似，某些特定操作在这类模型上会格外简单。这要感谢树形结构能链接信息、将相关信息（例如相关联的人）分组的本质。
这类数据库通常应用于关系（connection）需要建立明确边界的场景。例如，当你注册随便一个社交网络时，你朋友与你的关系，和他们朋友的朋友与你的关系，使用基于图形的数据库系统来处理会简单很多。
键/值型的数据存储往往表现很好，容易使用，并且通常有很好的扩展性。
一些流行的基于键/值的数据存储如下:
Redis:
内存中的键/值存储，附有可选的持久化功能。
Riak:
高度分布式的，自我复制（replicated）的键/值存储。
Memcached / MemcacheDB:
基于内存的分布式键/值存储。
基于键/值的数据存储一些常见的使用场景有：
缓存:
快速缓存数据，以供将来——可能是频繁地——使用。
用作队列:
部分键/值存储（例如 Redis）支持list，set，queue等类型。
分布式信息 / 任务处理:
可以用来实现观察者/发布订阅（Pub/Sub）模式。
保存活跃状态信息:
需要维护一个状态的应用很适合使用键/值存储。
基于列的数据存储非常强大，它们能够可靠地存储非常大规模的重要数据。尽管在数据的组成方面并不“灵活”，这类数据库仍然功能强大，性能良好。
一些流行的基于列的数据存储有:
Cassandra:
建立在 BigTable 和 DynamoDB 基础上的基于列的数据存储。
HBase:
为 Apache Hadoop 设计的数据存储，创意来自 BigTable。
基于列的数据存储的一些流行用例:
保存非结构化和非易失性的信息:
如果需要长时间保存一个巨大的属性和值的集合，基于列的数据存储是非常方便的。
扩容:
基于列的数据存储天生是高度可扩容的。他们可以处理那些有可怕数量的信息。
基于文件的数据存储非常适于保存许多不相关的复杂信息，不同结构之间可以有高度的可变性。
流行的一些基于文件的数据存储:
Couchbase:
基于JSON, 兼容“内存缓冲”的基于文件的数据存储。
CouchDB:
一个冲破性的基于文件的数据存储。
MongoDB:
一个非常流行和功能很好的数据库。
使用基于文件的数据存储的一些普遍情况:
嵌套的信息:
基于文件的数据存储允许很深的嵌套，和复杂的数据结构。
JavaScript友好性:
基于文件的数据存储的最具决定性的功能之一是他们与应用程序交互的方式：利用对JS友好的JSON。
基于图形的数据存储提供了一个非常独特的功能，是任何其他数据库管理系统无法相比的。
一些流行的基于图形的数据库如下:
OrientDB:
一个非常快速的基于图形和文档的混合 NoSQL 数据存储，使用 Java 编写，包含几种不同的操作模式。
Neo4J:
一个非范式的，基于图形的 Java 编写的数据存储，非常热门而强大。
基于图形的数据库一些常见的使用情景如下：
处理复杂的关联信息:
如同在简介中说过的一样，图形数据库在处理复杂但相关联的信息方面极其高效而易用。例如两个实体和与它们不同层次间接连接的实体之间的关联。
建模和处理分类:
图形数据库尤擅牵涉到关系的各种情形。以关系的方式来建模数据、为各种数据分类，用这类数据库可以处理得很好。
为了对NoSQL解决方案不同于关系数据库管理系统之处有一个清晰画面，让我们创建一个快速的比较表:
尺寸问题:
如果将具有非常大的数据集，来自NoSQL家族的数据库管理系统更容易实现持续扩容。
速度:
NoSQL数据库通常更快，对于写入来说有时非常快。读取也可以很快，这取决于NoSQL数据库的类型和查询的数据。
Schema-free 的设计:
关系数据库管理系统从一开始就需要结构化。NoSQL解决方案提供了大量的灵活性。
自动（或简单的复制/扩容）:
NoSQL数据库正在迅速增长，今天他们正在积极建立-厂商试图解决共同的问题，其中一个显然是复制和缩放。不像关系数据库管理系统那样，NoSQL解决方案可以很容易的在簇上扩容和工作。
多重选择:
当来选择一个NoSQL数据存储时，正如我们已经讨论的，有多种模式，你可以从中选择获得最满意的数据库管理系统——这取决于你的数据类型。
原文地址：https://www.digitalocean.com/community/articles/a-comparison-of-nosql-database-management-systems-and-models
京公网安备 11010802040832号 | 京ICP备19059560号-6 