NoSQL的分类

关系数据库 的缺点

1 关系数据库的 schema扩展很不方便关系数据库的表结构 schema是强约東,操作不存在的列会报错,业务变化时扩充列也比较麻烦需要执行DDL( data definition language,如 CREATE、 ALTER、DROP等)语句修改,而且修改时可能会长时间锁表(例妙如, MYSQL可能将表锁住1个小时)

2 关系数据库在大数据场景下/O较如果对一些大量数据的表进行统计之类的运算,关系数据库的/O会很高,因为即使只针对其中某列进行运算,关系数据库也会将整行数据从存储设备读入内存`

3 关系数据库的全文搜索功能比较弱关系数据库的全文搜索只能使用ike进行整表扫描匹配,性能非常低,在互联网这种搜索复杂的场下无法满足业务要求

NoSQL解决方案

针对上述问题,分别诞生了不同的 NOSQL解決方案,这些方案与关系数据库相比,在某些应用场下表现更好。
但世上没有免费的午餐, NOSQL方案带来的优势,本质上是牺牲ACID中的某或者某几个特性,因此我们不能
言目地迷信 NOSQL是银弹,而应该将 NOSQL作为力补充, NOSQL!= No SQL,而是 NOSQL= Not Only SQL
常见的 NOSQL方案分为4类：
K-V存储:解決关系数据库无法存储数据结构的可题,以 Redis为代表
文档数据库:解决关系数据库强 schema约束的可题ONGODB为代表
列式数据库:解决关系数据库大数据场景下的 I/O 问题,以 Hbase为代表
全文搜索引擎:解决关系数据库的全文搜索性能问题,以 Elasticsearch为代表

关系型和NoSQL数据库的选型。

考虑几个指标，数据量、并发量、实时性、一致性要求、读写分布和类型、安全性、运维性等。根据这些指标，软件系统可分成几类。
1.管理型系统，如运营类系统，首选关系型。
2.大流量系统，如电商单品页的某个服务，后台选关系型，前台选内存型。
3.日志型系统，原始数据选列式，日志搜索选倒排索引。
4.搜索型系统，指站内搜索，非通用搜索，如商品搜索，后台选关系型，前台选倒排索引。
5.事务型系统，如库存、交易、记账，选关系型+缓存+一致性协议，或新型关系数据库。
6.离线计算，如大量数据分析，首选列式，关系型也可以。
7.实时计算，如实时监控，可以选时序数据库，或列式数据库。