提供：ZStack云计算
内容简介
NoSQL数据库的存在意义在于提供传统关系数据库管理系统所不具备的特定功能。无论是负责承载简单的键-值对存储以实现短期缓存，抑或是处理传统数据库及结构化查询语言（简称SQL）所难以消化的非结构化集合，NoSQL都能为我们提供巨大的帮助。
在今天的文章中，我们将共同了解各类高人气NoSQL数据库管理系统及其定位与作用，从而帮助我们根据实际应用需求做出明智选择。
词汇表
1. 数据库管理系统
2. NoSQL数据库管理系统
- 基于键/值
- 基于列
- 基于文档
- 基于图形
3. 基于键/值的NoSQL数据库管理系统
- 主流键/值数据库
- 适合用途
4. 基于列的NoSQL数据库管理系统
- 主流列式数据库
- 适合用途
5. 基于文档的NoSQL数据库管理系统
- 主流文档数据库
- 适合用途
6. 基于图形的NoSQL数据库管理系统
- 主流图形数据库
- 适合用途
7. NoSQL数据库管理系统与关系数据库管理系统之对比
- NoSQL数据库适合用途
数据库管理系统
数据库属于逻辑性建模存储空间，负责承载各类不同信息（即数据）。每套数据库（除了无模式数据库以外）皆拥有一套模型，负责提供处理数据所必需的结构。数据库管理系统属于应用程序（或者库），旨在管理不同类型、规模以及形式的数据库方案。
备注：要了解更多与数据库管理系统相关的内容，请参阅了解数据库一文。
NoSQL数据库管理系统
过去十年来，关系数据库管理系统一直成为开发者与系统管理员们的最佳选项，而其理由也相当充分。尽管灵活性并不理想，但RDBMS的强大特性使其能够创建、查询并使用复杂的数据库方案。其能力已经可以满足绝大部分需求，因为长久以来市场上并未出现差异性极大的需求转变。
而“NoSQL”这一名号早在十几年前就已经出现，其强调的含义是“并非”另一种关系数据库。而在其背后则隐藏着完全不同的解决思路：消除对标准SQL的使用。接下来几年中，不过有厂商接过这面大旗并加以推动，隶属于该阵营的多种非关系数据库也开始不断涌现。
从设计角度看，NoSQL数据库与管理系统为非关系型（或者说无模式）设计。它们并非基于单一模式（例如RDBMS的关系模型），而且每款数据库根据自身功能定位都会采用不同的模式。
:NoSQL数据库包含以下几种不同的可选模式及功能系统：
- 键/值:
例如Redis、MemcacheDB等。
- 列式:
例如Cassandra、HBase等。
- 文档:
例如MongoDB、Couchbase等。
- 图形:
例如OrientDB、Neo4J等。
为了更好地理解每种数据库管理系统的角色定位与底层技术，下面对这四种可选模式进行逐一剖析。
键/值数据库
我们首先来讲键/值类数据库管理系统，因为它们较为简单且属于NoSQL实现方案的基础与主干。
这类数据库的工作原理是将键与值进行匹配，具体方式与字典相近。其中不存在结构或者关系。在接入数据库服务器（例如Redis）后，应用能够声明一个键（例如the_answer_to_life）并提供一个与之匹配的值（例如42）。在此之后，当我们提供该键，就能够检索到对应的值。
键/值DBMS通常被用于存储基础性信息，有时候也会存储某些并不基础的执行结果——例如CPU与内存密集型计算结果。其性能极高，效率可观且通常易于扩展。
备注：在计算机当中，字典指的通常是一种特殊的数据对象。其由大量集合数组构成，各数组中包含独立的键与值。
列式数据库
列式NoSQL数据库管理系统在键/值数据库的基础上更进了一步。
尽管互联网上查到的图片看似难以理解，不过此类数据库的工作原理其实非常简单——创建一个或者多个键/值对集合，并共同匹配一条记录。
与传统关系数据库的定义模式不同，列式NoSQL解决方案不需要利用预结构化表实现数据处理。每条记录都附带一个或者多个包含有信息的列，而每条记录中的每个列都可彼此不同。
基本上，列式NoSQL数据库就是大量二维数组，其中每个键（即行/记录）都附加一个或者多个键/值对。此类管理系统能够承载规模庞大的非结构化数据（例如可在单一记录中添加大量信息）。
这些数据库常被用于处理简单键/值对无法完成的任务，并存储总量极大、且承载信息量极多的记录。列式无模式DBMS能够实现极佳的扩展能力。
文档数据库
文档NoSQL数据库管理系统近来可谓人气爆棚。此类DBMS的工作原理与列式数据库基本一致；不过，它们能够实现更为深入的嵌套与更复杂的结构（例如某文档内包含一个文档，后者中又包含另一文档）。
文档数据库克服了列式数据库中键/值嵌套只能分为一到两个层级的限制。基本上，任何复杂结构都可以文档形式体现，并使用此类管理系统加以存储。
尽管自身非常强大，且能够通过个别键进行记录查询，但文档数据库管理系统也有着自己的问题与短板。例如，检索一条记录的值意味着需要对记录的全部内容进行搜索，更新亦是如此——这将极大影响执行性能。
图形数据库
最后来介绍最为有趣的NoSQL数据库管理系统类型——图形数据库。
图形DBMS模式会以完全不同的方式进行数据表示。其采用树状结构（即图形），其中包含大量节点与边界，且彼此间通过关系实现对接。
与数学计算类似，特定操作能够在此类模式中得以轻松实现，而这主要归功于相关信息片段的分组与连接方式（例如相关联系人）。
这类数据库常用于需要具备明确边界并实现必要连接的应用场景。例如当我们注册任何形式的社交网站时，其中都会提供“与朋友的朋友结识”之类的功能，这正是图形数据库管理系统的最佳施展平台。
键/值NoSQL数据库管理系统
键/值数据存储拥有出色的性能表现、易用性及可扩展能力。
主流键/值NoSQL数据库管理系统
部分主流键/值数据存储方案包括：
- Redis:
内存内键/值存储且提供持久性选项。
- Riak:
高分布式副本型键/值存储方案。
- Memcached / MemcacheDB:
基于键/值存储机制的分布式内存方案。
合适用途
合适的用途包括：
- 缓存:
快速存储数据以备未来使用。
- 队列:
部分键/值存储机制（例如Redis）支持列表、集合以及队列等功能。
- 分发信息/任务：
可用于实现Pub/Sub。
- 保存实时信息。
需要保持状态的应用可以利用键/值存储轻松实现。
列式NoSQL数据库管理系统
列式数据存储方案非常强大且能够用于保存规模庞大的重要数据。尽管在“灵活性”方面有所欠缺，但其主要卖点在于高功能性与高性能水平。
主流列式数据库
主流列式数据库包括：
- Cassandra:
基于BigTable与DynamoDB的列式数据存储方案。
- HBase:
源自BigTable设计灵感且面向Apache Hadoop的数据存储方案。
合适用途
合适用途包括：
- 保存非结构化非易失性信息：
如果需要对大量任意集合及值进行长期保存，那么列式数据存储方案将是最好的选择。
- 扩展能力：
列式数据存储方案天然拥有出色的可扩展能力，且能够处理总量极为庞大的信息。
文档NoSQL数据库管理系统
文档数据存储方案非常适用承载大量不相关且结构差别很大的复杂信息。
主流文档数据库
主流文档数据库包括：
- Couchbase:
基于JSON且与Memcached相兼容的文档数据存储方案。
- CouchDB:
一款突破性的文档数据存储方案。
- MongoDB:
一款极具人气且功能丰富的数据库选项。
合适用途
合适用途包括：
- 嵌套信息:
文档数据存储方案允许大家处理深层嵌套的复杂数据结构。
- JavaScript友好性:
文档数据存储方案的最大特色在于其与应用程序的对接方式：采用具备JavaScript友好性的JSON。
图形NoSQL数据库管理系统
图形数据存储方案能够提供与前几种DBMS完全不同的功能。
主流图形数据库
主流图形数据库包括：
- OrientDB:
一款速度很快的图形与文档混合NoSQL数据存储方案，由Java编写而成且拥有多种操作模式。
- Neo4J:
一款无模式高人气Java图形数据存储方案。
合适用途
合适用途包括：
- 处理复杂的关系型信息：
正如之前提到，图形数据库能够极为高效地轻松地处理复杂的关系型信息，例如两个条目间的对接以及与其相关联的其它更多条目。
- 分类的建模与处理：
图形数据库擅长处理任何涉及关系的状况。数据建模以及立足于关系实现信息分类都属于此类情况。
NoSQL DMBS与关系DBMS之比较
为了更加明确地了解NoSQL解决方案与关系数据库管理系统的不同，让我们对二者进行比较：
NoSQL数据库合适用途
- 规模是关键：
如果需要处理大量数据集，那么可扩展能力更强的NoSQL家族将更胜一筹。
- 速度:
NoSQL数据库通常速度更快，特别是在写入层面。其选取速度通常也非常出色，且具体取决于NoSQL数据库本身以及所查询数据的类型。
- 无模式设计：
关系DBMS从设计之初就需要结构与之配合。而NoSQL解决方案则拥有更可观的灵活空间。
- 自动（或者轻松）实现复制/规模伸缩：
NoSQL数据库发展迅猛且立足于当下——各厂商都在努力解决各类常见问题，特别是复制与规模伸缩需求。与RDBMS不同，NoSQL解决方案能够轻松实现集群内规模调整。
- 多种选项:
在选择NoSQL数据存储方案时，可供挑选的模式多种多样。大家可以根据之前提到的特性，立足于实际数据类型做出决策。
本文来源自DigitalOcean Community。英文原文：A Comparison Of NoSQL Database Management Systems And Models By O.S. Tezer
翻译：diradw
原文地址;https://blog.csdn.net/zstack_org/article/details/55504931