共计 5623 个字符，预计需要花费 15 分钟才能阅读完成。
对于写密集型利用，每天写入量微小，数据增长量无奈预估，且对性能和可靠性要求十分高，一般关系型数据库无奈满足其需要。对于全文搜寻和数据分析这类对查问性能要求极高的场景也是如此。为了进一步满足下面两类场景的需要，有了宽表存储和搜索引擎技术，本文将对他们的架构、原理、优缺点做介绍。
— 宽表存储 —
宽表存储最早来自 Google 的 Bigtable 论文，最后的定义为：A Bigtable is a sparse, distributed, persistent multidimensional sorted map. The map is indexed by a row key, column key, and a timestamp; each value in the map is an uninterpreted array of bytes.
《Bigtable: A distributed storage system for structured data》
Bigtable 会把数据存储在若干个 Table（表）中，Table 中的每个 Cell（数据单元）的模式如下：Cell 内的数据由字节串（string）形成，应用行、列和工夫戳三个维度进行定位。
图片来源于《Bigtable: A distributed storage system for structured data》
Bigtable 在存储数据时会依照 Cell 的 Row Key 对 Table 进行字典排序，并且将一个 Table 按 Row 切分成若干个相邻的 Tablet，并将 Tablet 调配到不同的 Tablet Server 上存储。如此一来，客户端查问较为靠近的 Row Key 时 Cell 落在同一个 Tablet 上的概率也会更大，查问的效率也会更高。
Table 中的不同 Cell 能够保留同一份数据的多个版本，以工夫戳进行辨别。工夫戳实质上为 64 位整数，可由 Bigtable 主动设定为数据写入的以后工夫（微秒），也可由利用自行设定，但利用须要自行确保 Cell 间不会呈现抵触。对于领有雷同 Row Key 和 Column Key 的 Cell，Bigtable 会依照工夫戳降序进行排序，如此一来最新的数据便会被首先读取。
因为 Google Bigtable 解决了海量数据场景下并发检索与查问、高速日志写入等外围业务场景需要，工业界受其启发开发了一些我的项目，如 HBase、Cassandra 等，并统称其为 Wide Column Store（宽表存储，又称表格存储）。宽表存储能够无 schema 限度，表的字段能够自在扩大。一个数据表能够有无穷多的 column，并且每行能够有不同的 column，也容许每行有很多的空值，相似一个稠密矩阵。一个列族（column family）存储常常被一起查问的相干数据。
以后 DB-Engine 中宽表 NoSQL 数据库的排名如下表，能够看到最受欢迎的次要是 Cassandra、HBase 和 Azure 上的 Cosmos DB。接下来咱们将介绍一下 HBase 的状况。
HBase 是一个面向列的分布式 NoSQL 数据库，是 Google Bigtable 框架的开源实现，可能响应随机、实时的数据检索需要。HBase 次要的存储和解决对象是大宽表，存储模式能够兼容本地存储、HDFS 和 Amazon S3 等 Hadoop 反对的文件系统，相比于 RDBMS 有很强的线性扩大能力。HBase 通过采纳基于 LSM 树的存储系统以保障稳固的数据写速率，同时利用其日志管理机制以及 HDFS 多正本机制确保数据库容错能力。通常的实用场景为：面向多版本、稠密的、半结构化和结构化的数据高并发写入 / 查问的 OLTP 业务。
HBase 的数据模型由不同的逻辑概念形成，包含：表、行、行键、列、列族、单元、工夫戳。
- 表（Table）：Table 是 HBase 中数据的组织模式，是列的汇合，和传统数据库中表的意义相似，同时也可能涵盖列数据在不同工夫戳下的更新记录。
- 列（Column）：是数据库中独自的数据项，每一个 Column 蕴含数据的一种类型。
- 列族（ColumnFamily）：HBase 中表的数据都是依照 ColumnFamily 分组，ColumnFamily 是一个或多个 HBase 表中相近类型列的聚合。HBase 将同一个 ColumnFamily 的数据放在一个文件中存储，能够起到相似于垂直分区的作用。查问时能缩小不必要的扫描，减少查问速度。
- 行（Row）：Row 是 RowKey 和 ColumnFamily 的汇合，一个 Row 中能够包含一个或多个 ColumnFamily。
- 行键（RowKey）：HBase 中的行数据以 RowKey 模式进行排序，具备主键的作用，在查问时 HBase 能够通过 RowKey 定位数据，Region 也是通过 RowKey 划分的。
- 工夫戳（Timestamp）：Timestamp 是给定值的版本标识，和值同时写入 HBase 数据库。Timestamp 能够是任何类型的工夫格局，对于每个 RowKey 来说能够有多个工夫版本的记录更新。
片来源于《HBase: The Definitive Guide》
在 HBase 中，表依照 RowKey 被切分为多个 Regions 存储。每个 Region 是 HBase 数据管理的根本单位，Region 通过 RowKey 切分，具备相似程度范畴分区的作用，数据得以散布于集群的各个节点，不同节点上的 Region 独特组合成表的整体逻辑视图，通过扩大 Region 能够晋升容量。
片来源于《HBase: The Definitive Guide》Regions 由 HRegionServer 保护，HRegionServer 受到 HMaster 对立治理。HMaster 能够主动调整 HRegionServer 中的 Region 数量，这样就实现了存储数据的有限扩大。
图片来源于《HBase: The Definitive Guide》
HBase 的技术架构如上图，次要的组件或服务包含：Client：
- Client 是整个 HBase 集群的拜访入口，负责与 HMaster 通信，以进行集群治理类操作，或者与 HRegionServer 通信进行数据读写类操作。
- ZooKeeper：集群中每个节点的状态信息都会注册在 ZooKeeper，HMaster 通 ZooKeeper 感知每个 HRegionServer 的衰弱状态。另外 HBase 容许启动多个 HMaster，ZooKeeper 可保障集群中只有一个 HMaser 在运行。
- HMaster：负责管理对数据表的 CRUD 操作，治理 HRegionServer 的负载平衡，负责新 Region 的调配；在 HRegionServer 故障停机时负责生效 HRegionServer 上的 Region 迁徙。
- HRegionServer：一个节点对应一个 HRegionServer。负责接管 HMaster 调配的 Region, 负责与 Client 通信并解决其治理的所有 Region 相干读 / 写申请。
- HStore：HStore 在 HBase 中负责数据存储性能，有 1 个 MemStore 和 0 个或更多的 StoreFiles。数据先写入内存 MemStore，刷写成 StoreFile(File 的封装），最初长久化到 HDFS，当查问某一列的时候只须要调出 HFDS 相应的 block 即可。
- HLog：日志治理与回回放，每个进入 MemStore 的操作都会记录在 HLog。
HBase 采纳 LSM 作为底层存储构造。LSM 绝对于 RDBMS 常采纳的 B + 树有更好的写速率。因为磁盘随机 IO 的速率比程序 IO 的速率慢指数级，所以数据库的存储设计都尽量避免磁盘随机 IO。尽管 B + 树会将同一个节点尽量存储在一个分页上，然而这样只在绝对较小数据量的状况无效，大量随机写时节点会趋于决裂，磁盘随机读写概率晋升。为了保障写速率，LSM 先写在内存，而后再程序批量落入磁盘。程序写设计使 LSM 绝对于 B + 树有更好的海量数据写性能，然而读取的时候须要写合并内存数据和磁盘的历史数据，因而读性能有肯定就义。但同时，LSM 也能够通过将小汇合并成大汇合（合并），以及 Bloom Filter 等形式进步肯定的读速。
图片来源于《HBase: The Definitive Guide》
HBase 与存储相干的构造包含 MemStore、HFile、WAL。MemStore 是一个可能将数据的随机写转化为程序写的内存存储构造，数据在写入时会先写入 MemStore，直到内存存储容量无奈持续存储数据时，再将数据存储转移在磁盘上。HFile 便是 HBase 数据最终写到磁盘上的文件数据结构，即 StoreFile 的底层保留格局。在 HBase 中一个 StoreFile 对应着一个 HFile，通常状况下 HFile 存储在 HDFS 之上的，因而可能保障数据完整性并提供分布式存储。WAL（Write-Ahead Log）负责提供高并发、长久化的日志存储和回放服务。HBase 产生的所有业务操作都会存储在 WAL 中，以提供劫难复原。例如 MemStore 内存数据写入 HFlie 长久化时如果机器断电，能够通过 WAL 回放，而数据不会失落。
— 全文搜索引擎 —
关系数据库以行记录的形式存储有固定格局数据，与之不同的是，搜索引擎会将数据以文档的模式存储，在物理上会是层次化构造或者树形构造。这个做法的益处是非常容易减少半结构化或者结构化数据的解决能力。
目前搜索引擎比拟有代表性的数据库有开源 Elasticsearch，国内星环科技有自研的搜寻产品 Scope。在 DB Engine 的排名中，Elasticsearch 长年排名在前十以内，相较于 SQL 数据库，ES 提供了可扩大、近实时性的分布式搜寻性能，反对将文本数据宰割为多个局部交由集群节点进行存储和备份以进步检索速度并保证数据的完整性，反对自动化的负载平衡和应急解决以确保整个集群处于高可用状态。ES 实用于各种对文档等非结构化数据有解决需要的业务，如智能分词、全文检索、相关度排名等。
ES 定义了一套专有的存储和治理数据的因素和概念，最次要的为 Field、Document、Type 和 Index。Field 是 Elasticsearch 中最小的数据单位, 与关系型数据库中的列类似，是一组具备雷同数据类型的数据值的汇合。Document 相似于关系型数据中行的概念，一个 Document 蕴含每一个 Field 中与之相应的数据值。Type 相似数据库中的表级别概念，而 Index 是 Elasticsearch 中最大的数据单位，与 SQL 的索引不同，ES 中 index 对应 SQL 中 schema 的概念。
在物理模型上，Elasticsearch 次要的概念包含 Cluster（集群）、Node（节点）和 Shard（分片）。其中节点指的是一个 Elasticsearch 的实例或者说 Java 过程，如果硬件资源比拟短缺，是能够在一个节点上运行多个实例的。Shard 是 ES 集群进行数据处理的最小单元，是 Lucene 索引的一个实例，每个 Index 由一个或多个节点上的 Shard 独特组成。Shard 分为 Primary Shard 和 Replica Shard，每一个 Document 都会存储在一个 Primary Shard 中，如果 Primary Shard 或所在节点产生故障时，Replica Shard 能够转为主 Shard 以保证数据的高可用；而在检索数据时，查问命令能够在备份 Shard 中进行以加重主 Shard 的压力，进而进步了查问性能。
当向 Elasticsearch 写入数据时，Elasticsearch 依据文档标识符 ID 将文档调配到多个分片上，当查问数据时，Elasticsearch 会查问所有的分片并汇总后果。为了防止查问时局部分片查问失败影响后果的准确性，Elasticsearch 引入了路由性能。当数据写入时，通过路由将数据写入指定分片。当查问数据时，通过雷同的路由指明在哪个分片将数据查出来。
凭借着底层 Lucene 倒排索引技术，Elasticsearch 在查问和搜寻文本、日志类数据方面体现十分突出，简直超过所有关系型数据库和其余基于 Lucene 革新的产品 (如 Solr)，因而被广泛应用在日志剖析、情报分析、常识检索等畛域中，尤其是基于 Elastic Stack 构建的多个行业解决方案。然而 2020 年 Elastic 扭转了其 license 模式，限度云厂商间接托管销售 Elasticsearch，业内尝试通过一些其余形式（如基于 Elasticsearch 5.7 版本开发的 OpenSearch）来绕过相干的 license 限度。
不过 ES 也有几个非常明显的架构不足之处，限度了其进一步拓展利用场景，包含：
- 不反对事务性能仅能反对数据的最终一致性，因而不能用于要害数据的存储和应用
- 剖析能力偏弱如简单的聚合能力偏弱
- 各个分片之间的高可用采纳主从复制，可能存在数据脑裂问题
- 单个 Node 的解决数据容量还有待晋升
- ES 的平安模块是商业化插件，大量的 ES 集群短少适合的平安防护
正是有以上的架构不足之处，也给业内其余搜索引擎一些改良的方向，尤其是 ES 的安全性问题，目前在国内曾经导致数起重大的数据安全泄露事件。星环科技在 2017 年开始研发 ES 的国产替代品，并于 2019 年公布了基于 Lucene 开发的分布式搜索引擎 Scope，采纳了全新基于 Paxos 协定的高可用架构、反对跨数据中心的部署模式、内置原生平安性能、反对单个服务器多个 Node 实例等形式，极大地晋升了搜索引擎的稳定性、可靠性和性能，在国内曾经落地多个大型生产集群，单个集群服务器数量超过 500 节点。
— 小结—
本文介绍了宽表存储和搜索引擎技术的架构、原理、优缺点（当初各项技术倒退比拟快，可能存在技术形容跟最新技术倒退状况不太统一的状况）。那么有了根底的数据存储管理，下一步是通过整合计算，取得所需后果，面对大数据量，如何实现高吞吐、低提早、高扩大、反对容错，是分布式计算技术的要害，下一篇起，咱们将介绍以 MapReduce 和 Spark 为代表的分布式计算技术。
