高性能 NoSQL
############

常见的 NoSQL 方案分为 4 类::

    1. K-V 存储：解决关系数据库无法存储数据结构的问题，以 Redis 为代表
    2. 文档数据库：解决关系数据库强 schema 约束的问题，以 MongoDB 为代表
    3. 列式数据库：解决关系数据库大数据场景下的 I/O 问题，以 HBase 为代表
    4. 全文搜索引擎：解决关系数据库的全文搜索性能问题，以 Elasticsearch 为代表

K-V 存储
========

.. note:: K-V 存储的全称是 Key-Value 存储，其中 Key 是数据的标识，和关系数据库中的主键含义一样，Value 就是具体的数据。

Redis 的缺点主要体现在并不支持完整的 ACID 事务，Redis 虽然提供事务功能，但 Redis 的事务和关系数据库的事务不可同日而语，Redis 的事务只能保证隔离性和一致性（I 和 C），无法保证原子性和持久性（A 和 D）


文档数据库
==========

.. note:: 文档数据库最大的特点就是 no-schema，可以存储和读取任意的数据。目前绝大部分文档数据库存储的数据格式是 JSON（或者 BSON），因为 JSON 数据是自描述的，无须在使用前定义字段，读取一个 JSON 中不存在的字段也不会导致 SQL 那样的语法错误。


文档数据库的 no-schema 特性，给业务开发带来了几个明显的优势::

    1. 新增字段简单
    业务上增加新的字段，无须再像关系数据库一样要先执行 DDL 语句修改表结构，程序代码直接读写即可
    2. 历史数据不会出错
    对于历史数据，即使没有新增的字段，也不会导致错误，只会返回空值，此时代码进行兼容处理即可
    3. 可以很容易存储复杂数据
    JSON 是一种强大的描述语言，能够描述复杂的数据结构

.. note:: 文档数据库的这个特点，特别适合电商和游戏这类的业务场景


文档数据库 no-schema 的特性带来的这些优势也是有代价的::

    最主要的代价就是不支持事务
    另外一个缺点就是无法实现关系数据库的 join 操作

列式数据库
==========

.. note:: 列式数据库就是按照列来存储数据的数据库，与之对应的传统关系数据库被称为 “行式数据库”

关系数据库按照行式来存储数据，主要有以下几个优势::

    1. 业务同时读取多个列时效率高，因为这些列都是按行存储在一起的，一次磁盘操作就能够把一行数据中的各个列都读取到内存中。
    2. 能够一次性完成对一行中的多个列的写操作，保证了针对行数据写操作的原子性和一致性；
        否则如果采用列存储，可能会出现某次写操作，有的列成功了，有的列失败了，导致数据不一致。

列式存储的优势::

    1. 节省 I/O
        海量数据进行统计场景。
        例如，
          计算某个城市体重超重的人员数据，实际上只需要读取每个人的体重这一列并进行统计即可，
          而行式存储即使最终只使用一列，也会将所有行数据都读取出来。
        如果单行用户信息有 1KB，其中体重只有 4 个字节，
        行式存储还是会将整行 1KB 数据全部读取到内存中，这是明显的浪费。
        而如果采用列式存储，每个用户只需要读取 4 字节的体重数据即可
    2. 列式存储还具备更高的存储压缩比，能够节省更多的存储空间
        普通的行式数据库一般压缩率在 3:1 到 5:1 左右，
        而列式数据库的压缩率一般在 8:1 到 30:1 左右，
        因为单个列的数据相似度相比行来说更高，能够达到更高的压缩率。

如果场景发生变化，列式存储的优势又会变成劣势::

    典型的场景是需要频繁地更新多个列。
    因为列式存储将不同列存储在磁盘上不连续的空间，导致更新多个列时磁盘是随机写操作；
    而行式存储时同一行多个列都存储在连续的空间，一次磁盘写操作就可以完成，
    列式存储的随机写效率要远远低于行式存储的写效率。
    此外，列式存储高压缩率在更新场景下也会成为劣势，因为更新时需要将存储数据解压后更新，然后再压缩，最后写入磁盘。



.. note:: 基于上述列式存储的优缺点，一般将列式存储应用在离线的大数据分析和统计场景中，因为这种场景主要是针对部分列单列进行操作，且数据写入后就无须再更新删除。


全文搜索引擎
============

传统的关系型数据库索引对全文索引无能为力，主要体现在::

    1. 全文搜索的条件可以随意排列组合，如果通过索引来满足，则索引的数量会非常多。
    2. 全文搜索的模糊匹配方式，索引无法满足，只能用 like 查询，而 like 查询是整表扫描，效率非常低。


1. 全文搜索基本原理::

    全文搜索引擎的技术原理被称为 “倒排索引”（Inverted index），也常被称为反向索引、置入档案或反向档案，是一种索引方法，
    其基本原理是建立单词到文档的索引。
    之所以被称为 “倒排” 索引，是和 “正排 “索引相对的，“正排索引” 的基本原理是建立文档到单词的索引


正排索引::

    适用于根据文档名称来查询文档内容。
    例如，用户在网站上单击了 “面向对象葵花宝典是什么”，网站根据文章标题查询文章的内容展示给用户。

倒排索引示例::

    适用于根据关键词来查询文档内容。
    例如，用户只是想看 “设计” 相关的文章，网站需要将文章内容中包含 “设计” 一词的文章都搜索出来展示给用户

2. 全文搜索的使用方式::

    全文搜索引擎的索引对象是单词和文档，而关系数据库的索引对象是键和行。
    因此，为了让全文搜索引擎支持关系型数据的全文搜索，需要做一些转换操作，即将关系型数据转换为文档数据。
      目前常用的转换方式是将关系型数据按照对象的形式转换为 JSON 文档，然后将 JSON 文档输入全文搜索引擎进行索引


Elasticsearch 索引基本原理如下::

    Elastcisearch 是分布式的文档存储方式。
    它能存储和检索复杂的数据结构 —— 序列化成为 JSON 文档 —— 以实时的方式。
    在 Elasticsearch 中，每个字段的所有数据都是默认被索引的。
    即每个字段都有为了快速检索设置的专用倒排索引。
    而且，它能在相同的查询中使用所有倒排索引，并以惊人的速度返回结果