对于写密集型利用，每天写入量微小，数据增长量无奈预估，且对性能和可靠性要求十分高，一般关系型数据库无奈满足其需要。对于全文搜寻和数据分析这类对查问性能要求极高的场景也是如此。为了进一步满足下面两类场景的需要，有了宽表存储和搜索引擎技术，本文将对他们的架构、原理、优缺点做介绍。

— 宽表存储 —

宽表存储最早来自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为代表的分布式计算技术。