浅谈hbase的兴起

hbase作为非关系型数据库的代表，为什么能在关系型数据库如日中天的时期悄然兴起呢？我浏览过能多的信息，其内容无非不是介绍hbase的特点。
包括：
1 列的可以动态增加，并且列为空就不存储数据,节省存储空间.

2 Hbase自动切分数据，使得数据存储自动具有水平scalability.

3 Hbase可以提供高并发读写操作的支持

4 不能支持条件查询，只支持按照Row key来查询.
等等。。
但很少有能将问题说清楚的，多余的就不说了，简单的聊两句。
互联网的后期，关系型数据库的瓶颈就是它的扩展性太差了，这里要补充一点数据库储存数据的知识了。
我们经常听到，关系型数据库常用数据储存结构是b+树，而非关系型数据库的数据储存结构是Lsm树。而实际上数据结构储存的是他们的索引，这点很重要，如果没有索引，不管什么类型的数据库，他们的数据储存只能建立在操作系统的基础上进行储存。
以Linux为例，操作系统读取硬盘的时候，不会一个个扇区地读取，这样效率太低，而是一次性连续读取多个扇区，即一次性读取一个"块"（block）。这种由多个扇区组成的"块"，是文件存取的最小单位。"块"的大小，最常见的是4KB，即连续八个 sector组成一个 block。

文件数据都储存在"块"中，那么很显然，我们还必须找到一个地方储存文件的元信息，比如文件的创建者、文件的创建日期、文件的大小、文件数据block的位置等等。这种储存文件元信息的区域就叫做inode，中文译名为"索引节点"。

我们在读取文件时，会先读取inode，在对应的找到硬盘上储存的该文件的原信息，根据文件数据block的位置在硬盘储存数据区域读取数据，如果硬盘是新的，数据块的储存位置是连续的，就可以顺序读取文件了。其中mysql的一个表是一个数据，而hbase的一个列族是一个文件。不管是hbase还是mysql都会尽量保持该数据的连续性，但实现不同。
mysql的实现是按数据类型固定数据的储存空间，便于数据的修改，而hbase的实现根本不允许修改文件（新版本中，hbase提供了一种文件类型可以提供就该功能，不影响文件结构），只能进行数据的累加，这里hbase引入了一个时间戳的概念，来保存我们想要储存修改的数据。随后在进行数据的合并，hbase会把多余时间戳删掉，重整文件结构，这很耗费时间，也就是hbase两次合并的第二种。
另外，作为牺牲hbase的索引库就只有rowkey了（也可以用倒排索引对文件建立索引）。
而关系型数据库则不然，它的内部远比hbase复杂，不仅可以对不同的字段建立索引，不同表之间的主键，外键的信息也会被存在元数据中，以便数据的查询和表之间的join，但恰恰是这点限制了关系型数据库的横向扩展，你的索引设计的完美的同时也意味着更复杂，当数据量过大时，在多个节点中同一个表就会有不同的索引文件，就算客户查询单表，不同节点之间索引查询的整合就非常复杂，当多表查询，节点更多时，关系型数据库的查询速度会大幅度降低。
可以说，hbase放弃了多索引的建立，而争得了横向扩展的优势。而Lsm树的数据结构就专为hbase而设计出来了，它的维护了两个树，小树储存着经常处理的热数据。它可以储存在计算机的内存中，大大加快了对热数据的查询速度，冀以希望对自带的缺点进行一些弥补。

文章的表达不是很清楚，逻辑也差点，但我已经尽力说明了，下面是一些参考文章：
理解inode
数据库原理笔记
Mysql数据库原理特性以及底层机制
Hbase与传统关系型数据库对比