前几天和公司的同事杨传辉(http://www.nosqlnotes.net/)做了简单的关于hbase的交流。这里做下简单的记录。Q为杨传辉，A为我。
| Q: .meta.和root表是否要分裂？ |
| A: meta表和root表不会分裂，代码中有所判断。 |
| Q: 如果不分裂，那么都只有1个region? |
| A: ... |
| (查看代码后)A: meta和root表是要split的，.meta.和-root-不split是在0.20.6以前的版本，升级到0.89以后都会split了，只是不分裂的代码接口还保留着，实际调用的并不是这段代码。-root-理论上也会split，而且一旦发生split就完蛋。但是因为root要split要满足超过1600亿的region，而region的数量被限制在Integer.max(4亿多)，所以这种情况是不会发生的 |
| Q: 二级索引如何实现？ |
| A: 目前没有好的实现。 |
| Q: 提供一个建议。google的做法是让应用层自己建索引表。写数据时先写数据再写索引，读数据是先读索引再读数据。这样最多是有些数据读不到，不会产生读出错误数据。 |
| A: 其实以前hbase的版本有过二级索引，实现时也是先写数据再写索引，索引放到后台队列中异步地写。实现最终一致。 |
| Q: 我讨厌最终一致这个词。它其实定义很含糊。 |
| A: 恩，hbase后来移走这块代码的一个原因就是索引到底落后数据多少时间是不确定的，特别是在异常的情况下。这样就导致在清理hlog时无法确定一个hlog是否真正全部写入数据了。 |
| Q: 所以像google那样交给应用层去做是很简单有效的一个做法。 |
| A: 应用层的压力会增大？ |
| Q: 要有相应的取舍。 |
| A: oceanbeans如何实现二级索引及事务？ |
| Q: ob的写是单机的，所以二级索引和事务都可以像传统数据库那样实现，完全基于内存的实现。 |
| Q: hbase中append如何实现？如何保证发生异常时不丢失数据？ |
| A: append是hbase写hlog时才做的。打开autoflush的情况下每次会把数据提交到服务器端。服务器端记录下hlog和写入memstore后返还给用户成功 |
| Q: 每次都把hlog写到磁盘？ |
| A: 每次都写。 |
| Q: 速度是多少？ |
| A: 响应时间单线程约为毫秒级，低于10ms。在做fsync时会超过10ms，fsync每秒1次或每64MB一次 |
| Q: 那不可能，一次写磁盘至少要10ms以上。 |
| A: ... |
| Q: 如果没有写透到磁盘，那在1s以内是会丢失数据？ |
| A: ... |
| A(查看代码):在hlog这一块是在append的时候追加数据用流式追加到hfile中，相当于顺序写一个日志文件。每条记录都会flush并且通过os的pagecache往文件里落地，如果单次写请求数据很少那效率确实会低不少。所以批量提交数据会有更大的优势(用put(List put)接口)。数据是不会丢失的。 |
| Q: append需要和master通信吗？ |
| A: 不需要，每次写都是直接联系datanode。 |
| Q: 那怎么知道当前append的offset？ |
| A: 写之前请求master当前的offset。写完再通知master更新blockmap。 |
| Q: 那能读到最新写入的数据吗？ |
| A: … |
| A(回来思考了一下): 不需要立即读到最新的数据，因为这是hlog，即时性没有那么高。在每次执行了fsync后就能读到。 |
| Q: 写是一个还是三个备份成功才返回？ |
| A(不确定): 两个。 |
| A(查看代码): 三个。它是一个pipe的模式，先自己写，然后交给next，next也会先写再交给下一个next，直到没有next为止。然后依次返回每一次的结果，如果有一个出错，就会抛出异常给client |
| Q: 那返回出错怎么处理？ |
| A: 出错后默认的client向namenode请求新的结点新建chunk文件进行重试。 |
| Q: cluster中各机器是如何相互知道对方存在的。 |
| A: namenode和datanode、hmaster和zookeeper、zookeeper之间、regionserver和zookeeper、hmaster和regionserver之间都存在hearbeat。 |
| Q: heartbeat机制是有问题的，比如因为gc或者网络抖动导致暂时心跳停止如何处理？ |
| A: gc时间一般很短，网络抖动也非经常的现象，稍调大心跳lease时间就可以了 |
| Q: 不能说一般，只要理论上可能出现的问题，实际应用中必然出现，特别是海量数据 |
| A: ...ob如何处理这种问题？ |
| Q: ob的slave都是静态数据，所以不存在这种问题 |
| A: 目前至少namenode和datanode、hmaster和regionserver、zookeeper之间这三组心跳发生以上问题都不太影响。zookeeper和regionserver以及hmaster之间的心跳确实都会造成相应的影响 |
| Q: 很难在测试环境中模拟出这种情况 |
| A: 怎么模拟？ |
| Q: 找QA帮忙，QA是知道如何模拟出网络不稳定的情况的。 |
| Q: 启动cluster的时候，hlog恢复时间长，是因为什么原因？ |
| A: hmaster单线程读hlog，然后单线程parse，多线程恢复数据。当hlog多的时候，时间就会很长 |
| Q: 此时所有的regionserver呢？ |
| A: regionserver在等待master做这个事。 |
| Q: 那region都处于offline状态？ |
| A: 是的 |
| Q: 那数据如何写入？ |
| A: ... |
| A(查看代码): 这里的关键是hlog中含有每一行数据的region信息。因此启动时只要读到这个region，hmaster就到对应的hdfs目录下创建一个新的文件。将相应的数据通过hdfs直接写入这个文件，这样在region扫描storefile时就能读到这个数据了。 |
| Q: 那顺序如何保证？ |
| A: hmaster在恢复hlog时，默认以128M为单位缓存读到的数据。缓存时采用了一个treemap，因此写入的数据也是有序的 |