一.高性能NoSQL 关系型数据库发展了很多年，是很多项目首*选的数据存储方案。强大的 SQL 功能和 ACID 的属性，使得关系数据库广泛应用于各式各样的系统中，但这并不意味着关系数据库是完美的，关系数据库存在如下缺点：
关系数据库存储的是行记录，无法存储数据结构关系数据库的 schema 扩展很不方便关系数据库在大数据场景下 I/O 较高关系数据库的全文搜索功能比较弱 针对关系型数据库的这些问题，分别诞生了不同的 NoSQL 解决方案，这些方案，在某些场景下，能大大提升服务性能。但是，这也是有代价的，它本质上是牺牲 ACID 中的某个或者某几个特性。因此我们不能盲目地迷信 NoSQL 是银弹，而应该将 NoSQL 作为 SQL 的一个有力补充，NoSQL != No SQL，而是 NoSQL = Not Only SQL。
1.K-V 存储 K-V 存储的全称是 Key-Value 存储，其中 Key 是数据的标识，和关系数据库中的主键含义一样，Value 就是具体的数据。它解决关系数据库无法存储数据结构的问题，以 Redis 为代表，并且其 value 支持多种数据结构（String、LIst、Set、Sort set、Hash），所以常常又被称为数据结构服务器。 Redis 的缺点主要体现在并不支持完整的 ACID 事务，虽然提供事务功能，但与关系型数据的事物相比而言，犹如小巫见大巫，所以 Redis 的事物又可称为弱事物。只能保证隔离性和一致性（I 和 C），无法保证原子性和持久性（A 和 D）。 虽然 Redis 事物没有严格遵循 ACID 原则，但实际上大部分业务也不需要严格遵循 ACID 原则。因此我们在设计方案时，需要根据业务特性和要求来确定是否可以用 Redis，而不能因为 Redis 不遵循 ACID 原则就直接放弃。
2.文档数据库 为了解决关系数据库 schema 带来的问题，文档数据库应运而生，其中以 MongoDB 为代表。文档数据库大的特点就是 no-schema，可以存储和读取任意的数据。目前绝大部分文档数据库存储的数据格式是JSON（或者 BSON），因为 JSON 数据是自描述的，无须在使用前定义字段，读取一个 JSON 中不存在的字段也不会导致 SQL 那样的语法错误。文档数据库带来的优势主要有：
新增字段简单历史数据不会出错可以很容易存储复杂数据 文档数据库的这个特点，特别适合当前电商和游戏这类的业务场景。其中以电商为例，不同商品的属性差异很大，如果使用关系数据库来存储数据，就会很麻烦，而使用文档数据库，会简单、方便许多，扩展新的属性也更加容易（只需要一个 JSON 描述即可）。
文档数据库也不是没有缺点的，首先，就是文档性数据库（MongoDB）是不支持事物的，因此某些对事务要求严格的业务场景是不能使用文档数据库的；其次，是无法实现关系数据库的 join 操作，需要查询多次。
3.列式数据库 顾名思义，列式数据库就是按照列来存储数据的数据库，它解决关系数据库大数据场景下的 I/O 问题，以 HBase 为代表。 传统的关系型数据库，我们又称为“行式数据库”，因为关系数据库是按照行来存储数据的。与这里的“列式数据库”形成了强烈的对比。之所以要使用列式存储的方式，主要是因为一些业务会对海量数据进行统计（如：统计金额），而这种统计使用“行式数据库”来实现的话，即使终只使用一列，也会将所有行数据都读取出来（排除 MySQL 的一些索引优化）。从而使 I/O 飙升；同时，每列的值放在一起存储，其压缩比会更好，文件压缩的收益会更大。 但是，如果需要频繁地更新多个列，“列式数据库”的特性又会成为它的劣势，因为列式存储将不同列存储在磁盘上不连续的空间，导致更新多个列时磁盘是随机写操作；而“行式数据库”存储时同一行多个列都存储在连续的空间，一次磁盘写操作就可以完成，列式存储的随机写效率要远远低于行式存储的写效率。此外，列式存储高压缩率在更新场景下也会成为劣势，因为更新时需要将存储数据解压后更新，然后再压缩，后写入磁盘。 因此，列式存储一般都应用在离线的大数据分析和统计场景中。
4.全文搜索引擎 传统的关系型数据库通过索引来达到快速查询的目的，但是在全文搜索的业务场景下，索引也无能为力，而全文搜索引擎解决关系数据库的全文搜索性能问题，其中以 Elasticsearch 为代表。
基本原理：
全文搜索引擎的技术原理被称为“倒排索引”（Inverted index），也常被称为反向索引、置入档案或反向档案，它是一种索引方法，其基本原理是建立单词到文档的索引。之所以被称为“倒排”索引，是和“正排“索引相对的，“正排索引”的基本原理是建立文档到单词的索引。 如果说“正排索引”是根据文档名称来查询文档内容，那么“倒排索引”就是根据关键词（文档内容的分词）
使用方式：
全文搜索引擎的索引对象是单词和文档，与关系数据库的索引对象（键和行）相差甚远。因此，为了让全文搜索引擎支持关系型数据的全文搜索，需要做一些转换操作，即将关系型数据转换为文档数据。 目前常用的转换方式是将关系型数据按照对象的形式转换为 JSON 文档，然后将 JSON 文档输入全文搜索引擎进行索引。全文搜索引擎能够基于 JSON 文档建立全文索引，然后快速进行全文搜索。
5.总结 不管是 SQL 还是 NoSQL，都有各自的缺点和优点，都不是完美的，在做架构设计的时候，需要根据当前的业务需要来进行选择，只有合适的架构，没有好的架构。 关系型和NoSQL数据库的选型，可以从以下几个指标进行考虑：数据量、并发量、实时性、一致性要求、读写分布和类型、安全性、运维性等。根据这些指标，软件系统可分成以下几类：
管理型系统
如运营类、后台管理类等系统，首*选关系型数据库。大流量系统
如电商单品页的某个服务，后台可选关系型；前台可选内存型（Redis、MongoDB）。日志型系统
原始数据采用列式存储；而日志的搜索就采用倒排索引（Elasticsearch）。搜索型系统
如果只是站内搜索，非通用搜索，如商品搜索，可选关系型；前台的搜索使用倒排索引。事务型系统
如库存、交易、记账等系统，一般选关系型 + 缓存 + 一致性协议，或新型关系数据库。离线计算
如大量数据分析，首*选列式，其次关系型也可以。实时计算
如实时监控，可以选时序数据库，也可以选列式数据库。
