深入解读NOSQL

忘是亡心i 2024-03-31 12:39 20阅读 0赞

## 前言 ##

随着大数据时代的来临，数据类型繁多，包括结构化数据和各种非结构化数据，其中非结构化数据的比例高达90%以上，传统的关系型数据库由于数据类型不灵活、水平扩展能力较差等局限性，已无法满足各种类型的非结构化数据的大规模存储需求。

## NOSQL简介 ##

Nosql是Not Only SQL简写，从字面意思上就可以理解为不仅仅是SQL。

百度百科上是这样描述的：

> NoSQL仅仅是一个概念，泛指非关系型的数据库，区别于关系数据库，它们不保证关系数据的ACID特性。NoSQL是一项全新的数据库革命性运动，其拥护者们提倡运用非关系型的数据存储，相对于铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。
> 
> 百度百科

NoSQL是一种下一代数据库管理系统 (DBMS)。NoSQL 数据库具有灵活的模式，可用于构建具有大量数据和高负载的现代应用程序。

NoSQL一词最早出现于1998年，是Carlo Strozzi开发的一个轻量、开源、不提供SQL功能的关系数据库。

2009年，Last.fm的Johan Oskarsson发起了一次关于分布式开源数据库的讨论，来自Rackspace的Eric Evans再次提出了NOSQL的概念，这时的NOSQL主要指非关系型、分布式、不提供ACID的数据库设计模式。

2009年，在亚特兰大举行的"no:sql(east)"讨论会是一个里程碑，其口号是"select fun, profit from real\_world where relational=false;"。因此，对NOSQL最普遍的解释是“非关联型的”，强调键-值存储和面向文档数据库的优点，而不是单纯的反对RDBMS。

在处理大量数据时，任何关系数据库管理系统 (RDBMS) 的响应时间都会变慢。为了解决这个问题，我们可以通过升级现有硬件来“扩大”信息系统，这非常昂贵。但是，NoSQL 可以更好地横向扩展并且更具成本效益。

NoSQL 对于非结构化或非常大的数据对象（例如聊天日志数据、视频或图像）非常有用，这就是为什么 NoSQL 在微软、谷歌、亚马逊、Meta (Facebook) 等互联网巨头中特别受欢迎的原因。

## NOSQL特点 ##

1.  方便扩展，数据之间没有关系，方便扩展。
2.  大数据量高性能（Redis秒写8w，秒读11w），NoSQL的缓存是记录级，是一种细粒度的缓存，性能会比较高
3.  数据类型是多样型的（不需要事先去设计数据库），随取随用

RDBMS与NoSQL的区别

*  **传统的RDBMS：**

*   *  结构化组织
     *  SQL
     *  数据和关系都存在单独的表中
     *  数据操作、数据定义语言
     *  严格的一致性
     *  基础的事务操作

*  **NoSQL**

*   *  不仅仅是数据
     *  没有固定的查询语言
     *  键值对存储、列存储、文档存储、图形数据库
     *  最终一致性
     *  CAP定理和BASE
     *  高性能、高可用、高可扩展性

## 结构化数据、非结构化数据与半结构化数据 ##

首先是结构化数据，根据定义结构化数据指的是由二维表结构来逻辑表达和实现的数据，严格遵循数据格式与长度规范，也称作为行数据，特点为：数据以行为单位，一行数据表示一个实体的信息，每一行数据的属性是相同的。

因此关系型数据库完美契合结构化数据的特点，关系型数据库也是关系型数据最主要的存储与管理引擎。

非结构化数据，指的是数据结构不规则或不完整，没有任何预定义的数据模型，不方便用二维逻辑表来表现的数据，例如办公文档（Word）、文本、图片、HTML、各类报表、视频音频等。

介于结构化与非结构化数据之间的数据就是半结构化数据了，它是结构化数据的一种形式，虽然不符合二维逻辑这种数据模型结构，但是包含相关标记，用来分割语义元素以及对记录和字段进行分层。常见的半结构化数据有XML和JSON，例如：

这种结构也被成为自描述的结构。

## 关于CAP定理与BASE理论 ##

CAP理论，指的是在一个分布式系统中，Consistency(一致性)、Availability(可用性)、Partition Tolerance(分区容错性)，不能同时成立。

*  **Consistency(一致性)**

指写操作后的读操作可以读取到最新的数据状态，当数据分布在多个节点上，从任意节点读取到的数据都是最新的状态。

*  **Availability(可用性)**

可用性是指任何事务操作都可以得到响应结果，且不会出现响应超时或响应错误。

*  **Partition Tolerance(分区容错性)**

通常分布式系统的各节点部署在不同的子网，这就是网络分区，不可避免的会出现由于网络问题而导致结点之间通信失败，此时仍可对外提供服务，这叫分区容错性。

CAP 定理的基本表述是：给定"一致性"（Consistency，C）、"可用性"（Availabilty，A）、"分区耐受性"（Partition tolerance，P）三个属性，只能同时满足其中两个属性。作为分布式系统的理论，P 是必要的，所以要在 A 与 C 中做选择。===>当系统可能会遭遇"分区"状态时，我们需要在 C 和 A 之间进行权衡，综合处理来满足特定需求。

在 NoSQL 领域中，通常认为"CAP 定理"，是需要放宽一致性约束的原因。

CAP 将"可用性"一词定义为"系统中某个无障碍节点所接收的每一条请求，无论成功失败，都会得到响应"。这可以视为能够忍受的最大延迟时间，一旦延迟过高，就放弃操作，并认为数据不可用。

NoSQL 系统具备"BASE 属性"（基本可用、柔性状态、最终一致性）,ACID 与 BASE 之间存在多个逐渐过渡的权衡方案可选。

*  **Basically Available**：分布式系统在出现故障时允许损失部分可用性，以保证核心功能可用。比如在电商场景中，有时交易付款出现了问题，但用户仍可以正常浏览商品。
 *  **Soft State**：由于不要求强一致性，BASE 允许系统中存在一种不影响系统可用性的中间状态，比如订单支付中、数据同步中等，在数据达到最终一致的状态后才改为成功。
 *  **Eventually Consistent**：指经过一段时间后所有节点的数据将会达到一致。比如最终支付中的状态会变成支付成功或者支付失败；订单的状态和实际交易的过程达成一致；但这个过程有一定的时间延迟。

BASE 理论是对 CAP 中 AP 理论的扩展，通过牺牲强一致性获得可用性。当出现故障时，允许部分不可用，但能保证核心功能可用；允许数据在一段时间内不一致，但最终要达到一致。

## 常见的NOSQL数据库 ##

NoSQL 大致可以分为以下几类：

*  **K-V存储**：解决关系数据库无法存储数据结构的问题，主要适合对全局数据进行快速查找的低延时、高性能场景，以Redis为代表。
 *  **列式数据库**：解决关系数据库在大数据场景下的I/O问题，主要适合对数据量比较大或者对数据统计OLAP和聚合统计的场景，以HBase为代表。
 *  **文档数据库**：解决关系数据库强Schema约束的问题，主要适合动态模式变更和支持敏捷开发的场景，以MongoDB为代表。
 *  **全文搜索引擎**：解决关系数据库的全文搜索性能问题，主要适合检索及过滤，以Elasticsearch为代表。
 *  **图数据库**：专门使用图作为存储模型来存储数据，完全不同于键值、列族数据库和文档数据库的数据模型，可以高效存储不同顶点之间的关系，比较适用于社交网络、模式识别、以及路径寻找等问题，以neo4j为代表。
 *  **时序数据库**：提供时序数据库能力，以Graphite、InfluxDB、OpenTSDB代表。

## K-V存储 ##

可以把KV数据库看成一个简单的哈希表，主要用在所有数据库都通过主键来访问的情况下使用。Key用来定位Value，Value对数据库而言是透明不可见的，不能对Value进行索引和查询，只能对Key进行查询，Value可以用来存储任意类型的数据，比如整型、字符型、数组，还可以是对象。

此外，关系数据库很难实现横向扩展而只能通过纵向扩展的方式实现扩充，但是键值数据库是天生具有良好的伸缩性，理论上可以通过横向扩展实现无限扩容（纵向扩展需要通过更换一个更大的服务器实现，而横向扩展无需新购买更大的服务器，只需要增加一个的服务器、虚拟机或是云服务器就可以实现扩展）。键值数据库的弱项是条件查询，如果只对部分值进行查询或者更新，键值数据库的效率比较低，此外，键值数据库不支持回滚操作，所以无法支持事务。

*  产品：Riak、Redis、Memcached、Amazon’s Dynamo、Project Voldemort
 *  有谁在使用：GitHub （Riak）、BestBuy （Riak）、Twitter （Redis和Memcached）、StackOverFlow （Redis）、 Instagram （Redis）、Youtube （Memcached）、Wikipedia（Memcached）

Redis是K-V存储的典型代表，它是一款开源（基于BSD许可）的高性能K-V缓存和存储系统。Redis的Value是具体的数据结构，包括string、hash、list、set、sorted set、bitmap和hyperloglog，所以常被称为数据结构服务器。

**适用的场景**

*  缓存
 *  数据共享分布式
 *  分布式锁
 *  全局ID
 *  计数器
 *  限流
 *  位统计
 *  购物车
 *  用户消息时间线
 *  抽奖、点赞、签到、打卡、秒杀
 *  商品标签、商品筛选、用户关注、推荐模型、排行榜

**不适用场景**

*  取代通过键查询，而是通过值来查询。Key-Value数据库中根本没有通过值查询的途径。
 *  需要储存数据之间的关系。在Key-Value数据库中不能通过两个或以上的键来关联数据。
 *  事务的支持。在Key-Value数据库中故障产生时不可以进行回滚。

相对于关系型数据库而言，关系型数据库需要通过建立索引来实现加速查询（索引的原理），频繁发生写操作时，索引会发生频繁更新，因此产生维护索引的开销很大。Redis提供的主从复制模式（Replication-Sentinel模式）和集群模式（Redis-Cluster模式）可以很好地提供多数据中心、多向复制等高度可用性和高度扩展性。

Redis高性能的数据存储总结下来有下面几个原因。

*  Redis将所有数据放在内存中，内存的响应时间大约为100ns，这是Redis达到每秒万级别访问的重要基础。
 *  非阻塞I/O特性，Redis使用epoll作为I/O多路复用技术的实现，再加上Redis自身的事件处理模型，将epoll中的链接、读写、关闭都转换为事件，不在网络I/O上耗费时间。
 *  单线程避免了线程切换和锁产生的消耗。
 *  Redis全程使用hash结构，读取速度快，还有一些特殊的数据结构，对数据存储进行了优化。如压缩表，对短数据进行压缩存储；再如跳表，使用有序的数据结构加快读取的速度。

## 列存储数据库 ##

顾名思义，列式数据库就是按照列来存储数据的数据库，与之对应的传统关系数据库被称为“行式数据库”，关系数据库就是按照行来存储数据的。

*  产品：Cassandra、HBase
 *  有谁在使用：Ebay （Cassandra）、Instagram （Cassandra）、NASA （Cassandra）、Twitter （Cassandra and HBase）、Facebook （HBase）、Yahoo!（HBase）

HBase 是一个分布式、面向列的 NoSQL 数据库，是 Google Bigtable 的开源实现，底层存储基于 HDFS，原生支持 MapReduce 计算框架，实现的编程语言为Java。它是Apache软件基金会Hadoop项目的一部分，运行于HDFS文件系统上，为Hadoop提供类似BigTable规模的服务。因此，它可以存储海量稀疏的数据。HBase基于LSM树实现，它将对数据的修改增量保持在内存中，达到指定的大小后将这些修改操作批量写入磁盘。

在极端情况下，写性能比MySQL高一个数量级，读性能低一个数量级，所以列式数据库的适用场景，以HBase为例说明如下：

*  适合大数据量（100TB级数据），有快速随机访问的需求。
 *  适合写密集型应用，每天写入量巨大，比如即时消息的历史消息、游戏日志等。
 *  适合不需要使用复杂查询条件来查询数据的应用。HBase只支持基于Rowkey的查询，对于HBase来说，单条记录或者小范围的查询是可以接受的。但由于分布式的原因，大范围的查询可能在性能上有影响。HBase不适用于使用级联、多级索引、表关系复杂的数据模型。
 *  适合数据量较大且增长量无法预估的应用，以及需要进行优雅的数据扩展的应用。HBase支持在线扩展，即使在一段时间内，数据量呈井喷式增长，也可以通过HBase横向扩展来满足功能需求。

**主要特点**

*  随机读写访问
 *  分布式、面向列
 *  强一致性
 *  底层数据存储在 HDFS 之上

**适用的场景**

*  1. 日志。因为我们可以将数据储存在不同的列中，每个应用程序可以将信息写入自己的列族中。
 *  2. 博客平台。我们储存每个信息到不同的列族中。举个例子，标签可以储存在一个，类别可以在一个，而文章则在另一个。

**不适用场景**

*  1. 如果我们需要ACID事务。Vassandra就不支持事务。
 *  2. 原型设计。如果我们分析Cassandra的数据结构，我们就会发现结构是基于我们期望的数据查询方式而定。在模型设计之初，我们根本不可能去预测它的查询方式，而一旦查询方式改变，我们就必须重新设计列族。

列族数据库一般用列族数据模型，数据库由多个行构成，每行数据包含多个列族，不同的行可以具有不同数量的列族，属于同一个列族的数据会被存放在一起，以HBase为例介绍一下列族数据库的数据模型：

上图是一张用来保存学生信息的HBase表，学号作为行键来唯一标识每一个学生，表中设计了列族Info用来保存学生相关信息，列族Info中包含了三个列：name、major和email，分别用来保存学生的姓名、专业和电子邮箱信息。学号为“201505003”的学生存在两个版本的电子邮件地址，时间戳分别为ts1和ts2，时间戳较大的数据版本是最新的数据。在关系数据库中，我们可以通过行和列组成的二维坐标来定位一个具体值在获取数据的值，而在HBase中，需要通过行键、列族、列限定符和时间戳组成的一个四维坐标来获取一个值。

HBase是面向列存储的，而传统的关系型数据库是面向行存储的。行式数据库中，数据表中的每行是连续地存储在磁盘页中，数据是一行一行存储的，第一行写入磁盘页后，再写第二行，所以在查询数据的时候，需要从磁盘中顺序地扫描出每行的完整内容，然后再从这个完整的内容中筛选出这次查询所需要的属性。假设有一种情况，我们存储的某一行数据属性很多，但是其中只有一个属性是这次查询需要的，其他很多无关的属性虽然用不到，这时候由于采用的是顺序扫描，所以会扫描到很多用不到的属性值，浪费很多磁盘和内存的开销。而采用列式存储，同一个列族的数据会存储在一起，同一个属性的所有值会被存储到一起，执行查询时可以只对可以回答查询的列进行处理，而不需要处理与查询无关的数据行。

列族数据库主要适合于批量数据处理等，因为它可以降低I/O开销，支持大量并发用户查询，典型的应用是分布式数据存储与管理。

## 文档数据库 ##

为了解决关系数据库Schema带来的问题，文档数据库应运而生。MongoDB作为文档数据库的典型代表，是专为可扩展性、高性能和高可用性设计的数据库。它可以从单服务器部署扩展到大型、复杂的多数据中心架构。利用内存计算的优势，MongoDB能够提供高性能的数据读写操作。MongoDB的本地复制和自动故障转移功能使应用程序具有企业级的可靠性和操作灵活性。

文档数据库最大的特点就是No-Schema（不使用表结构）存储和可读取任意数据。目前绝大部分文档数据库存储的数据格式是JSON，因为JSON数据是自描述的，读取一个JSON中不存在的字段也不会导致SQL那样的语法错误。文档数据库的No-Schema特性，为业务开发带来了几个明显的优势。

*  新增字段简单：业务上增加新的字段，无须再像关系数据库一样先执行DDL修改表结构，程序代码直接读写即可。
 *  容易兼容历史数据：对于历史数据，即使没有新增的字段，也不会导致错误，只会返回空值，此时对代码进行兼容处理即可。
 *  容易存储复杂数据：JSON是一种强大的描述语言，能够描述复杂的数据结构。使用JSON来描述数据，比使用关系数据库表来描述数据要方便和容易得多，而且更加容易理解。同时，对于很多数据在属性差别比较大的情况下，也比较适合采用文档数据库；对于属性变更的场景，关系数据库需要使用DDL重新定义表字段，而文档数据库则更加方便。

面向文档数据库会将数据以文档的形式储存。每个文档都是自包含的数据单元，是一系列数据项的集合。每个数据项都有一个名称与对应的值，值既可以是简单的数据类型，如字符串、数字和日期等；也可以是复杂的类型，如有序列表和关联对象。数据存储的最小单位是文档，同一个表中存储的文档属性可以是不同的，数据可以使用XML、JSON或者JSONB等多种形式存储。

*  产品：MongoDB、CouchDB、RavenDB
 *  有谁在使用：SAP （MongoDB）、Codecademy （MongoDB）、Foursquare （MongoDB）、NBC News （RavenDB）

MongoDB 是一个分布式文件存储、面向文档的 NoSQL 数据库，用于大容量数据存储，提供统一的数据格式（bson），支持不同类型的索引。

**主要特点**

*  高性能、易部署、易使用，存储数据非常方便。
 *  面向集合存储，易存储对象类型的数据。
 *  支持动态查询。
 *  支持各种类型的索引
 *  支持复制和故障恢复，实现高可用性
 *  使用高效的二进制数据存储，包括大型对象（如视频等）。
 *  文件存储格式为BSON（一种JSON的扩展）。
 *  自动分片，易于扩展

**适用场景**

*  网站实时数据处理。它非常适合实时的插入、更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。
 *  缓存。由于性能很高，它适合作为信息基础设施的缓存层。在系统重启之后，由它搭建的持久化缓存层可以避免下层的数据源过载。
 *  高伸缩性的场景。非常适合由数十或数百台服务器组成的数据库，它的路线图中已经包含对MapReduce引擎的内置支持。

**不适用的场景如下**

*  要求高度事务性的系统，例如，银行或会计系统
 *  传统的商业智能应用，针对特定问题的BI 数据库会产生高度优化的查询方式。对于此类应用，数据仓库可能是更合适的选择。
 *  复杂的跨文档（表）级联查询。

传统的关系数据库的存储方式是以表的形式存放，而在MongoDB中，以文档的形式存在。数据结构由键值对组成。MongoDB 文档类似于 JSON 对象。字段值可以包含其他文档，数组及文档数组。下面这张图片就是一个典型的JSON文档。

下面的图片描述了关系数据库和MongoDB之间概念的对应关系以及存储形式，可以帮助我们理解MongoDB。关系数据库中的表对应MongoDB中的集合，关系数据库中的行对应MongoDB中的文档。

文档数据库和刚才介绍的第一种键值数据库类似，可以看做是键值数据库的升级版，而且它比键值数据库具有更高的查询效率，与键值数据库不同，文档数据库既可以根据Key来构建索引，也可以基于文档内容来构建索引。

MongoDB可以用来存储、索引并管理面向文档的数据或者类似的半结构化数据。

## 图数据库 ##

图数据库是最复杂的非关系数据库类型，它们可以处理大量数据。图数据库专注于数据元素之间的连接和关系，并使用图论来存储、搜索和管理这些关系。图数据库使用 nodes 来存储数据，用 nodes 表示单个实体或数据。一个节点连接到另一个节点。为了表示实体之间的连接或关系，图数据库还用到了 edges。

图数据库中的“图”是数学中的概念（数据结构中也有类似的概念），用来表示一个对象的集合，包括顶点以及连接顶点的边。图数据库专门使用图作为存储模型来存储数据，完全不同于键值、列族数据库和文档数据库的数据模型，可以高效存储不同顶点之间的关系，比较适用于社交网络、模式识别、以及路径寻找等问题。

图数据库允许我们将数据以图的方式储存。实体会被作为顶点，而实体之间的关系则会被作为边。比如我们有三个实体，Steve Jobs、Apple和Next，则会有两个“Founded by”的边将Apple和Next连接到Steve Jobs。

*  产品：Neo4J、Infinite Graph、OrientDB
 *  有谁在使用：Adobe （Neo4J）、Cisco （Neo4J）、T-Mobile （Neo4J）

**适用的场景**

*  1. 在一些关系性强的数据中
 *  2. 推荐引擎。如果我们将数据以图的形式表现，那么将会非常有益于推荐的制定不适用场景不适合的数据模型。图数据库的适用范围很小，因为很少有操作涉及到整个图。
 *  3. 社交网络、推荐引擎、交通运输系统、物流管理、主数据管理（避免僵化）、访问管理、欺诈检测。

图数据库对于许多公司，尤其金融、互联网等领域的公司来说，是刚需。正如Neo4j在新闻稿中所提到的，他们的服务已经被75%的Fortune 100公司所使用。然而，图数据库也有着自己的局限性。第一，图数据库的数据量规模往往较小。以社交网络举例，图数据库的常用建模方式是存储一个用户到其所关联用户的映射关系， 一个用户对应数据库内部一条记录。可以想象，在该数据库中存储的记录条数最多不会超过网站的注册用户数。对于亿级别的数据量来说，单机往往就已经足够。这就一定程度上限制了图数据库通过分布式批量卖机器来赚钱。第二，图数据库本身就不适合分布式。与传统OLTP或OLAP数据库轻松通过分库分表做扩展的方式不同，图数据库做分布式的两种方式，按边切割与按点切割，都是hard级难度，从理论上就难以优化。这并非危言耸听，毕竟只要认真研究过图计算领域的同学都会发现绝大多数关于分布式图计算的论文都在讨论切割问题。并且，图数据有着非常强的偏度（skewness），也就是说，个别节点会拥有大量的边。以社交网络举例，大V们的粉丝涵盖了整个社交网络绝大多数用户。这一特性使得图数据库做分布式难上加难。因此，哪怕数据规模达到分布式需求的时候，从性能角度出发，用户可能还是更加倾向于租用更好的单机，而非选择分布式。第三，图数据库相比于OLTP与OLAP数据库，更加难以成为信源（source-of-truth）。也就是说，用户更倾向于将数据持久化在其他系统中，当需要使用图数据库的时候再将数据进行导入导出。这种做法会导致系统的用户黏性没有那么强，替换成本较低。

## 全文检索数据库 ##

传统的关系数据库通过索引来达到快速查询的目的，但是在全文搜索的业务场景下，索引也无能为力，主要体现在：全文搜索的条件可以随意排列组合，如果通过索引来满足，则索引的数量会非常多。

全文搜索的模糊匹配方式，索引无法满足，只能用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来调试日志用例。

**主要特点**

*  拓展性好：支持一主多从且方便扩容，可扩展至上百台服务器；
 *  高可用：集群对节点支持分片和复制，多分片中只要有一个节点存活就可以继续提供服务。
 *  采用Restful API标准：通过http接口使用JSON格式进行操作数据。
 *  适用方便：数据存储的最小单位是文档，本质上是一个JSON 文本：
 *  单个服务最大达到 10w+ QPS，平响 20ms~，P95 延时小于 100ms。

**适用场景**

*  日志实时分析，如MySQL日志、套件ELK
 *  搜索服务，数据分析，数据监控
 *  智能分词 + 模糊匹配查询
 *  用户浏览行为日志追踪，推荐期望商品或内容
 *  搜索引擎，搜索推荐
 *  电商网站，商品检索，商品价格监控抢购
 *  站内搜索（电商、招聘、门户、OA）
 *  近乎实时的存储、检索数据

## 时序数据库 ##

时序数据是随时间不断产生的一系列数据，简单来说，就是带时间戳的数据。在有时间的坐标中将这些数据点连成线，往过去看可以做成多纬度报表，揭示其趋势性、规律性、异常性;往未来看可以做大数据分析，机器学习，实现预测和预警。

时序数据的主要数据属性如下：

*  每个数据点都包含用于索引、聚合和采样的时间戳。该数据也可以是多维的和相关的；
 *  写多读少，需要支持秒级和毫秒级甚至纳秒级高频写入；查询通常是多维聚合查询，对查询的延迟要求比较高
 *  数据的汇总视图（例如，下采样或聚合视图、趋势线）可能比单个数据点提供更多的洞察力。例如，考虑到网络不可靠性或传感器读数异常，我们可能会在一段时间内的某个平均值超过阈值时设置警报，而不是在单个数据点上这样做；
 *  分析数据通常需要在一段时间内访问它（例如，给我过去一周的点击率数据）；

时序数据库是专门处理时序数据的数据库，因此其相关概念是和时序数据紧密联系的，下面是时序数据库的一些基本概念。

*  **度量 Metric**：Metric 类似关系型数据库里的表（Table），代表一系列同类时序数据的集合，例如为空气质量传感器建立一个 Table，存储所有传感器的监测数据。
 *  **标签 Tag**：Tag 描述数据源的特征，通常不随时间变化，例如传感器设备，包含设备 DeviceId、设备所在的 Region 等 Tag 信息，数据库内部会自动为 Tag 建立索引，支持根据 Tag 来进行多维检索查询；Tag 由 Tag Key、Tag Value 组成，两者均为 String 类型。
 *  **时间戳 Timestamp**：Timestamp代表数据产生的时间点，可以写入时指定，也可由系统自动生成；
 *  **量测值 Field**：Field描述数据源的量测指标，通常随着时间不断变化，例如传感器设备包含温度、湿度等Field；
 *  **数据点Data Point**: 数据源在某个时间产生的某个量测指标值（Field Value）称为一个数据点，数据库查询、写入时按数据点数来作为统计指标；
 *  **时间线 Time Series** ：数据源的某一个指标随时间变化，形成时间线，Metric + Tags + Field 组合确定一条时间线；针对时序数据的计算包括降采样、聚合（sum、count、max、min等）、插值等都基于时间线维度进行；

**时序数据库产品：**Graphite、InfluxDB、OpenTSDB

时序数据库的应用场景在物联网和互联网APM等场景应用比较多，下面是列举了一些时序数据库的应用场景，但不是全部：

*  **公共安全**：上网记录、通话记录、个体追踪、区间筛选；
 *  **电力行业**：智能电表、电网、发电设备的集中监测；
 *  **互联网**：服务器/应用监测、用户访问日志、广告点击日志；
 *  **物联网**：电梯、锅炉、机械、水表等各种联网设备；
 *  **交通行业**：实时路况、路口流量监测、卡口数据；
 *  **金融行业**：交易记录、存取记录、ATM、POS机监测；

时序数据库是一个非常细化的市场，场景很有针对性，其所针对的领域包括了系统监控、物联网、金融等。做这种特化的数据库优势是容易批量找到合适的用户，但缺陷是实际的市场空间较小。跟通用型数据库，尤其是OLAP数据库相比，时序数据库最大的差异点在于对于时间维度建立了独特的索引与优化，而其他所谓schemaless等特性在OLAP数据库上都能做到，不存在技术障碍。这也就是为什么其实在公司做时序场景的数据库选型的时候会直接将时序数据库与一些OLAP数据库（比如ClickHouse）做比较。如果要把时序数据库往更宽的场景发展，那就是想好如何与那么多的通用型数据库做竞争了。当然，时序数据库可以朝特定场景发展。但是，在这些特定场景下，也存在着诸多竞争对手。比如如果做金融场景，就基本绕不开跟老牌金融数据库kdb+做竞争。如果做IoT 场景，就会需要考虑到跟EMQ X这样的专业IoT玩家做竞争。如果做系统监控，那么就需要挑战Chronosphere这样的独角兽公司。总之，时序数据库是个细化市场，如何掌握好产品的宽度与深度将是个创业公司们面临的问题。

## 何时使用NOSQL OR SQL ##

随着企业更快地积累更大的数据集，结构化数据和关系模式并不总是适合。有必要使用非结构化数据和大型对象来更好地捕获这些信息。

传统的 RDBMS 使用 SQL（结构化查询语言）语法来存储和检索结构化数据，相反，NoSQL 数据库包含广泛的功能，可以存储和检索结构化、半结构化、非结构化和多态数据。

有时，NoSQL 也被称为“不仅仅是 SQL”，强调它可能支持类似 SQL 的语言或与 SQL 数据库并列。SQL 和 NoSQL DBMS 之间的一个区别是 JOIN 功能。SQL 数据库使用 JOIN 子句来组合来自两个或多个表的行，因为 NoSQL 数据库本质上不是表格的，所以这个功能并不总是可行或相关的。

但是，一些 NoSQL DBMS 可以执行类似于 JOIN的操作——就像 MongoDB 一样。这并不意味着不再需要 SQL DBMS，相反，NoSQL 和 SQL 数据库倾向于以不同的方式解决类似的问题。

## 何时使用 SQL 数据库 ##

*  需要分布在多个表中的高度结构化的数据，需要数据遵守严格的、可预测的、预定义的和已经计划好的模式。
 *  数据将保持相对不变。如果不打算频繁更改数据库的结构并且不需要定期更新项目，SQL 数据库会很方便。请记住，它们提供的灵活性很小。
 *  需要一致的数据。
 *  数据完整性和安全性是重中之重。
 *  需要复杂查询的准确结果。

SQL 数据库的一个缺点是它们是垂直扩展的。当存储变多时，需要增加当前机器上的硬件和提高计算能力。这可能代价高昂。需要增加处理能力和内存存储来处理增加的负载以提高性能。

## 何时使用 NoSQL 数据库 ##

*  在一个快速的开发环境中工作，需要经常调整需求并不断更改数据库结构。
 *  正在处理大量性质不同但不需要大量结构或准确性的数据。
 *  正在处理需要频繁更新的数据。NoSQL 数据库提供了一个松散、灵活和动态的模式，允许对数据进行定期更改。
 *  需要快速的查询结果和系统的持续可用性。
 *  不想对数据库进行任何前期规划、准备或设计，而是想立即开始构建。

NoSQL 数据库的一大优势是它们可以水平扩展。

它们的设计方式可以将更多机器添加到现有机器（例如云服务器）中。与需要额外 CPU（中央处理单元）或 RAM（随机存取存储器）资源的垂直缩放相比，这种行为更可取。

但当然，NoSQL 数据库的一个缺点是它们不能确保数据的完整性和一致性。

## 如何选用NOSQL ##

1.  对读写要求极高、数据量小、数据无需长期存储，选择 Redis
2.  对数据的读性能要求很高，数据表的结构需要经常变化，有时还需要做一些聚合查询，选择 MongoDB
3.  如果你需要构造一个搜索引擎或者搞一个可视化的数据平台，选择 ElasticSearch
4.  如果需要存储海量数据，且未来数据会快速增长，选择 HBase

## NOSQL未来发展趋势 ##

根据 Gartner 的统计，2025 年全球会有 175ZB 的数据需求，其中大部分是非结构化/半结构化数据，并且会大量沉淀在 TOS/S3 等存储产品中，这些数据的存储和计算都蕴含大量的机遇。当然机遇与挑战并存，谁能解决数据的处理（存储+计算）问题，谁就能立于不败之地。

NoSQL 不仅是 not only SQL 也不仅是没有 SQL 语言，我对 NoSQL 的定义是高性能弹性存储+可扩展性动态计算的数据库。

现在我们从数据 Schema 维度审视，NoSQL 代表了半结构化和非结构化的数据处理。“处理”既包括计算，也包含存储。从 CAP 理论维度来看，NoSQL 强调的是“最大化” P，也就是弹性规模化能力，在 C 和 A 上不同的场景各有不同权衡。

预测未来NOSQL的发展趋势如下：

*  利用 Cloud Native、Serverless 能力，实现极致弹性和性价比、精细化的资源调度；
 *  强调数据增值能力和数据共享，对计算（包括分析和 AI）的需求越来越重；
 *  融合多样化的非结构/半结构数据 Schema，统一存储，统一计算；
 *  软硬件结合，带来数量级革命的技术升级；
 *  对于OLAP数据分析支持以及MapReduce支持