学习笔记-16 高性能NoSQL

关系数据库优点：强大的 SQL 功能和 ACID 的属性
关系数据库缺点：

1. 关系数据库存储的是行记录，无法存储数据结构
2. 关系数据库的 schema (表头)扩展很不方便，修改时可能会长时间锁表
3. 关系数据库在大数据场景下 I/O 较高
4. 关系数据库的全文搜索功能比较弱

针对上述问题，分别诞生了不同的 NoSQL 解决方案，这些方案与关系数据库相比，在某些应用场景下表现更好。但世上没有免费的午餐，NoSQL 方案带来的优势，本质上是牺牲 ACID 中的某个或者某几个特性，因此我们不能盲目地迷信 NoSQL 是银弹，而应该将 NoSQL 作为 SQL 的一个有力补充，NoSQL != No SQL，而是 NoSQL = Not Only SQL。常用关系型数据库 Oracle、DB2、MySQL、Microsoft SQL Server、Microsoft Access

常见的 NoSQL 方案分为 4 类。

• K-V 存储：解决关系数据库无法存储数据结构的问题，以 Redis 为代表。没有严格遵循 ACID 原则，Redis 的事务只能保证隔离性和一致性（I 和 C），无法保证原子性和持久性（A 和 D）
• 文档数据库：解决关系数据库强 schema 约束的问题，以 MongoDB 为代表，目前绝大部分文档数据库存储的数据格式是 JSON（或者 BSON）。新增字段简单、历史数据不会出错、可以很容易存储复杂数据。他的json格式数据适合电商和游戏这类的业务场景。
• 列式数据库：解决关系数据库大数据场景下的 I/O 问题，以 HBase 为代表。列式数据库的压缩率一般在 8:1 到 30:1 左右，如果需要频繁地更新多个列压缩优势也会变成劣势，因为更新时需要将存储数据解压后更新，然后再压缩，最后写入磁盘。基于上述列式存储的优缺点，一般将列式存储应用在离线的大数据分析和统计场景中，因为这种场景主要是针对部分列单列进行操作，且数据写入后就无须再更新删除。
• 全文搜索引擎：解决关系数据库的全文搜索性能问题，以 Elasticsearch 为代表。全文搜索引擎的技术原理被称为“倒排索引”（Inverted index），也常被称为反向索引、置入档案或反向档案，全文搜索引擎能够基于 JSON 文档建立全文索引，然后快速进行全文搜索。以 Elasticsearch 为例

思考：如何选择数据库
需求驱动架构，无论选用RDB(关系数据库)/NoSQL/DRDB(内存数据库)，一定是以需求为导向，最终的数据存储方案也必然是各种权衡的设计妥协。

关系型(RDB)和NoSQL数据库的选型。考虑几个指标，数据量、并发量、实时性、一致性要求、读写分布和类型、安全性、运维性等。根据这些指标，软件系统可分成几类。
1.管理型系统，如运营类系统，首选关系型。
2.大流量系统，如电商单品页的某个服务，后台选关系型，前台选内存型。
3.日志型系统，原始数据选列式，日志搜索选倒排索引。
4.搜索型系统，指站内搜索，非通用搜索，如商品搜索，后台选关系型，前台选倒排索引。
5.事务型系统，如库存、交易、记账，选关系型+缓存+一致性协议，或新型关系数据库。
6.离线计算，如大量数据分析，首选列式，关系型也可以。
7.实时计算，如实时监控，可以选时序数据库，或列式数据库。
No SQL并非银弹，如ACID方面就无法跟关系型数据库相比，实际运用中，需要根据业务场景来分析，比较好的做法是，No SQL+关系型数据库结合使用，取长补短。如我们之前的做法是将商品/订单/库存等相关基本信息放在关系型数据库中(如MySQL，业务操作上支持事务，保证逻辑正确性)，缓存可以用Redis(减少DB压力)，搜索可以用Elasticsearch(提升搜索性能，可通过定时任务定期将DB中的信息刷到ES中)。

学习地址：16 | 高性能NoSQL https://time.geekbang.org/column/article/8377