本文已参与「新人创作礼」活动，一起开启掘金创作之路。
NoSQL
大数据时代的3V 海量 Volume 多样 Variety 实时 Velocity，互联网需求的3高 高并发 高可扩 高性能.
NoSQL 是什么
NoSQL Not Only SQL, 即 不仅仅是SQL, NoSQL 泛指非关系型的数据库.
随着互联网的兴起, 传统的关系数据库面对超大规模和高并发的纯动态网站已经显得力不从心, 存在很多难以克服的问题, 而非关系型的数据库则由于其本身的特点得到了非常迅速的发展. NoSQL 数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战, 尤其是大数据应用难题, 包括超大规模数据的存储. 这些类型的数据存储不需要固定的模式, 无需多余操作就可以横向扩展.
(1) 优点:
易扩展. NoSQL 数据库种类繁多, 但是一个共同的特点都是去掉关系数据库的关系型特性. 数据之间无关系, 这样就非常容易扩展. 也无形之间, 在架构的层面上带来了可扩展的能力.大数据量 高性能. NoSQL 数据库都具有非常高的读写性能, 尤其在大数据量下, 这得益于它的无关系性, 数据库的结构非常简单.多样灵活的数据模型. NoSQL 无需事先为要存储的数据建立字段, 随时可以存储自定义的数据格式. 而在关系数据库里, 增删字段是一件非常麻烦的事情. 如果是非常大数据量的表, 增加字段简直就是一个噩梦.
(2) 传统 RDBMS vs NoSQL
RDBMS : 高度组织化结构化的数据, 结构化查询语言, 数据和关系都存储在单独的表中, 严格的一致性, 基础事务.
NoSQL : 非结构化的数据, 没有声明查询语言, 没有预定义的模式, 键-值存储, 列存储, 文档存储, 图形数据库, 最终一致性, CAP 定理, 高性能, 高可用性, 可伸缩性.
(3) 当下的 NoSQL 经典应用
以淘宝首页的商品为例 :
- 商品基本信息. 关系型数据库. MySQL.
- 商品描述, 详情, 评价信息. 多文字信息描述类, IO 读写性能变差, 多采用文档型数据库 MongoDB.
- 商品的图片. 分布式文件系统. HDFS, TFS, GFS.
- 商品的关键字. 站内搜索 ElasticSearch, Slor.
- 商品的波段性的热点高频信息. 内存数据库. Redis, Tair, Memcache.
- 商品的交易, 价格计算, 积分累计. 第三方支付接口.
NoSQL 数据库的分类
- K-V键值型 : Redis Memcache
- 文档型 : MongoDB, CouchDB
- 列存储 : HBase, Cassandra, 分布式文件系统
- 图关系 : Neo4J, InfoGrid, 存放关系 : 朋友圈社交网络, 广告推荐系统等.
NoSQL 的 CAP
根据 CAP 定理, 数据库 可以分为以下三种:
CA: 单点集群, 满足一致性, 可用性, 但是可扩展性不强. 比如, 传统的 RDBMS.CP: 满足一致性, 分区容错性, 通常性能不是很高. 比如, Redis , Mongo.AP: 满足可用性, 分区容错性, 通常一致性不是很高. 比如, 大多数网站架构的选择.
一致性和可用性的选择:
对于 web2.0 网站来说, 关系数据库的很多主要特性却往往无用武之地.
- 数据库事务一致性需求. 很多 web 实时系统并不要求严格的数据库事务, 对读一致性的要求很低, 有些场合对写一致性要求并不高. 允许实现最终一性.
- 数据库的写实时性和读实时性需求. 对关系数据库来说, 插入一条数据之后立刻查询, 是肯定可以读出来这条数据的, 但是对于很多 web 应用来说, 并不要求这么高的实时性, 比方说发一条消息之后, 过几秒乃至十几秒之后, 订阅者才看到这条动态是完全可以接受的.
- 对复杂的 SQL 查询, 特别是多表关联查询的需求. 任何大数据量的 web 系统, 都非常忌讳多个大表的关联查询, 以及复杂的数据分析类型的报表查询, 特别是 SNS 类型的网站, 从需求以及产品设计角度, 就避免了这种情况的产生. 往往更多的只是单表的主键查询, 以及单表的简单条件分页查询, SQL 的功能被极大的弱化了.
CAP 定理
CAP 定理是一个经典的分布式系统理论. CAP 理论告诉我们：一个分布式系统不可能同时满足一致性（C：Consistency）, 可用性（A：Availability）和分区容错性（P：Partition tolerance）这三个基本需求, 最多只能同时满足其中两项.
一致性 Consistency
在分布式环境下, 一致性是指数据在多个副本之间能否保持一致. 在一致性的需求下, 当一个系统在数据一致的状态下执行更新操作后, 应该保证系统的数据仍然处于一致的状态.
对于一个将数据副本分布在不同分布式节点上的系统来说, 如果对第一个节点的数据进行了更新操作并且更新成功后, 却没有使得第二个节点上的数据得到相应的更新, 在对第二个节点的数据进行读取操作时, 获取的依然是脏数据, 这就是典型的分布式数据不一致的情况. 在分布式系统中, 如果能够做到针对一个数据项的更新操作执行成功后, 所有的用户都可以读取到其最新的值, 那么这样的系统就被认为具有强一致性.
可用性 Availability
可用性是指系统提供的服务必须一直处于可用的状态, 对于用户的每一个操作请求总是能够在有限的时间内返回结果. 这里的重点是 有限时间内和返回结果.
有限时间内是指, 对于用户的一个操作请求, 系统必须能够在指定的时间内返回对应的处理结果, 如果超过了这个时间范围, 那么系统就被认为是不可用的. 另外, 有限的时间内是系统设计之初就设计好的运行指标, 通常不同系统之间有很大的不同, 无论如何, 对于用户请求, 系统必须存在一个合理的响应时间, 否则用户便会对系统感到失望.
返回结果是可用性的另一个非常重要的指标, 它要求系统在完成对用户请求的处理后, 返回一个正常的响应结果. 正常的响应结果通常能够明确地反映出队请求的处理结果, 即成功或失败, 而不是一个让用户感到困惑的返回结果, 比如后台报错直接返回给用户的.
分区容错性 Partition tolerance
分区容错性约束了一个分布式系统具有如下特性：分布式系统在遇到任何网络分区故障的时候, 仍然需要能够保证对外提供满足一致性和可用性的服务, 除非是整个网络环境都发生了故障.
网络分区是指在分布式系统中, 不同的节点分布在不同的子网络（机房或异地网络）中, 每个子网络就叫做一个区（partition）. 比如, 一台服务器放在中国, 另一台服务器放在美国, 这就是两个区. 可能由于一些特殊的原因导致这些区之间出现网络不连通的状况或者无法通行, 但各个子网络的内部网络是正常的, 整个系统的网络环境被切分成了若干个孤立的区域. 需要注意的是, 组成一个分布式系统的每个节点的加入与退出都可以看作是一个特殊的网络分区.
一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立.
Consistency 和 Availability 的矛盾
一致性和可用性，为什么不可能同时成立？答案很简单，因为可能通信失败（ 即出现分区容错 ）
比如有两台 NoSQL 服务器 G1 和 G2, 如果保证 G2 的一致性, 那么 G1 必须在写操作时, 锁定 G2 的读操作和写操作. 只有数据同步后, 才能重新开放读写. 锁定期间, G2 不能读写, 丧失了可用性. 如果保证 G2 的可用性, 那么势必不能锁定 G2, 所以一致性不成立.
综上, G2无法同时做到一致性和可用性. 系统设计时只能选择一个目标. 如果追求一致性, 那么无法保证所有节点的可用性; 如果追求所有节点的可用性, 那就没法做到强一致性.
既然一个分布式系统无法同时满足一致性, 可用性, 分区容错性三个特点, 所以就需要抛弃其中一样. 不过对于一个分布式系统而言, 分区容错性是一个最基本的要求. 因为既然是一个分布式系统, 那么分布式系统中的组件必然需要被部署到不同的节点, 否则也就算不上分布式系统了, 因此必然出现子网络. 而对于分布式系统而言, 网络问题又是一个必定会出现的异常情况, 因此分区容错性也就成为了一个分布式系统必然需要面对和解决的问题. 因此系统架构师往往需要把精力花在如何根据业务特点在 C（一致性）和A（可用性）之间寻求平衡.
BASE 理论
BASE 理论是为了解决关系数据库强一致性要求而引起的可用性降低 而提出的解决方案. BASE 理论是对 CAP 中一致性和可用性权衡的结果, 其来源于对大规模互联网系统分布式实践的总结, 是基于 CAP 定理逐步演化而来的.
BASE 是 Basically Available（基本可用）, Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的缩写.
BASE 理论的核心思想是：即使无法做到强一致性, 但每个应用都可以根据自身业务特点, 采用适当的方式来使系统达到最终一致性.
基本可用
基本可用是指分布式系统在出现不可预知故障的时候, 允许损失部分可用性 , 但是绝不能让系统不可用. 比如：
- 响应时间上的损失 : 正常情况下, 一个搜索引擎需要在 0.5 秒之内返回给用户相应的查询结果, 但由于出现故障, 查询结果的响应时间增加了 1~2 秒.
- 系统功能上的损失 : 淘宝双 12 的时候, 为了保护系统的可用性, 部分消费者可能会被引导到一个降级页面.
- 短时间内的数据不一致 : 视频网站的播放次数, 微博博文的赞数等.
软状态
软状态指允许系统中的数据存在中间状态, 并认为该中间状态的存在不会影响系统的整体可用性, 即允许系统在不同节点的数据副本之间进行数据同步的过程中存在延时.
最终一致性
最终一致性强调的是所有的数据副本, 在经过一段时间的同步之后, 最终都能够达到一个一致的状态. 因此, 最终一致性的本质是需要系统保证最终数据能够达到一致, 而不需要实时保证系统数据的强一致性.
总的来说, BASE 理论面向的是大型高可用可扩展的分布式系统, 和传统的事务 ACID 特性是相反的, 它完全不同于 ACID 的强一致性模型, 而是通过牺牲强一致性来获得可用性, 并允许数据在一段时间内是不一致的, 但最终达到一致状态. 但同时, 在实际的分布式场景中, 不同业务单元和组件对数据一致性的要求是不同的, 因此在具体的分布式系统架构设计过程中, ACID 特性和 BASE 理论往往又会结合在一起.
\
参考文章：
