这里Order By无时不刻的处理，我们要看到刚才的足迹，不能使用缓存技巧。

• 根据时间戳来查询，显然很快，应为Hbase就是以时间戳来存的。
• 将最近的数据放在内存中，显然从内存中快速查找数据更快速，应用于此场景显然更快速。类似于内存数据库。
• 我们只需要往集群里增加节点，就能解决负荷上升的问题。

reverse key 反向设计ID，随机化，可以更分散的分布到各个节点。

通过hash函数映射出一个随机ID，把哈希值加到ID的后面，也起到随机化的效果。

下图就是这个思想进行查询操作。

世界上任何任何的一张二维表大概都可以写成三个列的形式，这个大表呢，就是bigtable，这三个列是什么呢？

第一列是行键，就是key值，对象的标识值，比如说学生对象中的学号就是他的key，通过学号就可以定位到具体的学生

第二列是属性，学生有哪些属性呢，姓名、专业等

第三列是value，就是他的值

这里呢一般的关系型数据库中，学生表呢会占一行就可以实现这样的数据库存储，而在bigtable中呢，我们有三行，第一行就是学号、姓名，张三，第二行就是学号、专业，计算机，第三行就是学号、年龄、20岁。

那这里我们不能像关系型数据库那样，有聚合操作，子查询，比如说我们在bigtable下做一个group by操作，基本上很难做，但是我们做key-value查询是很方便的，你输入键值还有属性，就是行键及属性就能返回他的值。连接查询也很方便，比如说，我们查询一个学生的数学课的成绩是多少？我们先查这个学生修啦什么课？得到一个课号，将此课号作为key，又在查下他这个key得到什么成绩，本来通过连接能做的现在转变成key-value来做。

我们可以看见这里的逻辑视图，我们现在想修改t3时间戳的列族对应的数据怎么办呢？

因为hdfs中文件系统中的文件的一部分是不能修改的，你可以把整个文件删掉，你就是不能修改，连追加append都比较困难，因此我们在Hbase中去修改一个行的内容就不现实，因此我们只能插入新的行和新的实践戳来反映这个修改，那删除也是这样的，我们不能删除整个文件的某个记录，我们只能插入一个新的行键代表一行，里面有个删除标记，来表示这个行键所代表行全部被删除掉啦。

这又有个问题啦，假如是插入的话，那修很老的时间戳，很占用内存空间，我们要把他们删除掉，超过保存锁定的预制，这里Hbase每隔一段时间会做一个重整的工作，会把小的数据文件合并成一个大的数据文件，Hbase会在整个生命周期里面都会做这个事情，这个抛弃是在重整里面做的，此时一些旧的行会把它扔掉，还有些时间戳太老的我们也可以在内存中把他扔掉，然后把剩下的合并在一块，然后再重新写入硬盘里面，形成一个新的一个更大的文件。

作为用户以上过程，说明Hbase中的行和记录是可以删除的和修改的，表面上操作的时候有这种感觉，其实背后不然。

• HMaster是Hbase的数据库的总控节点
• HRegionServer在一*立的计算机中就是物理节点，通常一个物理节点只会运行一个HRegionServer，他可以管理很多的HRegion（比如说一个表在行的方向上来分，这个表可能有10亿行，在分布式的思想里面呢，可以按照行的方向来分，分成10个区域，每个区域呢一共有1千万行，那每个区域我们称为一个Region）

• HRegion中有HLog（灾难恢复啦，断电什么的），Store与StoreFile，每一个列族一个Store，之所以Hbase被称为面向列的数据库，    就是这样，因为他的列族上的元素，是在物理上存放于一个地方，那不同的列族在物理上就是分离的，这样做是有好处的。Store可以分为MemStore和StoreFile，即内存Store和硬盘Store，新的修改进来一般进入内存Store，当内存里面搜集的数据足够多啦，此时一些小的StoreFile可能就会合并成为一个大的StoreFile，在此期间合并的同时就会有一些已经过期的超出预期的被抛弃掉，然后把内存里的东西写进入硬盘中，成为一个StoreFile。一般来说Hbase的存储都是稀疏的，95%的都是稀疏的，比如一个行，只有在某个列族上存在着值，而在其他列族上不存在值。可能一个行被分散在好几个Store中，我们去查询时就要去好几个Store中去查。每个StoreFile对应一个HFile，其实这个HFile就是Hdfs里的文件，这个文件才Hdfs里面有可能是分布式的，分散存放在物理节点里面。