HBase是一个分布式的、面向列的开源数据库，该技术来源于 Fay Chang 所撰写的Google论文“Bigtable：一个结构化数据的分布式存储系统”。

就像Bigtable利用了Google文件系统(File System)所提供的分布式数据存储一样，HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的Hadoop

项目的子项目。HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。

HBase是Hadoop项目的一部分,HBase列式数据库，BigTable的一种实现。高效存储大量数据，支持列压缩，行事务。适合Schema-less的数据，

适合稀疏表，一个表可以容纳上亿行、上百万列，用做超大数据量要求扩展简单的离线分析型应用。Hadoop的无缝集成，有数据可靠性和海量数据分析性能（MapReduce）的能力。

优点:HBase也继承了Hadoop项目的最大优点，那就是对海量数据的支持，以及极强的横向（存储容量）扩展能力。

缺点:HBase的列式存储特性带来了海量数据规模的支持和极强的扩展能力，但是也给数据的读取带来很大的局限。

由于只有同一列族的数据才会被存放在一起，而且所有的查询都必须要依赖Key，这就使得很多复杂查询难以进行。

应用场景:作为MapReduce（大规模数据集（大于1TB）的并行运算）的后台数据源；Facebook的消息类应用，包括Messages、Chats、Emails和SMS系统，用的都是HBase。

HBase是一个数据库，一个NoSql的数据库，像其他数据库一样提供随即读写功能，Hadoop不能满足实时需要，HBase正可以满足。如果你需要实时访问一些数据，就把它存入HBase。

hbase分页功能的几种实现方案

分页功能是线上系统的常用功能，对hbase，有以下几个方案可以选择(抛砖引玉)。

假设要查第N页，1页大小为M

1 client分页，scan查到N*M条，过滤掉N*（M--1）条，返回M条。对于M,N较小时比较适合。

2 自定义Filter，该filter可以传递offset(server端需要过滤的记录条数)，在server端分页，注意，跨不同的region时需要重新计算该offset。

例子：第1个HRegion的请求传递该值为N*M-1，表示需要在server端过滤掉N*M--1条记录。当第1个HRegion返回时，需要知道该次请求在server端实际过滤了多少条记录(假设为Size条),

第2个HRegion的请求传递该值为（N*（M-1）)-Size。

3 缓存上次分页查询的最后一条，下次分页查询从这条（不包含)开始查。

4 查询条件固定的话，定时任务汇总表。

5 结合其他框架想办法。

少量数据的推荐使用的，使用了方案1。

Apache HBase是一个分布式的基于于读性能优化的列式存储，读性能的优化来自于每个列簇对应一个文件。HBase最初思想来源于Google文件系统。以列为单位进行数据聚合， 可以减少IO，  因为列上的数据结构天生相似，逻辑上来说每行之间只有轻微的不同，所以更有利于提高压缩比从而降低返回结果时的带宽消耗,

在网站用户量增加一定程度的时候，减少压力的第一步是增加用于并行读取的从服务器，也就是读写分离，主服务器只服务于写请求，因为网站请求主要由用户浏览构成，写请求实际是很少的， 在这个方案抗一段时间后下一步就是增加缓存，将读操作接入到高速内存缓存当中，但是有了缓存以后就会产生数据的不一致性， 也就是数据库数据与缓存数据的不一致性， 这个不一致性的时间差需要做到尽量最小化。 再继续随着网站的功能扩容，这些功能都会转化为后台数据库的查询语句，以前顺利执行的SQL Join也会突然变慢，或者无法执行，这个时候就需要采用逆范式化存储结构，也就是为了节省时间多设计一些冗余字段，以空间换取时间的策略。（存储过程是可以解决多个客户端同时更新数据的一致性问题，也就是需要始终保证多张表的数据一致性时的解决方案），存储过程也会慢慢无效，此时索引的性能提升也会慢慢下降。这个时候可以考虑数据分区，但是代价昂贵，运维成本高

HBase中扩展和负载均衡的基本单元称为region,本质上region是以行键排序的连续存储区间，region太大的时候就会把他们动态拆分，反之就会合并，一台region server可以同时加载多个region.

HFile中存储的是经过排序的键值映射结构,每个HFile有一个块索引，在内存中的块索引中进行二分查找，确定可能包含键的块,然后读取磁盘块找到实际要找的键.

每次更新数据时，都会先将数据记录在提交日志中(WAL write-ahead log),然后再将这些数据写入内存的memstore中，一旦内存保存的写入数据的大小超过了一个给定的最大值，就会将这些数据移出内存作为HFile刷到磁盘中，数据移出内存后系统就会丢弃对应的提交日志，只保留未持久化到磁盘的提交日志。

随着memstore中的数据不断刷到磁盘中，会产生越来越多的HFile文件，HBase内部有一个解决问题的管家机制。将文件进行合并 1: minor合并:将多个小文件重写为数量较少的大文件，减少文件存储数量（实际是个多路归并的过程）. 2:major合并:将一个region中的若干个HFile重写为一个新的HFile, major是清理墓碑记录的唯一机会

HBase 读:

如果想快速访问数据，通用的原则是数据保持有序并尽可能保存在内存里。HBase实现了这两个目标，大多数情况下读操作可以做到毫秒级。HBase读动作必须重新衔接持久化到硬盘上的HFile和内存中MemStore里的数据。HBase在读操作上使用了LRU(最近最少使用算法)缓存技术。这种缓存也叫做BlockCache，和MemStore在一个JVM堆里。BlockCache设计用来保存从HFile里读入内存的频繁访问的数据，避免硬盘读。每个列族都有自己的BlockCache。 
掌握BlockCache是优化HBase性能的一个重要组成部分。BlockCache中的Block是HBase从硬盘完成一次读取的数据单位。HFile物理存放形式是一个Block的序列外加这些Block的索引。这意味着，从HBase里读取一个Block需要先在索引上查找一次该Block，然后从硬盘读出。Block是建立索引的最小数据单位，也是从硬盘读取的最小数据单位。Block大小按照列族设定，默认值是64KB。根据使用场景你可能会调大或者调小该值。Block变小会导致索引变大，进而消耗更多内存；Block变大意味着索引项变少，索引变小，因此节省内存。 
从HBase中读出一行，首先会检查MemStore等待修改的队列，然后检查BlockCache看包含该行的Block是否最近被访问过，最后访问硬盘上的对应HFile。

HBase是一个数据库，一个NoSql的数据库，像其他数据库一样提供随即读写功能，Hadoop不能满足实时需要，HBase正可以满足。如果你需要实时访问一些数据，就把它存入HBase。

hbase分页功能的几种实现方案。

分页功能是线上系统的常用功能，对hbase，有以下几个方案可以选择

假设要查第N页，1页大小为M

1 client分页，scan查到N*M条，过滤掉N*（M--1）条，返回M条。对于M,N较小时比较适合。

2 自定义Filter，该filter可以传递offset(server端需要过滤的记录条数)，在server端分页，注意，跨不同的region时需要重新计算该offset。

例子：第1个HRegion的请求传递该值为N*M-1，表示需要在server端过滤掉N*M--1条记录。当第1个HRegion返回时，需要知道该次请求在server端实际过滤了多少条记录(假设为Size条),

第2个HRegion的请求传递该值为（N*（M-1）)-Size。

3 缓存上次分页查询的最后一条，下次分页查询从这条（不包含)开始查。

4 查询条件固定的话，定时任务汇总表。

5 结合其他框架想办法。

• 它是用来当有需要写重的应用程序。

• HBase使用于当我们需要提供快速随机访问的数据。

• 很多公司，如Facebook，Twitter，雅虎，和Adobe内部都在使用HBase。