分布式数据库NoSQL是一种非关系型数据库，采用了键值对、文档、列族、图等数据模型，具有高度的可伸缩性和灵活性，用于大规模存储和处理分布式数据。
优势与特性
NoSQL数据库适用于互联网应用、物联网、日志存储等应用场景，特别是需要处理大规模数据和高并发访问的场景。
| 对比 | 关系型数据库 | 非关系型数据库 |
|---|---|---|
| 数据类型 | 依据关系模型【一对一/一对多/多对一/多对多】来创建的数据库，擅长存储结构化数据 | 适合存储半结构化或者非结构化数据（因为它们不强制遵循表的schema设计） |
| 事务支持 | 严格遵守 ACID 保证，因此是事务数据的不错选择 | 大多数 NoSQL 数据库仅支持最终一致性，因此不是事务操作的最佳选择。 |
| CAP原则 | 大多数数据库优先考虑一致性 (Consistency) 和可用性 (Availability)，而不是分区容错性 (Partition tolerance) | 分区容错性是其构建基础，牺牲了一致性和参照完整性。 |
| 工作负载 | 适合处理中等量的数据；低速传入的数据 | 适合处理大数据；高速传入的数据 |
| 架构灵活性 | 一旦确定关系表之后，修改很麻烦 | 模式灵活，允许添加或删除属性 |
| 部署 | 纵向部署；集中式结构 | 横向部署；去中心化结构 |
| 成本 | 为了处理TB级别的数据，关系型数据库往往需要高端的专用硬件 | 通用硬件成本廉价，且易于水平扩展 |
分类
NoSQL 大致可以分为以下几类：
- KV 类：以 Redis 为代表；
- 文档存储：以 MongoDB 为代表，文档存储一般用类似json的格式存储，存储的内容是文档型的。这样也就有机会对某些字段建立索引，实现关系数据库的某些功能。
- 列存储：以 HBase 为代表，顾名思义，是按列存储数据的。最大的特点是方便存储结构化和半结构化数据，方便做数据压缩，对针对某一列或者某几列的查询有非常大的IO优势。
- 图、时序等新兴的数据库也都属于 NoSQL 范畴。
| 分类 | 键值数据库 | 列存储数据库 | 文档型数据库 | 图数据库 |
|---|---|---|---|---|
| 特点 | 数据存储在键/值对中; 每个键都是唯一的 | 不同于关系型数据库的以行为单位储存，在列存储数据库中，一个列族存储经常被一起查询的相关数据。 | 与键值数据库类似，但是它的数据是以文档的形式(XML、JSON)储存，该值被DB理解，可以查询。 | 将数据以图的方式存储。实体会被作为顶点，而实体之间的关系则会被作为边。 |
| 优势 | 可扩展性：支持横向/纵向扩展 性能优势：单个节点的键值数据库在读写数据方面性能较高 易于使用：可以接受任何类型的数据，甚至在需要的时候可以接受不同类型的数据 |
海量数据的聚合查询很快：例如只需要知道所有用户的平均年龄 压缩效率高：列式存储把相同类型的数据归在一起，压缩比较高，通常能到10%~25% |
灵活的数据模式：不需要文档有一致性(尤其在不断变化的系统中) 更快的创建和维护：创建后维护成本很低。而且由于没有外键约束，文档可以相互独立 性能提升：全文检索性能好(可以在一个文档中找到需要的所有内容) |
灵活的数据模式：可以灵活增设节点、边类型/属性； 灵活的查询：可以更灵活地对相关数据进行分组和聚合 维度组合&维度分层：可以结合多个维度（不同粒度）来管理大数据。 |
| 劣势 | 缺乏ACID的支持； 不支持高级查询(在应用层进行过滤处理等，会降低性能)； |
数据写入开销较大，因为需要对每一列数据进行写入； 依赖于详细的行数据的场景，效率不高 |
对事务支持不好； 一致性检查限制; |
不适用于基于事务的系统； 图数据库并不能像关系数据库那样，很容易的实现统计，报表分析。 |
| 产品举例 | Redis、Memcached、ByteKV、ABase | HBase | MongoDB、Elasticsearch、ByteDoc | Neo4j、ByteGraph |
| 应用场景举例 | 大规模的会话(session)管理； 用户偏好&配置文件 |
适合OLAP(OnLine Analytical Processing) | 内容管理系统(Windows注册表)； 日志系统； |
欺诈识别； 社交关系处理； 商品实时推荐 |
易扩展
NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。在架构的层面上带来了可扩展的能力，可以轻松地进行横向扩展，通过添加更多的节点来增加存储容量和处理能力。这种可伸缩性使得NoSQL数据库可以处理大规模数据和高并发访问的需求。
大数据量，高性能
NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。
一致性
NoSQL数据库的一致性模型分为强一致性、弱一致性和最终一致性。强一致性要求数据的更新在所有副本中立即可见，弱一致性允许数据的更新在一定时间内不可见，最终一致性则保证最终所有副本达到一致状态。
- 强一致性：采用 Paxos 或者 Raft 协议来保证数据的强一致。
- 最终一致性：一般是通过数据复制实现最终一致性，数据的复制支持同步复制、异步复制和半同步复制。业务可以根据自己的业务特点选择合适的复制方式。其中半同步复制时，会保证备机写入成功才会返回客户端成功，这样保证不会有数据丢失。
灵活的数据模型
NoSQL数据库可以根据需求选择不同的数据模型，如键值对、文档、列族、图等，以适应不同的应用场景。这种灵活性使得NoSQL数据库适用于各种不同类型的数据存储需求。
NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。
高可用
NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。比如Cassandra，HBase模型，通过复制模型也能实现高可用。
可用性与一致性
由 CAP 原理可知，任何分布式系统都需要在一致性和可用性之间取舍，这就出现了两类存储系统：
- 高可用，最终一致的存储系统
- Redis
- 强一致的系统
- 提供数据强一致性能够大大减小业务的负担
