一、相关概念
-
RDBMS(Relational Database Management System)：
- 指的就是关系数据库管理系统
- 是指包括相互联系的逻辑组织和存取这些数据的一套程序 (数据库管理系统软件)。关系数据库管理系统就是管理关系数据库，并将数据逻辑组织的系统
-
NoSQL(Not Only SQL)：
- 泛指非关系型的数据库。
-
大数据时代的3V
-
Velume（海量）
-
Variety（多样）
-
Velocity（实时）
-
-
互联网需求的3高
- 高并发
- 高可扩
- 高性能
-
ACID：指关系型数据库事务正确执行的四个基本要素的缩写
- Atomicity(原子性)：整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样
- Consistency(一致性)：一个事务可以封装状态改变（除非它是一个只读的）。事务必须始终保持系统处于一致的状态，不管在任何给定的时间并发事务有多少。
- Isolation(隔离性)：隔离状态执行事务，使它们好像是系统在给定时间内执行的唯一操作。如果有两个事务，运行在相同的时间内，执行相同的功能，事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。这种属性有时称为串行化，为了防止事务操作间的混淆，必须串行化或序列化请求，使得在同一时间仅有一个请求用于同一数据。
- Durability(持久性)：在事务完成以后，该事务对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。
二、传统关系型数据库缺点与NoSQL优势
1. 传统关系型数据库演变过程
1.1 单机 MySQL
-
互联网刚起步时，互联网用户少之又少，一般的网站访问量并不大，而且大部分都是静态网页，动态交互型网站并不多，单个数据库足够应付。
-
单机版架构
-
缺点
- 只适用于访问量较小的网站
- 如果数据库量过大（单个数据库存储不下），该种架构就无法满足需求。
1.2 Memcached(缓存)+MySQL+垂直拆分
- 随着访问量的上升，上述单机版的机构无法满足需求，一些企业开始大量使用缓存技术来缓解数据库的压力，优化数据库的结构和索引，开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技术产品。
- Memcached作为一个独立的分布式的缓存服务器，为多个web服务器提供了一个共享的高性能缓存服务，在Memcached服务器上，又发展了根据hash算法来进行多台Memcached缓存服务的扩展，然后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端。
1.3 Mysql主从读写分离
- 由于数据库的写入压力增加，Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了。
1.4 分库分表+水平拆分+mysql集群
-
在Memcached的高速缓存，MySQL的主从复制，读写分离的基础之上，这时MySQL主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM在写数据的时候会使用表锁，在高并发写数据的情况下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。
ps：这就是为什么 MySQL 在 5.6 版本之后使用 InnoDB 做为默认存储引擎的原因 – MyISAM 写会锁表，InnoDB 有行锁，发生冲突的几率低，并发性能高。
1.5 MySQL的扩展性瓶颈
- MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小，如果能把这些数据从MySQL省去，MySQL将变得非常的小。关系数据库很强大，但是它并不能很好的应付所有的应用场景。MySQL的扩展性差（需要复杂的技术来实现），大数据下IO压力大，表结构更改困难，正是当前使用MySQL的开发人员面临的问题。
2. 为什么使用NoSQL ?
今天我们可以通过第三方平台（如：Google,Facebook等）可以很容易的访问和抓取数据。用户的个人信息，社交网络，地理位置，用户生成的数据和用户操作日志已经成倍的增加。我们如果要对这些用户数据进行挖掘，那SQL数据库已经不适合这些应用了, NoSQL数据库的发展也却能很好的处理这些大的数据
三、NoSQL简介
- 泛指非关系型的数据库。
- 随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。
- NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储
四、Nosql和关系型数据库对比
1. 区别
| 区别 | 关系型数据库 | 非关系型数据库（Nosql） |
|---|---|---|
| 存储方式 | 表格式存储。存储在表的行和列中。他们之间很容易关联协作存储，提取数据很方便 | 而Nosql数据库则与其相反，他是大块的组合在一起。通常存储在数据集中，就像文档、键值对或者图结构。 |
| 存储结构 | 结构化数据。数据表都预先定义了结构（列的定义），结构描述了数据的形式和内容。这一点对数据建模至关重要，虽然预定义结构带来了可靠性和稳定性（优点），但是修改这些数据比较困难（缺点）。 | 而Nosql数据库基于动态结构，使用与非结构化数据。因为Nosql数据库是动态结构，可以很容易适应数据类型和结构的变化。 |
| 存储规范 | 数据存储为了更高的规范性，把数据分割为最小的关系表以避免重复，获得精简的空间利用。虽然管理起来很清晰，但是单个操作涉及到多张表的时候，数据管理就显得有点麻烦 | 而Nosql数据存储在平面数据集中，数据经常可能会重复。单个数据库很少被分隔开，而是存储成了一个整体，这样整块数据更加便于读写 |
| 存储扩展 | 关系型数据库是纵向扩展，也就是说想要提高处理能力，要使用速度更快的计算机。因为数据存储在关系表中，操作的性能瓶颈可能涉及到多个表，需要通过提升计算机性能来克服。虽然有很大的扩展空间，但是最终会达到纵向扩展的上限 | 而Nosql数据库是横向扩展的，它的存储天然就是分布式的，可以通过给资源池添加更多的普通数据库服务器来分担负载。 |
| 查询方式 | 结构化查询语言来操作数据库（就是我们通常说的SQL）。 关系型数据库表中主键 关系型数据库使用预定义优化方式（比如索引）来加快查询操作 | 以块为单元操作数据，使用的是非结构化查询语言（UnQl），它是没有标准的 Nosql中存储文档的ID 更简单更精确的数据访问模式 |
| 事务 | 遵循ACID规则（原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)） 支持对事务原子性细粒度控制，并且易于回滚事务。 | 遵循BASE原则（基本可用（Basically Availble）、软/柔性事务（Soft-state ）、最终一致性（Eventual Consistency）） Nosql数据库是在CAP（一致性、可用性、分区容忍度）中任选两项，因为基于节点的分布式系统中，很难全部满足，所以对事务的支持不是很好，虽然也可以使用事务，但是并不是Nosql的闪光点。 |
| 性能 | 为了维护数据的一致性付出了巨大的代价，读写性能比较差。在面对高并发读写性能非常差，面对海量数据的时候效率非常低。 | Nosql存储的格式都是key-value类型的，并且存储在内存中，非常容易存储，而且对于数据的 一致性是弱要求。Nosql无需sql的解析，提高了读写性能。 |
| 授权方式 | 关系型数据库通常有SQL Server，Mysql，Oracle。大多数的关系型数据库都是付费的并且价格昂贵，成本较大。 | 主流的Nosql数据库有redis，memcache，MongoDb。而Nosql数据库通常都是开源的。 |
2. 优缺点对比
| 数据库 类型 | 特性 | 优点 | 缺点 |
|---|---|---|---|
| 关系型数据库 | 1、关系型数据库，是指采用了关系模型来组织 数据的数据库； 2、关系型数据库的最大特点就是事务的一致性； 3、简单来说，关系模型指的就是二维表格模型， 而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织。 | 1、容易理解：二维表结构是非常贴近逻辑世界一个概念，关系模型相对网状、层次等其他模型来说更容易理解； 2、使用方便：通用的SQL语言使得操作关系型数据库非常方便； 3、易于维护：丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了数据冗余和数据不一致的概率； 4、支持SQL，可用于复杂的查询。 | 1、为了维护一致性所付出的巨大代价就是其读写性能比较差； 2、固定的表结构； 3、高并发下读写性能差； 4、海量数据的高效率读写效率差； |
| 非关系型数据库 | 1、使用键值对存储数据； 2、分布式； 3、一般不支持ACID特性； 4、非关系型数据库严格上不是一种数据库，应该是一种数据结构化存储方法的集合。 | 1、无需经过sql层的解析，读写性能很高； 2、基于键值对，数据没有耦合性，容易扩展； 3、存储数据的格式多样：nosql的存储格式是key,value形式、文档形式、图片形式等等，文档形式、图片形式等等，而关系型数据库则只支持基础类型。 | 1、不提供sql支持，学习和使用成本较高； 2、无事务处理，附加功能和报表等支持也不好； |
五、NoSQL分类及应用
1. 键值对存储（key-value）
1.1 数据模型
- 使用键值(key-value)存储的数据库
- 键是一个字符串对象
- 值可以是任意类型的数据，比如整型、字符、数组、列表、集合等
1.2 应用场景
-
适用场景
- 涉及频繁读写、拥有简单数据模型的应用
- 内容缓存，比如会话、配置文件、参数、购物车等
- 存储配置和用户数据信息的移动应用
-
不适用场景
- 需要通过值来查询，而不是键来查询。Key-Value数据库中没有提供通过值查询的途径
- 需要储存数据之间的关系。在Key-Value数据库中不能通过两个或以上的键来关联数据
- 需要事务的支持。在Key-Value数据库中故障产生时不可以进行回滚
1.3 代表产品
-
Redis
- Redis是一个使用ANSI C编写的开源、支持网络、基于内存、可选持久性的键值对存储数据库。从2015年6月开始，Redis的开发由Redis Labs赞助，而2013年5月至2015年6月期间，其开发由Pivotal赞助。在2013年5月之前，其开发由VMware赞助。根据月度排行网站DB-Engines.com的数据显示，Redis是最流行的键值对存储数据库。
-
Cassandra
- Apache Cassandra（社区内一般简称为C）是一套开源分布式NoSQL数据库系统*。它最初由Facebook开发，用于储存收件箱等简单格式数据，集Google BigTable的数据模型与Amazon Dynamo的完全分布式架构于一身。Facebook于2008将 Cassandra 开源，此后，由于Cassandra良好的可扩展性和性能，被 Apple, Comcast,Instagram, Spotify, eBay, Rackspace, Netflix等知名网站所采用，成为了一种流行的分布式结构化数据存储方案。
-
LevelDB
- LevelDB是一个由Google公司所研发的键／值对（Key/Value Pair）嵌入式数据库管理系统编程库， 以开源的BSD许可证发布。
2. 列存储
2.1 数据模型
- 以列相关存储架构进行数据存储
2.2 应用场景
-
适用场景
- 分布式数据存储与管理
- 数据在地理上分布于多个数据中心的应用程序
- 可以容忍副本中存在短期不一致情况的应用程序
- 拥有动态字段的应用程序
- 拥有潜在大量数据的应用程序（几百TB的数据）
-
不适用场景
- 扫描小量数据
- 随机的更新
- 做含有删除和更新的实时操作
- 需要ACID事务支持的情形
2.3 代表产品
-
HBase
- HBase是一个开源的非关系型分布式数据库（NoSQL），它参考了谷歌的BigTable建模，实现的编程语言为 Java。它是Apache软件基金会的Hadoop项目的一部分，运行于HDFS文件系统之上，为 Hadoop 提供类似于BigTable 规模的服务。因此，它可以容错地存储海量稀疏的数据。
-
BigTable
- BigTable是一种压缩的、高性能的、高可扩展性的，基于Google文件系统（Google File System，GFS）的数据存储系统，用于存储大规模结构化数据，适用于云端计算。
3.文档数据库存储
3.1 数据模型
- 键/值存储
- 值是版本化的文档
3.2 应用场景
-
适用场景
- 数据量很大或者未来会变得很大
- 表结构不明确，且字段在不断增加，例如内容管理系统，信息管理系统
-
不适用场景
- 在不同的文档上需要添加事务。Document-Oriented数据库并不支持文档间的事务
- 多个文档直接需要复杂查询，例如join
3.3 代表产品
-
MongoDB
- MongoDB是一种面向文档的数据库管理系统，由C++撰写而成，以此来解决应用程序开发社区中的大量现实问题。2007年10月，MongoDB由10gen团队所发展。2009年2月首度推出。
-
CouchDB
- Apache CouchDB是一个开源数据库，专注于易用性和成为"完全拥抱web的数据库"。它是一个使用JSON作为存储格式，JavaScript作为查询语言，MapReduce和HTTP作为API的NoSQL数据库。其中一个显著的功能就是多主复制。CouchDB的第一个版本发布在2005年，在2008年成为了Apache的项目。
4. 图形数据库存储
4.1 数据模型
- 图结构存储
4.2 应用场景
- 专门用于处理具有高度相互关联关系的数据
- 适合于社交网络、模式识别、依赖分析、推荐系统以及路径寻找等问题
4.3 代表产品
-
Neo4j
- Neo4j是一个流行的图形数据库，它是开源的。最近，Neo4j的社区版已经由遵循AGPL许可协议转向了遵循GPL许可协议。尽管如此，Neo4j的企业版依然使用AGPL许可。Neo4j基于Java实现，兼容ACID特性，也支持其他编程语言，如Ruby和Python
-
Titan
- Titan是一个可扩展的图形数据库，针对存储和查询包含分布在多机群集中的数百亿个顶点和边缘的图形进行了优化。Titan是一个事务性数据库，可以支持数千个并发用户实时执行复杂的图形遍历。
-
GraphDB
- GraphDB是德国sones公司在.NET基础上构建的。Sones公司于2007年成立，近年来陆续进行了几轮融资。GraphDB社区版遵循AGPL v3许可协议，企业版是商业化的。GraphDB托管在Windows Azure平台上。
-
ArangoDB
- ArangoDB是由triAGENS GmbH开发的原生多模型数据库系统。数据库系统支持三个重要的数据模型（键/值，文档，图形），其中包含一个数据库核心和统一查询语言AQL（ArangoDB查询语言）。查询语言是声明性的，允许在单个查询中组合不同的数据访问模式。ArangoDB是一个NoSQL数据库系统，但AQL在很多方面与SQL类似。
5. 全文搜索引擎
传统关系型数据库主要通过索引来达到快速查询的目的，在全文搜索的业务下，索引也无能为力，主要体现在：
- 全文搜索的条件可以随意排列组合，如果通过索引来满足，则索引的数量非常多
- 全文搜索的模糊匹配方式，索引无法满足，只能用like查询，而like查询是整表扫描，效率非常低
而全文搜索引擎的出现，正是解决关系型数据库全文搜索功能较弱的问题
5.1 基本原理
- 全文搜索引擎的技术原理称为“倒排索引”（inverted index），是一种索引方法，其基本原理是建立单词到文档的索引。与之相对是，是“正排索引”，其基本原理是建立文档到单词的索引。
5.2 应用场景
-
适用场景
- 分布式的搜索引擎和数据分析引擎
- 全文检索，结构化检索，数据分析
- 对海量数据进行近实时的处理
可以将海量数据分散到多台服务器上去存储和检索
-
不适用场景
- 数据需要频繁更新
- 需要复杂关联查询
5.3 代表产品
-
Elasticsearch
- Elasticsearch是一个基于Lucene的搜索引擎。它提供了一个分布式，多租户 -能够全文搜索与发动机HTTP Web界面和无架构JSON文件。Elasticsearch是用Java开发的，并根据Apache License的条款作为开源发布。根据DB-Engines排名，Elasticsearch是最受欢迎的企业搜索引擎。
-
Solr
- Solr是Apache Lucene项目的开源企业搜索平台。其主要功能包括全文检索、命中标示、分面搜索、动态聚类、数据库集成，以及富文本（如Word、PDF）的处理。Solr是高度可扩展的，并提供了分布式搜索和索引复制
六、总结
-
关系型数据库和NoSQL数据库的选型，往往需要考虑几个指标：
- 数据量
- 并发量
- 实时性
- 一致性要求
- 读写分布和类型
- 安全性
- 运维成本
-
常见软件系统数据库选型参考如下：
- 内部使用的管理型系统
如运营系统，数据量少，并发量小，首选考虑关系型 - 大流量系统
如电商单品页，后台考虑选关系型，前台考虑选内存型 - 日志型系统
原始数据考虑选列式，日志搜索考虑选倒排索引 - 搜索型系统
例如站内搜索，非通用搜索，如商品搜索，后台考虑选关系型，前台考虑选倒排索引 - 事务型系统
如库存，交易，记账，考虑选关系型型+缓存+一致性型协议 - 离线计算
如大量数据分析，考虑选列式或者关系型也可以 - 实时计算
如实时监控，可以考虑选内存型或者列式数据库
- 内部使用的管理型系统
-
设计实践中，要基于需求、业务驱动架构，无论选用RDB/NoSQL/DRDB,一定是以需求为导向，最终数据存储方案必然是各种权衡的综合性设计
3859
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
