redis是nosql数据库吗NOSQL数据库简介
近年来，相信IT从业者对NOSQL这个名词不会陌⽣，根据WikiPedia的，NOSQL是”non SQL”或”Not Only SQL”的简称。其实早在1960年前后，计算机领域就出现过类似的系统，但NOSQL系统真正的爆发点是在WEB2.0出现以后，特别是随着⼤数据概念的兴起⽽⼤放异彩。其被⼴泛使⽤的原因与数据特点有着紧密关系。
本⽂是NOSQL数据库综述⽅⾯的学习笔记，参考资料主要来⾃”“⼀书附录”NOSQL Overview”部分。
1. NOSQL基本概念
⽬前IT⾏业，尤其是互联⽹⾏业数据有⼏个典型特征：
1）数据量⼤，单机⽆法存储；即使能存储于单机关系型数据库，但随着数据量增加，联表join查询的性能会急剧下降
2）数据变化快：a. 数据增速快；b. 流量分布变化快（有明显的峰⾕，也可能有突发流量）；c. 数据间的耦合结构变化快，传统关系型数据库的强schema模式显得不够灵活
3）数据来源多，原始数据不容易结构化，有强schema约束的关系型数据库不再合适
4）对数据存储的要求有变化，以为指导，⼤多数系统并不要求强⼀致性，⽽是对数据存储系统的Availability & Partition tolerance有更⾼要求
⽽NOSQL数据库通常满⾜BASE约束：
1）Basic Availability
系统在外界看来似乎总处于可⽤状态，这是通过多机⽔平扩展的集部署⽅案实现的，只要多数节点正常就能保证系统基本的可⽤性，只有落在故障节点的⽤户请求才会感知到系统不可⽤。
2）Soft-state
⼤多数NOSQL系统通过牺牲强⼀致性来保证可⽤性和分区容忍性，也即，⼀个节点写⼊新数据后，更新不会⽴即传播⾄集其它节点，所以落在其它节点上的读请求可能会读到旧数据。
3）Eventual consistency
NOSQL系统对最终⼀致性通常是可以保证的。值得⼀提的是，Neo4j这个图数据库虽然也属NOSQL阵营，但它是可以保证ACID约束的。
从定义来看，与关系型数据库的ACID强约束相⽐，BASE约束要松散⼀些，但灵活性有优势，因此，满⾜前述数据特征的互联⽹系统越来越依赖NOSQL系统也就不⾜为奇了。当然，⼀些对数据有ACID要求的系统还是应该⾸选关系型数据库。
总之，数据特征决定了我们在实际⼯程中应该使⽤何种存储系统。
2. 业界典型的NOSQL系统
根据业界流⾏的NOSQL系统，可以将NOSQL存储划分为4个象限，如下图所⽰。
2.1 Key-Value Stores
KV型NOSQL系统起源于Amazon开发的Dynamo系统（Amazon AWS提供的DynamoDB就是这货），可以把它理解为⼀个分布式的hashmap，⽀持SEG/GET元操作。
⼀个完整的分布式KV系统会将KEY按策略尽量均匀地散列在不同的节点上。其中是⽐较优雅的散列策略，它可以保证当某个节点挂掉时，只有该节点的数据需要重新散列。作为对⽐，若采⽤取模哈希策略，则集有节点不可⽤时，取模的分母N发⽣变化，会导致⼏乎所有的KEY都要重新散列，代价太⾼。
⼤多数KV NOSQL通常不会关⼼存⼊的value到底是什么，在它看来，那只是⼀堆字节⽽已，所以开发者也⽆法通过value的某些属性来获取整个value。如果开发者有根据value的部分字段查数据的需求，那应该考虑使⽤⽂档型NOSQL系统。
典型的KV型NOSQL系统：Memcached, Redis及DynamoDB
2.2 Document Stores
对于需要跟具有层次⽂档结构的数据打交道的开发者来说，⽂档型NOSQL系统提供了最⾃然的存储模式，它⽀持读/写⼀些标准格式的⽂档数据（典型如XML, YAML和JSON，甚⾄⽀持2进制的BSON格式）
。
在最简单的应⽤中，⽂档数据可以通过其ID进⾏读写操作，此时，可以将⽂档型NOSQL系统看作是K-V系统。
但⽂档型NOSQL系统更普遍的应⽤场合是根据⽂档的某个属性字段来获取整个⽂档。根据属性快速获取包含该属性的所有⽂档的操作是通过索引来实现的，也即⽂档数据在写⼊时，系统会对某些⽂档属性建⽴索引，从⽽⽀持⾼效地反查操作。⽽维护索引是有代价的，因此，⽂档型NOSQL数据库适⽤于读多写少的场合。
需要注意的是，对于单个⽂档的读写，⽂档型NOSQL系统可以保证原⼦操作，但批量写⼊的事物原⼦性⽬前还不能由系统保证，需要开发者在应⽤程序中显式处理。
此外，⽬前⼤多数⽂档型NOSQL系统需要⽤户来规划数据在集多个实例间的sharding策略，因此，系统的⽔平扩展问题需要在选型时重点考虑，例如MongoDB早期版本的auto sharding在运维上就容易坑⼈，导致其⼀直被诟病。作为对⽐，主流的KV NOSQL系统和列式NOSQL系统在底层实现时就⽀持⾃动sharding，通常⽆需开发者花费很⼤精⼒来处理。
典型的⽂档型NOSQL系统：MongoDB和Apache CouchDB
2.3 Column Family Stores
列式NOSQL系统起源于Google的BigTable，其数据模型可以看作是⼀个每⾏列数可变的数据表，它可以细分为4种实现模式，如下图所⽰。
其中，Super Colunm Family模型可以理解为maps of maps，例如可以把⼀个作者和他的专辑结构化地存成Super Colunm Family模式，如下图所⽰。
与KV型或⽂档型的NOSQL系统相⽐，列式存储系统对数据模型的表达⼒更强。
典型的列式NOSQL系统：BigTable, Cassandra, HBase
2.4 Graph Databases
上⾯介绍的KV系统、⽂档型系统及列式存储系统可被统⼀称为聚合存储系统（Aggregate Stores），它们的共同点是不适合处理具有耦合关系的数据，即它们不适合⽤于需要理解数据关联关系的复杂查
询，⽽这正是图数据库的⽤武之地。
图数据库可以细分为底层存储引擎和处理引擎两部分。有些图数据库实现了native的、为存储和管理图数据做过特别优化的图存储引擎（例如Neo4j），⽽有些图数据库底层存储是外接系统。⾄于处理引擎，有些数据库实现了具备index-free adjacency特性的引擎（如
Neo4j），⽽有些图数据库并未做到这⼀点。
图数据库在查数据时并不会特别依赖索引（严格地说，只是在定位初始节点时会⽤到索引），因为对于图来说，节点间的关系可以⽤有向边表达出来。基于图的查询会利⽤这种局部临接关系遍历图，⽽⾮根据全局索引对图中节点做遍历，因此，对于有关联关系的数据来说，利⽤图进⾏查询的性能会很⾼。
图数据库在组织数据时，常⽤的数据模型包括：属性图（property graphs）、超图（hypergraphs）和三元组（triples)，其中属性图模型是图数据库组织数据时普遍采⽤的主流模型，Neo4j即是采⽤属性图模型来表达数据间的关联关系。
上述3种图数据模型间的详细区别涉及较多术语，限于篇幅，本⽂不赘述，感兴趣的话可以翻阅”Graph Database (2nd Edition)”⼀书的附录部分。
3. 参考资料
1. Wikipedia:
2. Wikipedia:
3. Book: , Appendix A. NOSQL Overview
4. Wikipedia:
5. Neo4j Blog: , ⽂中解释了index-free adjacency对图遍历的重要性

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。