关系型、非关系型数据库存储选型盘点大全( 二 )

为了提供丰富的查询能力，通常热点表都会有多个二级索引，一旦有了二级索引，数据的新增必然伴随着所有二级索引的新增，数据的更新也必然伴随着所有二级索引的更新，这不可避免地降低了关系型数据库的读写能力，且索引越多读写能力越差。除了数据文件不可避免地占空间外，索引占的空间其实也并不少。水平扩展后带来的种种问题难处理
随着业务规模扩大，一种方式是对数据库做分库，做了分库之后，数据迁移（1个库的数据按照一定规则打到2个库中）、跨库join、分布式事务处理都是需要考虑的问题，尤其是分布式事务处理，业界当前都没有特别好的解决方案。全文搜索功能弱
例如like“%新年快乐%” ，只能搜索到“新年快乐，爱大家” ，无法搜索到“新年真是太快乐了，爱大家”这样的文本，即不具备分词能力，且like查询在“%新年快乐”这样的搜索条件下，无法命中索引，将会导致查询效率大大降低。表结构扩展不方便
由于数据库存储的是结构化数据，因此表结构schema是固定的，扩展不方便，如果需要修改表结构，需要执行DDL（datadefinitionlanguage）语句修改，修改期间会导致锁表，部分服务不可用。
如上文所分析的，关系型数据库优点明显，缺点同样不能忽视，因此通常在企业规模不断扩大的情况下，不会一味指望通过增强数据库的能力来解决数据存储问题，而是会引入其他存储，也就是我们说的NoSql 。
NoSql的全称为NotOnlySQL ，泛指非关系型数据库，是对关系型数据库的一种补充，特别注意补充这两个字，这意味着NoSql与关系型数据库并不是对立关系，二者各有优劣，取长补短，在合适的场景下选择合适的存储引擎才是正确的做法。
下面看一下常用的NoSql及他们的代表产品，并对每种NoSql的优缺点和适用场景做一下分析，便于熟悉每种NoSql的特点，方便技术选型。
1、KV型NoSql（代表——Redis）
KV型NoSql顾名思义就是以键值对形式存储的非关系型数据库，是最常见的一种NoSql 。 Redis、MemCache是其中的代表， Redis又是KV型NoSql中应用最广泛的NoSql ， KV型数据库以Redis为例，最大的优点总结下来主要有两点：数据基于内存，读写效率高。 KV型数据，时间复杂度为O(1) ，查询速度快。
所以说， KV型NoSql最大的优点就是高性能，利用Redis自带的BenchMark做基准测试， TPS可达到10万的级别，性能非常强劲。同样的Redis也有所有KV型NoSql都有的比较明显的缺点：内存是有限的，无法支持海量数据存储。只能根据K查V ，无法根据V查K 。查询方式单一，只有KV的方式，不支持条件查询，多条件查询唯一的做法就是数据冗余，但这会浪费很多存储空间。由于KV型NoSql的存储是基于内存的，会有丢失数据的风险（有持久化存储方案）。
综上所述， KV型NoSql最合适的场景就是缓存的场景：读远多于写。没有持久化的需求，可以容忍数据丢失。
针对那些读远多于写的数据，引入一层缓存，每次读从缓存中读取，缓存中读取不到，再去数据库中取，取完之后再写入到缓存，对数据做好失效机制通常就没有大问题了。通常来说，缓存是性能优化的第一选择也是见效最明显的方案。
2、搜索型NoSql（代表——ElasticSearch）
传统关系型数据库主要通过索引来达到快速查询的目的，但是在全文搜索的场景下，索引是无能为力的， like查询无法满足所有模糊匹配需求，使用限制太大且使用不当容易引起慢查询问题，搜索型NoSql的诞生正是为了解决关系型数据库全文搜索能力较弱的问题， ElasticSearch是搜索型NoSql的代表产品。