关于NoSQL数据库的一切，终于说清楚了

NoSQL 不仅仅是 SQL它是 Not Only SQL 的缩写也是众多非关系型数据库的统称。NoSQL 和关系型数据库一样也是用来存储数据的仓库。为什么需要使用 NoSQL随着互联网的高速发展数据量、访问量呈爆发式增长人们对网络的需求逐渐多样化。比如通过 QQ、微信、微博等进行聊天互动刷朋友圈点赞互评又如通过各大视频网站、音乐网站看视频、看直播、听音乐等这么多数据都是需要存储的。然而传统的关系型数据库面对这些海量数据的存储以及实现高访问量、高并发读/写就会显得力不从心尤其是当面对超大规模、高并发、高吞吐量的大型动态网站的时候就会暴露出很多难以克服的问题影响用户体验。为了满足对海量数据的高速存储需求实现高并发、高吞吐量NoSQL 应运而生。NoSQL 的出现可以解决传统关系型数据库所不能解决的问题。1) NoSQL 解决了高并发读/写问题Web 2.0 动态网站需要根据用户的个性化信息来实时生成动态页面和提供动态信息而无法使用动态页面的静态化技术因此数据库的并发负载就会非常高。比如微博、朋友圈的实时更新就会出现每秒上万次的读/写需求。关系型数据库在面对每秒上万次的 SQL 查询操作时还能应对自如但是在面对每秒上万次的 SQL 写操作时就难以胜任了。普通的 BBS 系统网站也存在高并发读/写的需求比如实时统计在线人数、记录热门帖子的浏览次数等当面对这些需求时传统的关系型数据库就会出现大量问题。2) NoSQL 解决了海量数据的高效率存储和访问问题面对实时产生的大数据量的存储与查询关系型数据库是难以应付的会显得效率非常低而利用 NoSQL 的高效存储与查询能力就能解决这个问题。3) NoSQL 实现了高可用性及高可扩展性在基于 Web 的架构中关系型数据库难以进行横向扩展。当一个网站系统的用户量和访问量与日俱增的时候数据库没有办法像 Web 服务器或应用服务器那样通过添加更多的硬件来搭建负载均衡的服务器。对于很多提供 24 小时不间断服务的网站来说对数据库系统的维护升级和扩展是非常折磨人的一件事往往需要停机维护和数据迁移。NoSQL 的出现解决了大规模数据库集中和数据种类不同所带来的各种问题尤其是大数据实现的困难。常见的 NoSQL 如下图所示。图1常见的 NoSQL 数据库LogoNoSQL 具有如下特点容易扩展方便使用数据之间没有关系。数据模型非常灵活无须提前为要存储的数据建立字段类型随时可以存储自定义的数据格式。适合大数据量、高性能的存储。具有高并发读/写、高可用性。NoSQL 与传统关系型数据库的比较相信大家对传统关系型数据库都不陌生我们常常使用的关系型数据库有 MySQL、Oracle、SQL Server、SQLite、DB2、Teradata、Infomix、Sybase、PostgreSQL、Access、FoxPro 等。我们将通过以下几个方面来比较 NoSQL 与传统关系型数据库。1) 使用成本NoSQLNoSQL 使用简单易搭建大部分是开源软件比较廉价任何人都可以使用。关系型数据库相对于 NoSQL关系型数据库通常需要安装部署开源的比较少使用成本比较昂贵。尤其是 Oracle 数据库需要花费大量资金购买使用成本比较高。2) 存储形式NoSQLNoSQL 具有丰富的存储形式如 key-value键值对形式、图结构形式、文档形式、列簇形式等因此它可以存储各种类型的数据。关系型数据库关系型数据库是采用关系型数据模型来组织的它是行列表结构通过行与列的二元形式表示出来数据之间有很强的关联性。它采用二维表结构的形式对数据进行持久存储。3) 查询速度NoSQLNoSQL 将数据存储在系统的缓存中不需要经过 SQL 层的解析因此查询效率很高。关系型数据库关系型数据库将数据存储在系统的硬盘中在查询的时候需要经过 SQL 层的解析然后读入内存实现查询因此查询效率较低。4) 扩展性NoSQLNoSQL 去掉了传统关系型数据库表与字段之间的关系实现了真正意义上的扩展。它采用键值对的形式存储数据消除了数据之间的耦合性因此易扩展。关系型数据库由于关系型数据库采用关系型数据模型来存储数据数据与数据之间的关联性较强存在耦合性因此不易扩展。尤其是存在多表连接join查询机制的限制使得扩展很难实现。5) 是否支持 ACID 特性ACID 特性是指数据库事务的执行要素包括原子性、一致性、隔离性、持久性。NoSQLNoSQL 一般不支持 ACID 特性它实现最终一致性。关系型数据库关系型数据库支持 ACID 特性具有严格的数据一致性。6) 是否支持 SQL 语句NoSQLSQL 语句在 NoSQL 中是不被支持的NoSQL 没有声明性查询语言且没有预定义的模式。关系型数据库关系型数据库支持 SQL 语句也支持复杂查询。SQL 是结构化查询语言、数据操纵语言、数据定义语言。NoSQL 与传统关系型数据库是互补的关系对方的劣势就是自己的优势反之亦然。在什么应用场景下使用NoSQLNoSQL 的应用场景比较广泛下面简单说一下比较适合使用 NoSQL 的几个场景。对于大数据量、高并发的存储系统及相关应用。对于一些数据模型比较简单的相关应用。对数据一致性要求不是很高的业务场景。对于给定 key 来映射一些复杂值的环境。对一些大型系统的日志信息的存储。存储用户信息如大型电商系统的购物车、会话等。对于多数据源的数据存储。对易变化、热点高频信息、关键字等信息的存储。以上这些相关业务场景都可以使用 NoSQL 来存储。NoSQL 还有很多其他应用在此不再细述请读者自行参考其他相关资料。NoSQL 的数据模型我们知道关系型数据库的数据模型由数据结构、数据操作及完整性约束条件组成。同样NoSQL 也有其相关的数据模型。NoSQL 的 4 种数据模型如下。1) 键值对数据模型键值对数据模型就是采用键值对形式将数据存储在一张哈希表中的一类数据库这张哈希表具有一个特定的键和一个指向特定数据的指针。键值对存储中的值可以是任意类型的值如数字、字符串也可以是封装在对象中的新的键值对。2) 列数据模型列数据模型就是将数据按照列簇形式来存储的一类数据库通常用于存储分布式系统的海量数据。它也有键这些键指向多个列由数据库的列簇来统一安排。3) 文档数据模型文档数据模型以文档形式进行存储它是键值对数据模型的升级版是版本化的文档。它可以使用模式来指定某个文档结构通常采用特定格式来存储半结构化的文档最常使用的存储格式是 XML、JSON。每个文档都是自包含的数据单元是一系列数据项的集合。4) 图数据模型图数据模型采用图结构形式存储数据它是最复杂的 NoSQL常被用于存储一些社交网络的社交关系适用于存储高度互联的数据。它由多个节点和多条边组成节点表示实体边表示两个实体之间的关系。其中键值对数据模型、列数据模型、文档数据模型统称为聚合模型它们有一个共同特点可以把一组相互关联的对象看作一个整体单元来操作通常把这个单元称为一个聚合。NoSQL 数据库的分类NoSQL 数据库的种类繁多它所存储的数据类型也是各异的。在实际应用中企业往往会根据不同的业务场景来选择不同的 NoSQL 数据库比如一个大型社交系统可能需要使用多种 NoSQL 数据库才能满足业务需求。本文我们就详细介绍一下 NoSQL 数据库的分类以便帮助读者在实际应用中选择不同的 NoSQL 数据库来实现不同的业务需求。NoSQL 数据库大致可以分为四大类分别如下。1) 键值对存储数据库主要采用键值对形式存储数据的一类数据库。典型代表Redis由 C/C 语言开发、Memcached、Voldemort、Berkeley DB、Tokyo Cabinet/Tyrant 等。当采用该类数据库存储数据时需要定义数据结构半结构化才能进行存储。2) 面向列存储数据库主要按照列存储数据的一类数据库。典型代表HBase由 Java 语言开发、Cassandra由 Java 语言开发、Riak由 Erlang 语言、C语言及 JavaScript 组合开发等。当采用该类数据库存储数据时需要定义数据结构半结构化才能进行存储。3) 面向文档数据库主要用于存储文档的一类数据库。文档也是它的最小单元同一张表中存储的文档属性可以是多样化的数据可以采用 XML、JSON、JSONB 等多种格式存储。典型代表MongoDB由 C 语言开发、CouchDB由 Erlang 语言开发、RavenDB 等。当采用该类数据库存储数据时不需要定义数据结构非结构化就可以存储。4) 面向图形数据库主要用于存储图片信息的一类数据库。典型代表Neo4j由 Java 语言开发、InfoGrid、Infinite Graph 等。目前NoSQL 数据库的使用场景比较广泛很多企业都会根据自己相关的业务场景来使用各类 NoSQL 数据库或者混合使用它们。各类 NoSQL 数据库的比较前面说了那么多关于 NoSQL 数据库的相关知识接下来我们就来比较一下各类 NoSQL 数据库的优缺点以方便在实际应用中正确选择合适的数据库如下表所示。表1各类 NoSQL 数据库的比较分类数据模型优点缺点适用场景不适用场景键值对存储数据库一系列 key 指向 value 的键值对通过采用哈希表来实现査询速度快保存速度快兼具临时性和永久性数据无结构通常只被当作字符串或二进制数据当进行临时性保存时数据有可能丢失做高速缓存实现大数据量的存储与访问缓存日志做日志缓存系统存储用户信息如购物车、会话等不适用于通过值来査询的业务不适用于需要存储数据之间关系的业务需要对事务提供支持在遇到故障时事务不可以回滚面向 列存储数据库采用列簇形式存储将同一列数据存放在一起査询速度快擅长以列为单位读入数据可扩展性强尤其是分布式扩展功能相对同限做分布式文件系统存储日志信息不适用于需要实现 ACID 相关事务的业务面向文档数据库釆用文档形式存储也可以看作一系列键值对它的每个数据项都有对应的名称和值无须定义表结构表结构可变对数据结构要求不严格可以使用复杂的査询条件査询性能不高缺乏统一的查询语法Web应用与 key-value 类似value 是结构化的不同的是数据库可以了解 value 的内容存储日志信息 做相关业务的分析在存储文档数据 时需要在不同的文档上添加事务时不适用面向图形数据库釆用图结构形式存储实体是一个节点节点之间的关系是边具有很多图结构算法的支持如最短路径算法、最小生成树算法等为了得到结果需要对整个图形进行计算不利于做分布式应用适用范围有限应用于大型社交网络做相关推荐系统面对一些关系性强的数据不适用于存储非图结构的