NoSQL数据存储
传统的架构方法是在服务之间共享一个数据库，而微服务却与之相反，每个微服务都拥有独立、自主、专门的数据存储。微服务数据存储是基础设施构建的重点，因为它提供服务解耦、数据存储自主性、小型化开发、测试设置等特性，有助于应用程序更快地交付或更新。选择理想的数据存储的第一步是确定微服务数据的性质，可以根据数据的特点将数据大致做如下划分。
全局共享数据：缓存服务器是存储短暂数据很好的例子。它是一个临时数据存储，其目的是通过实时提供信息来改善用户体验。
事务数据：从交易（如付款处理和订单处理）收集的数据必须作为永久记录存储在支持强ACID控制的数据库中。
加速数据：日志、消息和信号等数据通常以高容量和速度到达。数据提取服务通常要在将其传递到适当的目的地之前处理该信息，这样的数据存储需要支持高速写入。如果额外支持时间序列数据和内置JSON功能，会是一个加分项。瞬态数据的持久性要求高于短暂数据，但不如交易数据高。
操作数据：从用户会话收集的信息（如用户基本资料、订单信息）被视为操作数据。微服务器需要提供更好的用户体验与实时反馈，即使存储在数据库中的数据不是永久的记录，架构也必须尽最大努力保留数据以实现业务的连续性。对于操作数据，数据的持久性、一致性和可用性要求很高。通常，
企业会把操作数据放在特定的数据模型中。
为了优化微服务以获得性能和数据持久性要求，一定要确认所选的数据库为数据类型提供了适当的存储技术。我们可以对微服务及其各自的数据存储进行分类，如下表所示。
如果追求高性能，那么纯内存数据库是理想的选择。
如果追求持久性，那么数据复制及磁盘或闪存上的持久性是最好的解决方案。
如果追求事务一致性和复杂的关联查询，则可以采用数据库查询。
如 果 追 求 查 询 性 能 ， 高 速 写 入 数 据 ， 则 可 以 选 择Elasticsearch。
如果是对JSON类数据的写入和读取，则可以使用文档数据库。
如果选择写入时序类型数据，则可以使用时序性数据库。
下面是四类常见的NoSQL方案。
K-V存储：解决关系数据库无法存储数据结构的问题，主要适合对全局数据进行快速查找的低延时、高性能场景，以Redis为代表。
文档数据库：解决关系数据库强Schema约束的问题，主要适合动态模式变更和支持敏捷开发的场景，以MongoDB为代表。
列式数据库：解决关系数据库在大数据场景下的I/O问题，主要适合对数据量比较大或者对数据统计OLAP和聚合统计的场景，以HBase为代表。
全文搜索引擎：解决关系数据库的全文搜索性能问题，主要适
合检索及过滤，以Elasticsearch为代表。
下面来介绍各种高性能NoSQL方案的典型特征和应用场景。
K-V存储
K-V存储指按照键值（Key-Value）进行的数据存储，其中Key是数据的标识，和关系数据库中的主键含义一样；Value是具体的数据。
Redis是K-V存储的典型代表，它是一款开源（基于BSD许可）的高性能K-V缓存和存储系统。Redis的Value是具体的数据结构，包括string、hash、list、set、sorted set、bitmap和hyperloglog，所以常被称为数据结构服务器。
K-V存储适合作为分布式内存缓存的解决方案。在微服务架构中，微服务共享的一些全局数据都保存在K-V存储中，例如，用户信息（如会话）、分布式锁、配置文件、参数、购物车等。这些信息一般都和ID挂钩。通过键值操作就可以获得共享的Value，Redis提供的主从复制模式（Replication-Sentinel模式）和集群模式（Redis-Cluster模式）可以很好地提供多数据中心、多向复制等高度可用性和高度扩展性。Redis高性能的数据存储总结下来有下面几个原因。
Redis将所有数据放在内存中，内存的响应时间大约为100ns，这是Redis达到每秒万级别访问的重要基础。
非阻塞I/O特性，Redis使用epoll作为I/O多路复用技术的实现，再加上Redis自身的事件处理模型，将epoll中的链接、读写、关闭都转换为事件，不在网络I/O上耗费时间。
单线程避免了线程切换和锁产生的消耗。
Redis全程使用hash结构，读取速度快，还有一些特殊的数据结构，对数据存储进行了优化。如压缩表，对短数据进行压缩存储；再如跳表，使用有序的数据结构加快读取的速度。
文档数据库
为了解决关系数据库Schema带来的问题，文档数据库应运而生。MongoDB作为文档数据库的典型代表，是专为可扩展性、高性能和高可用性设计的数据库。它可以从单服务器部署扩展到大型、复杂的多数据中心架构。利用内存计算的优势，MongoDB能够提供高性能的数据读写操作。MongoDB的本地复制和自动故障转移功能使应用程序具有企业级的可靠性和操作灵活性。
文档数据库最大的特点就是No-Schema（不使用表结构）存储和可读取任意数据。目前绝大部分文档数据库存储的数据格式是JSON，因为JSON数据是自描述的，读取一个JSON中不存在的字段也不会导致SQL那样的语法错误。文档数据库的No-Schema特性，为业务开发带来了几个明显的优势。
新增字段简单：业务上增加新的字段，无须再像关系数据库一样先执行DDL修改表结构，程序代码直接读写即可。
容易兼容历史数据：对于历史数据，即使没有新增的字段，也不会导致错误，只会返回空值，此时对代码进行兼容处理即可。
容易存储复杂数据：JSON是一种强大的描述语言，能够描述复杂的数据结构。使用JSON来描述数据，比使用关系数据库表来描述数据要方便和容易得多，而且更加容易理解。同时，对于很多数据在属性差别比较大的情况下，也比较适合采用文档数据库；对于属性变更的场景，关系数据库需要使用DDL重新定义表字段，而文档数据库则更加方便。
列式数据库
顾名思义，列式数据库就是按照列来存储数据的数据库，与之对应的传统关系数据库被称为“行式数据库”，关系数据库就是按照行来存储数据的。
HBase是一个开源的非关系分布式数据库，它参考了谷歌的BigTable建模，实现的编程语言为Java。它是Apache软件基金会Hadoop项目的一部分，运行于HDFS文件系统上，为Hadoop提供类似BigTable规模的服务。因此，它可以存储海量稀疏的数据。HBase基于LSM树实现，它将对数据的修改增量保持在内存中，达到指定的大小后将这些修改操作批量写入磁盘。在极端情况下，写性能比MySQL高一个数量级，读性能低一个数量级，所以列式数据库的适用场景，以HBase为例说明如下：
适合大数据量（100TB级数据），有快速随机访问的需求。
适合写密集型应用，每天写入量巨大，比如即时消息的历史消息、游戏日志等。
适合不需要使用复杂查询条件来查询数据的应用。HBase只支持基于Rowkey的查询，对于HBase来说，单条记录或者小范围的查询是可以接受的。但由于分布式的原因，大范围的查询可能在性能上有影响。HBase不适用于使用级联、多级索引、表关系复杂的数据模型。
适合数据量较大且增长量无法预估的应用，以及需要进行优雅的数据扩展的应用。HBase支持在线扩展，即使在一段时间内，数据量呈井喷式增长，也可以通过HBase横向扩展来满足功能需求。
全文搜索引擎
传统的关系数据库通过索引来达到快速查询的目的，但是在全文搜索的业务场景下，索引也无能为力，主要体现在：全文搜索的条件可以随意排列组合，如果通过索引来满足，则索引的数量会非常多。
全文搜索的模糊匹配方式，索引无法满足，只能用like查询，而like查询是整表扫描的，效率非常低。全文搜索引擎（又称为倒排索引）的基本原理是建立单词到文档的索引。而正排索引的基本原理是建立文档到单词的索引。Elasticsearch是一个分布式可扩展的实时搜索和分析引擎，一个建立在全文的搜索引擎。当然Elasticsearch并不像Apache Lucene那么简单，它不仅具有全文搜索功能，还具有下列特性和能力：
分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索。
实时分析的分布式搜索引擎。
横向可扩展性：作为大型分布式集群，很容易就能扩展新的服务器到ES集群中，处理PB级别的结构化或非结构化数据；也可运行在单机上作为轻量级搜索引擎使用。
更丰富的功能：与传统的关系数据库相比，Elasticsearch提供了全文检索、同义词处理、相关度排名、复杂数据分析、海量数据的近实时处理等功能。
分片机制提供更好的分布性：同一个索引被分为多个分片（Shard），利用分而治之的思想提升处理效率。
高可用：提供副本（Replica）机制，一个分片可以设置多个副本，即使在某些服务器宕机后，集群仍能正常工作。
开箱即用：提供简单易用的API，使服务的搭建、部署和使用都很容易被操作。
下表是一份简易的Elasticsearch和关系数据库的术语对照表。
一个Elasticsearch集群可以包含多个索引（数据库），也就是说可以包含很多类型。这些类型中包含了很多的文档（行），然后每个文档中又都包含了很多字段（列）。Elasticsearch的交互可以使用Java Native API，也可以使用HTTP的Restful API。Elasticsearch通过Lucene的倒排索引技术可以实现比关系数据库更快的过滤。
Elasticsearch可以为任何形式的数据提供出色的搜索和分析，通过Kibana提供交互式控制面板。我们经常使用Elasticsearch来调试日志用例。
本文给大家讲解的内容是微服务数据架构，数据分类及存储特性，NoSQL数据存储
- 下篇文章给大家讲解的内容是微服务数据架构，数据分类及存储特性，Spring Data
- 觉得文章不错的朋友可以转发此文关注小编；
- 感谢大家的支持！