Sql Or NoSql？看完之后你就应该懂了( 四 ) _NoSql

搜索型NoSql以ElasticSearch为例，它的优点为：

支持分词场景、全文搜索，这是区别于关系型数据库最大特点
支持条件查询，支持聚合操作，类似关系型数据库的Group By，但是功能更加强大，适合做数据分析
数据写文件无丢失风险，在集群环境下可以方便横向扩展，可承载PB级别的数据
高可用，自动发现新的或者失败的节点，重组和重新平衡数据，确保数据是安全和可访问的

同样，ElasticSearch也有比较明显的缺点：

性能全靠内存来顶，也是使用的时候最需要注意的点，非常吃硬件资源、吃内存，大数据量下64G + SSD基本是标配，算得上是数据库中的爱马仕了。为什么要专门提一下内存呢，因为内存这个东西是很值钱的，相同的配置多一倍内存，一个月差不多就要多花几百块钱，至于ElasticSearch内存用在什么地方，大概有如下这些：
Indexing Buffer----ElasticSearch基于Luence，Lucene的倒排索引是先在内存里生成，然后定期以Segment File的方式刷磁盘的，每个Segment File实际就是一个完整的倒排索引
Segment Memory----倒排索引前面说过是基于关键字的，Lucene在4.0后会将所有关键字以FST这种数据结构的方式将所有关键字在启动的时候全量加载到内存，加快查询速度，官方建议至少留系统一半内存给Lucene
各类缓存----Filter Cache、Field Cache、Indexing Cache等，用于提升查询分析性能，例如Filter Cache用于缓存使用过的Filter的结果集
Cluter State Buffer----ElasticSearch被设计为每个Node都可以响应用户请求，因此每个Node的内存中都包含有一份集群状态的拷贝，一个规模很大的集群这个状态信息可能会非常大
读写之间有延迟，写入的数据差不多1s样子会被读取到，这也正常，写入的时候自动加入这么多索引肯定影响性能
数据结构灵活性不高，ElasticSearch这个东西，字段一旦建立就没法修改类型了，假如建立的数据表某个字段没有加全文索引，想加上，那么只能把整个表删了再重建

因此，搜索型NoSql最适用的场景就是有条件搜索尤其是全文搜索的场景，作为关系型数据库的一种替代方案。
另外，搜索型数据库还有一种特别重要的应用场景。我们可以想，一旦对数据库做了分库分表后，原来可以在单表中做的聚合操作、统计操作是否统统失效？例如我把订单表分16个库，1024张表，那么订单数据就散落在1024张表中，我想要统计昨天浙江省单笔成交金额最高的订单是哪笔如何做？我想要把昨天的所有订单按照时间排序分页展示如何做？这就是文档型NoSql的另一大作用了，我们可以把分表之后的数据统一打在文档型NoSql中，利用文档型NoSql的搜索与聚合能力完成对全量数据的查询。
至于为什么把它放在KV型NoSql后面作为第二个写呢，因为通常搜索型NoSql也会作为一层前置缓存，来对关系型数据库进行保护。
列式NoSql（代表----HBase）列式NoSql，大数据时代最具代表性的技术之一了，以HBase为代表。
列式NoSql是基于列式存储的，那么什么是列式存储呢，列式NoSql和关系型数据库一样都有主键的概念，区别在于关系型数据库是按照行组织的数据：

文章插图

看到每行有name、phone、address三个字段，这是行式存储的方式，且可以观察id = 2的这条数据，即使phone字段没有，它也是占空间的。
列式存储完全是另一种方式，它是按每一列进行组织的数据：

文章插图

文章插图

这么做有什么好处呢？大致有以下几点：

查询时只有指定的列会被读取，不会读取所有列
存储上节约空间，Null值不会被存储，一列中有时候会有很多重复数据（尤其是枚举数据，性别、状态等），这类数据可压缩，行式数据库压缩率通常在3:15:1之间，列式数据库的压缩率一般在8:130:1左右
列数据被组织到一起，一次磁盘IO可以将一列数据一次性读取到内存中

第二点说到了数据压缩，什么意思呢，以比较常见的字典表压缩方式举例：