NoSQL 数据库

NoSQL 数据库

一、出现背景

首先要提一下数据库的应用场景，实际应用中数据库部署在服务器上，服务器得到客户端传来的前端数据后，将数据交由业务逻辑层处理，业务逻辑层访问数据库取出数据。这样的架构逻辑决定了任何一个阶段性能不够都将制约整个流程的性能与用户体验。

互联网的飞速发展，对高并发、低延时的需求越来越高。然而传统数据库的访问效率逐渐不能满足需求。在此情况下，传统数据库必然需要进行优化升级，比如优化 SQL 语句、数据库读写分离等。但当下软件系统复杂的业务逻辑使得耦合度提高，传统数据库的升级面临很大瓶颈，维护成本也会变高。

大数据时代到来，若仍然采用传统数据库纵向扩展方式，则需要很大的单台服务器存放，采购成本高，维护难度高。单台服务器配置存在技术上的天花板，存储空间不能无限大。

如今数据无处不在，如何提取有效数据，于是便催生了数据挖掘研究的迅速发展，传统 SQL 数据库不适合相关研究。

需求决定供给，高并发、低延时、易扩展 等需求催生了 NoSQL 数据库的出现于流行。NoSQL 数据库访问高效，方便大数据处理，也为动辄几百上千 QPS 的并发量提供了很好的解决方案。另外，单台数据库存储空间瓶颈使得海量数据只能采用集群环境存储，NoSQL 数据库不同于传统数据库的易扩展性无疑提升了其竞争力。

二、特点

与传统的关系型数据库相比，NoSQL 数据库有以下特点：

• 非持久化，部分 NoSQL 数据库是纯内存存储的；
• 存储方式与传统数据库不同，NoSQL 数据库有列式存储、key/value存储、文档型存储以及图结构存储等；
• 无 SQL 语言，没有 SQL 语言操作接口，NoSQL 系统有自己特有的 API 接口；
• 结构自然，采用文档模型，数据表达方式更自然，与关系型数据库中表结构不同，文档中可以嵌入数组和子文档。
• 集群设计，NoSQL 系统用于服务器集群环境，并非共享性数据库架构；
• 存储位置不确定，出于架构原因，NoSQL 数据库系统下，会有不知道数据存在哪里的情况；
• 弱一致性，系统中的某个数据被更新后，后续对该数据的读取操作可能得到更新后的值，也可能是更改前的值；
• 数据压缩性能高，压缩比可达到五倍以上，极大节约磁盘空间。

三、优势与缺点

优势

1. 读写效率高：逻辑简单，纯内存操作，性能出色，单节点每秒可以处理超过10万次读写操作，适合高并发、低延时的应用场景。更简单的数据访问模式也让开发者更容易理解数据库的性能表现，尤其是当涉及到索引时;
2. 易于扩展：NoSQL 数据库的存储方式使其易于扩展，而且更加适合集群环境的数据存储扩展调度；
3. 易于维护：NoSQL 没有过多的操作，使得系统各部分之间耦合度低，尤其是非结构化以及半结构化的数据，修改灵活，易于维护与修改；
4. 可用性高、负载均衡：NoSQL 有自己业务的副本集和驱动程序，可以非常有效和方便地实现高可用，读负载均衡；
5. 开源：大部分分布式数据库系统为开源软件，项目开发测试与部署成本低。

缺点

1. 功能有限：目前 NoSQL 产品功能不够完善，大部分不支持事务操作；
2. 不够成熟：大部分 NoSQL 产品尚处于初创阶段，与传统的关系型数据库相比差距很大；
3. 不兼容 SQL：对于占据市场几十载的 SQL 标准不支持，使得已有应用的迁移困难较大；
4. 学习成本高：对于习惯了传统数据库系统的使用者来说，学习 NoSQL 的成本较高。

四、NoSQL 数据库分类

分类	举例	典型应用场景	数据模型	优点	缺点
键值（key-value）	Tokyo Cabinet/Tyrant， Redis， Voldemort， Oracle BDB	内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统等等	Key 指向 Value 的键值对，通常用hash table来实现	查找速度快	数据无结构化，通常只被当作字符串或者二进制数据
列存储数据库	Cassandra， HBase， Riak	分布式的文件系统	以列簇式存储，将同一列数据存在一起	查找速度快，可扩展性强，更容易进行分布式扩展	功能相对局限
文档型数据库	CouchDB， MongoDb	Web应用（与Key-Value类似，Value是结构化的，不同的是数据库能够了解Value的内容）	Key-Value对应的键值对，Value为结构化数据	数据结构要求不严格，表结构可变，不需要像关系型数据库一样需要预先定义表结构	查询性能不高，而且缺乏统一的查询语法。
图形(Graph)数据库	Neo4J， InfoGrid， Infinite Graph	社交网络，推荐系统等。专注于构建关系图谱	图结构	利用图结构相关算法。比如最短路径寻址，N度关系查找等	很多时候需要对整个图做计算才能得出需要的信息，而且这种结构不太好做分布式的集群方案。

1. 键值数据库

   键值数据库类似传统语言中使用的哈希表。你可以通过key来添加、查询或者删除数据，因此有很好的性能及扩展性。

   适用的场景
   储存用户信息，比如会话、配置文件、参数、购物车等，这些信息一般都和ID（键）相关。

   不适用场景
   通过值来查询，Key-Value数据库中没有通过值查询的途径;
   需要储存数据之间的关系，在Key-Value数据库中不能通过两个或以上的键来关联数据;
   事务，在Key-Value数据库中故障产生时不可以进行回滚。

2. 列存储数据库

   列存储数据库将数据储存在列族中，一个列族存储经常被一起查询的相关数据。

   适用的场景
   日志，因为我们可以将数据储存在不同的列中，每个应用程序可以将信息写入自己的列族中；
   博客平台，我们储存每个信息到不同的列族中。

   不适用场景
   ACID事务，比如 Vassandra 就不支持事务；
   原型设计，在模型设计之初，我们不能去预测它的查询方式，而一旦查询方式改变，我们就必须重新设计列族。

3. 文档型数据库

   面向文档数据库会将数据以文档的形式储存，每个文档都是自包含的数据单元，是一系列数据项的集合。每个数据项都有一个名称与对应的值，值既可以是简单的数据类型，也可以是复杂的类型。数据存储的最小单位是文档，同一个表中存储的文档属性可以是不同的，数据可以使用XML、JSON或者JSONB等多种形式存储。

   适用的场景
   日志，没有固定的模式，故可以使用它储存不同的信息；
   分析，鉴于它的弱模式结构，不改变模式下就可以储存不同的度量方法及添加新的度量。

   不适用场景
   在不同的文档上添加事务。不支持文档间的事务，如果对这方面有需求则不应该选用这个解决方案。

4. 图数据库

   图数据库允许我们将数据以图的方式储存。实体会被作为节点，而实体之间的关系则会被作为边。

   适用的场景
   一些关系性强的数据中；
   推荐引擎，如果我们将数据以图的形式表现，那么将会非常有益于推荐的制定。

   不适用场景
   不适合的数据模型，图数据库的适用范围很小，因为很少有操作涉及到整个图。