谁能说说mangodb 和 hbase的区别

1Mongodb bson文档型数据库，整个数据都存在磁盘中，hbase是列式数据库，集群部署时每个familycolumn保存在单独的hdfs文件中。

2Mongodb 主键是“_id”,主键上面可以不建索引,记录插入的顺序和存放的顺序一样，hbase的主键就是row key，可以是任意字符串(最大长度是 64KB，实际应用中长度一般为 10-100bytes)，在hbase内部，row key保存为字节数组。存储时，数据按照Row key的字典序(byte order)排序存储。设计key时，要充分排序存储这个特性，将经常一起读取的行存储放到一起。

字典序对int排序的结果是1,10,100,11,12,13,14,15,16,17,18,19,2,20,21,…,9,91,92,93,94,95,96,97,98,99。要保持整形的自然序，行键必须用0作左填充。

3Mongodb支持二级索引，而hbase本身不支持二级索引

4Mongodb支持集合查找，正则查找，范围查找，支持skip和limit等等，是最像mysql的nosql数据库，而hbase只支持三种查找：通过单个row key访问，通过row key的range，全表扫描

5mongodb的update是update-in-place，也就是原地更新，除非原地容纳不下更新后的数据记录。而hbase的修改和添加都是同一个命令：put，如果put传入的row key已经存在就更新原记录,实际上hbase内部也不是更新，它只是将这一份数据已不同的版本保存下来而已，hbase默认的保存版本的历史数量是3。

6mongodb的delete会将该行的数据标示为已删除，因为mongodb在删除记录时并不是真把记录从内存或文件中remove，而是将该删除记录数据置空（写0或特殊数字加以标识）同时将该记录所在地址放到一个list列表“释放列表”中，这样做的好就是就是如果有用户要执行插入记录 *** 作时，mongodb会首先从该“释放列表”中获取size合适的“已删除记录”地址返回，这种方法会提升性能（避免了malloc内存 *** 作），同时mongodb也使用了bucket size数组来定义多个大小size不同的列表，用于将要删除的记录根据其size大小放到合适的“释放列表”中。Hbase的delete是先新建一个tombstonemarkers，然后读的时候会和tombstonemarkers做merge，在 发生major compaction时delete的数据记录才会真真删除。

7mongodb和hbase都支持mapreduce，不过mongodb的mapreduce支持不够强大，如果没有使用mongodb分片，mapreduce实际上不是并行执行的

8mongodb支持shard分片，hbase根据row key自动负载均衡，这里shard key和row key的选取尽量用非递增的字段，尽量用分布均衡的字段，因为分片都是根据范围来选择对应的存取server的，如果用递增字段很容易热点server的产生，由于是根据key的范围来自动分片的，如果key分布不均衡就会导致有些key根本就没法切分，从而产生负载不均衡。

9mongodb的读效率比写高，hbase默认适合写多读少的情况，可以通过hfileblockcachesize配置，该配置storefile的读缓存占用Heap的大小百分比，02表示20%。该值直接影响数据读的性能。如果写比读少很多，开到04-05也没问题。如果读写较均衡，03左右。如果写比读多，果断默认02吧。设置这个值的时候，你同时要参考hbaseregionserverglobalmemstoreupperLimit，该值是memstore占heap的最大百分比，两个参数一个影响读，一个影响写。如果两值加起来超过80-90%，会有OOM的风险，谨慎设置。

10hbase采用的LSM思想(Log-Structured Merge-Tree)，就是将对数据的更改hold在内存中，达到指定的threadhold后将该批更改merge后批量写入到磁盘，这样将单个写变成了批量写，大大提高了写入速度，不过这样的话读的时候就费劲了，需要merge disk上的数据和memory中的修改数据，这显然降低了读的性能。mongodb采用的是mapfile+Journal思想，如果记录不在内存，先加载到内存，然后在内存中更改后记录日志，然后隔一段时间批量的写入data文件，这样对内存的要求较高，至少需要容纳下热点数据和索引。

上图是RegionServer数据存储关系图。上文提到，HBase使用MemStore和StoreFile存储对表的更新。数据在更新时首先写入HLog和MemStore。MemStore中的数据是排序的，当MemStore累计到一定阈值时，就会创建一个新的MemStore，并且将老的MemStore添加到Flush队列，由单独的线程Flush到磁盘上，成为一个StoreFile。与此同时，系统会在Zookeeper中记录一个CheckPoint，表示这个时刻之前的数据变更已经持久化了。当系统出现意外时，可能导致MemStore中的数据丢失，此时使用HLog来恢复CheckPoint之后的数据。

StoreFile是只读的，一旦创建后就不可以再修改。因此Hbase的更新其实是不断追加的 *** 作。当一个Store中的StoreFile达到一定阈值后，就会进行一次合并 *** 作,将对同一个key的修改合并到一起，形成一个大的StoreFile。当StoreFile的大小达到一定阈值后，又会对 StoreFile进行切分 *** 作，等分为两个StoreFile。

11 写 *** 作流程

(1) Client通过Zookeeper的调度，向RegionServer发出写数据请求，在Region中写数据。

(2) 数据被写入Region的MemStore，直到MemStore达到预设阈值。

(3) MemStore中的数据被Flush成一个StoreFile。

(4) 随着StoreFile文件的不断增多，当其数量增长到一定阈值后，触发Compact合并 *** 作，将多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除。

(5) StoreFiles通过不断的Compact合并 *** 作，逐步形成越来越大的StoreFile。

(6) 单个StoreFile大小超过一定阈值后，触发Split *** 作，把当前Region Split成2个新的Region。父Region会下线，新Split出的2个子Region会被HMaster分配到相应的RegionServer上，使得原先1个Region的压力得以分流到2个Region上。

可以看出HBase只有增添数据，所有的更新和删除 *** 作都是在后续的Compact历程中举行的，使得用户的写 *** 作只要进入内存就可以立刻返回，实现了HBase I/O的高性能。

12 读 *** 作流程

(1) Client访问Zookeeper，查找-ROOT-表，获取META表信息。

(2) 从META表查找，获取存放目标数据的Region信息，从而找到对应的RegionServer。

(3) 通过RegionServer获取需要查找的数据。

(4) Regionserver的内存分为MemStore和BlockCache两部分，MemStore主要用于写数据，BlockCache主要用于读数据。读请求先到MemStore中查数据，查不到就到BlockCache中查，再查不到就会到StoreFile上读，并把读的结果放入BlockCache。

寻址过程：client–>Zookeeper–>-ROOT-表–>META表–>RegionServer–>Region–>client

21 -ROOT-表结构

HBase的用-ROOT-表来记录META的Region信息，就和META记录用户表的Region信息一模一样。-ROOT-只会有一个Region。

这么一来Client端就需要先去访问-ROOT-表。所以需要知道管理-ROOT-表的RegionServer的地址。这个地址被存在ZooKeeper中。默认的路径是：

/hbase/root-region-server

22 META表结构

23 两个表的关系

HBase的所有Region元数据被存储在META表中21，随着Region的增多，META表中的数据也会增大，并分裂成多个新的Region。为了定位META表中各个Region的位置，把META表中所有Region的元数据保存在-ROOT-表中，最后由Zookeeper记录-ROOT-表的位置信息。所有客户端访问用户数据前，需要首先访问Zookeeper获得-ROOT-的位置，然后访问-ROOT-表获得META表的位置，最后根据META表中的信息确定用户数据存放的位置，如下图所示。

-ROOT-表永远不会被分割，它只有一个Region，这样可以保证最多只需要三次跳转就可以定位任意一个Region。为了加快访问速度，META表的所有Region全部保存在内存中。客户端会将查询过的位置信息缓存起来，且缓存不会主动失效。如果客户端根据缓存信息还访问不到数据，则询问相关META表的Region服务器，试图获取数据的位置，如果还是失败，则询问-ROOT-表相关的META表在哪里。最后，如果前面的信息全部失效，则通过ZooKeeper重新定位Region的信息。所以如果客户端上的缓存全部是失效，则需要进行6次网络来回，才能定位到正确的Region。

文件主要分为四个部分：Scanned block section，Non-scanned block section，Opening-time data section和Trailer。

无论是Data Block Index还是Bloom Filter，都采用了分层索引的设计。

Data Block的索引，在HFile V2中做多可支持三层索引：最底层的Data Block Index称之为Leaf Index Block，可直接索引到Data Block；中间层称之为Intermediate Index Block，最上层称之为Root Data Index，Root Data index存放在一个称之为”Load-on-open Section“区域，Region Open时会被加载到内存中。基本的索引逻辑为：由Root Data Index索引到Intermediate Block Index，再由Intermediate Block Index索引到Leaf Index Block，最后由Leaf Index Block查找到对应的Data Block。在实际场景中，Intermediate Block Index基本上不会存在，文末部分会通过详细的计算阐述它基本不存在的原因，因此，索引逻辑被简化为：由Root Data Index直接索引到Leaf Index Block，再由Leaf Index Block查找到的对应的Data Block。

在”Scanned Block Section“区域，Data Block(存放用户数据KeyValue)、存放Data Block索引的Leaf Index Block(存放Data Block的索引)与Bloom Block(Bloom Filter数据)交叉存在。

无论是Data Block的索引数据，还是Bloom Filter数据，都被拆成了多个Block，基于这样的设计，无论是索引数据，还是Bloom Filter，都可以按需读取，避免在Region Open阶段或读取阶段一次读入大量的数据，有效降低时延。

至此，一个完整的HFile已生成。我们可以通过下图再简单回顾一下Root Index Block、Leaf Index Block、Data Block所处的位置以及索引关系：

Bloom Filter包含Bloom元数据(Hash函数类型，Hash函数个数等)与 位图数据(BloomData) ，为了避免每一次读取时加载所有的Bloom Data，HFile V2中 将BloomData部分分成了多个小的Bloom Block 。BloomData数据也被当成一类Inline Block，与Data Block、Leaf Index Block交叉存在，而关于Bloom Filter的元数据与多个Bloom Block的索引信息，被存放在Load-On-Open Section部分。但需要注意的是，在FileInfo部分，保存了关于BloomFilter配置类型信息，共包含三种类型：不启用，基于Row构建BloomFilter，基于Row+Column构建Bloom Filter。混合了BloomFilter Block以后的HFile构成如下图所示：

再来看hbase如何在hdfs上去检索一行数据。首先要只要hbase的检索都是以rowkey值或者rowkey值范围来检索数据的，现在root表中检索mata表的的hregion位置，root表只会有一个region而且永远不会

被拆分以保证能够一次获取到mata表的hregion的位置，在mata表中保存所有的用户表的region的信息，region的rowkey有该region对应的表和第一行的rowkey等组成，因为一个表的rowkey在所有的

region上都是有序的字典排序，所有要检索一个rowkey只要通过对比mata表中region的rowkey就可以知道包含改rowkey的数据在那个region上，meta中还包含了region所咋的hregionserver的信息，通过

mata中的region的信息可以直接定位到包含改rowkey数据的所在的region在哪台hregionserver上。

知道region在哪台hregionserver上对已快速定位rowkey的数据还是不够的，region会根据families把数据才分成store，一个store只能包含一个family，在保存到hdfs的时候store其实就是一个目录而已，真正存数据的是filestroe也就是hfile，每一个hfile当达到一定大小的时候就会拆分成两个hfile所以一个store目录中会包含多个hfile。

因为table是按照rowkey来划分region的，region默认的大小为256M，通常会设置得更高1G,2G,4G等，所以hfile不可能比region的的值要大。但是hfile有可能还是很大，在hdfs上会拆分成不同的block放在不同的datanode上，这样子仍然无法做到精确定位。

hfile 继续划分，有data block，block index，trailler等组成，已经定位到rowkey所在的hfile时，会先读取hfile的trailer的信息以获取block index的位置，block index的key就是data block中的第一个rowkey，所以通过block index 的key就能精确的定位到要检索的rowkey在那个data block上，然后直接将该data block读取到内存，需要注意的是这里的data block已经很小了（默认是64k，不同于hdfs上的block默认为64M，hbase的hfile中的block要小的多）这样子足以读取该block到内存中，将该block进行遍历就能获取到需要的rowkey取出数据，以为这里的block只有64k这样的遍历非常迅速。这就是为什么hfile的data block要设置的如此之小的原因。

FusionStorage RA 和 Block 都是云存储产品，但它们之间有以下不同：

1 存储结构：

FusionStorage RA 采用分布式的冗余-分离计算与存储，数据存储在多个节点，每个节点都有独立访问存储空间的权限。FusionStorage RA 还支持多种存储介质设置，包括磁盘阵列、SSD 等。

Block 利用硬件存储设备提供块级存储，允许计算机访问基于块的存储设备，可以提供高速、低延迟的数据传输

2 数据访问方式：

FusionStorage RA 提供网络存储，支持多种协议接口，包括 NFS、SMB、FC、iSCSI、S3、OCD API 等，可以访问多种应用程序和计算机系统。

Block 也是网络存储产品，提供 iSCSI 接口，允许计算机直接访问基于块的存储设备。

3 大数据分析支持：

FusionStorage RA 支持 Hadoop、Spark 和 Hbase 的扩展，可以作为分布式对象存储和分布式块存储使用，用于机器学习、深度学习、大规模数据分析等。

Block 不适用于大数据分析，主要用于虚拟化、数据库、企业应用等领域。

4 扩展性：

FusionStorage RA 具有良好的可扩展性，可以支持横向和纵向扩展，配置灵活，适用于各种规模的业务需求。

Block 的扩展性相对较差，不能支持多种不同存储设备之间的互 *** 作性和灵活扩展。

总之，FusionStorage RA 能够支持更广泛的应用场景和更多类型的存储介质，并提供更高的容错性和更高的性能，因而更加适合大型企业和云平台；而 Block 更加专注于基于块的存储方案，较为适合传统企业应用场景。

1、HBase写入流程

HBase服务端没有提供update,delete接口，HBase中对数据的更新、删除 *** 作都认为是写入 *** 作，更新 *** 作会写入一个最小版本数据，删除 *** 作写写入一条标记为deleted的KV数据

11、写入流程三个阶段概况

1）客户端处理阶段：客户端将用户请求进行预处理，并根据集群元数据定位写入数据所在的RegionServer,将请求发送给RS

2）Region写入阶段：RS收到请求之后解析数据，首先把数据写入WAL,再写入对应Region对应的MemStore

3）MemStore Flush阶段：当Region中MemStore容量达到一定阈值之后，系统异步执行flush *** 作，将内存写入文件，形成HFile

12、用户写入请求在完成写入MemStore之后就会返回成功。MemStore Flush是一个异步执行的过程。

13、客户端处理阶段步骤详解：

1）客户端可以设置批量提交，如果设置了批量提交（autoflush=false）客户端会先将数据写入本地缓冲区等达到一定阈值之后才会提交。否则put请求直接会提交给服务端进行处理。

2）RS寻址，在提交之前HBase会在元数据表hbase:meta中根据rowkey找到她们归属的RS

21）客户端根据写入的表和rowkey在元数据中查找，如果能够查找出该rowkey所在的RS及Region，就直接发送写入请求

22）如果客户端没有找到rowkey信息，需要首先到zk上找到hbase:meta表所在的RS,向那RS发送查询请求获取元数据，然后在元数据中查找rowkey所在的RS,并将元数据缓存在本地，以备下次使用。

3）客户端发送远程RPC请求给RS,将数据写入目标Region的MemStore中

14、Region写入阶段步骤详解：

1）获取行锁，HBase中使用行锁保证对同一行数据的更新是互斥 *** 作，用以保证更新的原子性，要么成功要么失败

2）更新所有待写入keyValue的时间戳为当前系统时间

3）对一次写入同一个Region的一个或多个KeyValue构建一条WALEdit记录，这样做的目的是保证Region级别事务的写入原子性

4）把WALEdit写入HLog，HLog是存储在HDFS上需要sync *** 作把HLog真正落地到HDFS，在这一部暂时不用执行sync,HBase使用了disruptor实现了高效的生产者消费者队列，来异步实现WAL的追加写入 *** 纵

5）写入WAL之后再将数据写入MemStore

6）释放行锁

7）sync WAL:将HLog真正sync到HDFS,如果sync失败，执行回滚 *** 作将MemStore数据移除

8）结束写事务。更新对外可见，更新生效

15、MemStore Flush阶段详解：

151、触发flush条件

1511、MemStore级别限制，当Rgion中任意一个MemStore大小达到阈值（hbasehrgionmemstoreflushsize）默认128M

1512、Region级别限制：当Region所有MemStore的大小达到了上限（hbasehregionmemstoreblockmultiplier hbasehrgionmemstoreflushsize）超过memstore大小的倍数达到该值则阻塞所有写入请求进行flush，自我保护默认是2

1513、RegionServer级别限制：当RS中MemStore的总大小超过低水位阈值hbaseregionserverglobalmemstoresizelowerlimit hbasereagionserverglobalmemstoresize RS则开始强制执行flush,按Region中MemStore大小从大到小进行flush,直到总MemStore大小下降到低水位。

1514、当一个RegionServer中HLog数量达到一定上限（hbaseregionservermaxlogs），系统选择最早的HLog对应的Rgion进行Flush

1515、HBase定期Flush,默认是1小时确保MemStore不会长时间没有持久化。为了避免同一时间所有都进行flush，定期的flush *** 作有一定时间的随机延迟

1516、手动flush,用户可以通过flush 'tablename'或者 flush 'regionname'对一个表或者Region进行flush

152、flush执行步骤

1521、prepare阶段

遍历当前region下的MemStore做一个快照，然后新一个ConcurrentSkipListMap接受新的数据请求。此阶段需要通过锁来阻塞写请求，结束后释放锁，此过程持锁时间很短

1522、flush阶段

对快照数据按照特定格式生成HFile持久化为临时文件放在tmp目录下。这个过程涉及到磁盘IO *** 作，相对比较耗时

1523、commit阶段

把临时文件移动到指定的CF目录下。再清空快照数据。

153、MemStore Flush对业务的影响

1531、大部分MemStore Flush *** 作都不会对业务读写产生太大影响，

1532、Region Server级别呆滞的flush,会对用户请求产生较大影响，会阻塞落在该RS上的写入 *** 作。

16、HLog写入模型

161、HLog持久化级别

SKIP_WAL:只写缓存，不写HLog，不可取

ASYNC_WAL：异步写入HLog

SYNC_WAL：同步写入日志文件，数据只是被写入文件系统缓存中并没有真正落盘。默认是此级别

FSYNC_WAL：同步将数据写入日志文件并强制落盘，这是最严格的写入级别，保证数据不丢失，性能相对较差

USER_DEFAULT：如果用户没有指定持久化级别，默认HBase使用SYN_WAL等级持久化数据putsetDurability(DurabilitySYNC_WAL);

162、HLog写入模型

1、HLog写入需要经过3个阶段：手写将数据写入本地缓存，然后将本地缓存写入文件系统，最后执行syn *** 作同步到磁盘

2、HBase使用LMAX Disruptor框架实现了无锁有界队列 *** 作，写入模型如下图

2、BulkLoad 流程

21、BulkLoad使用场景:用户数据位于HDFS中，业务需要定期将这部分海量数据导入HBase系统

22、核心流程分两步

221、HFile生成阶段：运行一个MapReduce任务，map需要自己实现，将HDFS文件中的数据读取出来组装一个复合KV，其中Key是rowkey,Value可以是KeyValue对象、Put对象甚至Delete对象；reduce由HBase负责，他会根据表信息配置一个全局有序的partitioner,将partitioner文件上传到HDFS集群，设置reduce task个数为目标表的Region个数。为每个Region生成一个对应的HFile文件

222、HFile导入阶段：HFile主备就绪后，将HFile加载到在线集群。

23、Bulkload遇到的一些常见问题

231、设置正确的权限

231、BulkLoad *** 作过程涉及到的用户：

第一步，通过MapReduce任务生成HFile。假设这个过程使用的HDFS账号为：u_mapreduce

第二步，将HFile加载到HBase集群，假设这个步骤使用的账号为：u_load。

一般地：HBase集群由一个专门的账号用来管理HBase数据，该账号拥有HBase集群的所有表的最高权限，

同时可以读写HBase root目录下的所有文件，假设这个账号为：hbase_srv

232、权限设置

2321、通过MapReduce任务生成HFile，HFile文件的owner为u_mapreduce。

2322、u_load需要HFile文件以及目录的读、写权限。写的权限是因为在HFile跨越多个Region时，需要对HFile进行split *** 作。

另外u_load账号需要HBase表的Create权限

2323、hbase_srv账号把HFile文件从用户的数据目录rename到HBase的数据目录，所以hbase_sHrv需要有用户数据目录及HFile的读取

权限，但事实上仅读取权限还不够，应为加载到HBase数据目录的HFile目录的owner仍为u_mapreduce。一旦执行完compaction *** 作

之后，这些文件无法挪动到archive目录，导致文件越来越多。这个问题在HBase 2x 上修复。

232、影响Locality

如果生成HFile都在的HDFS集群和HBase所在HDFS集群时同一个，则MapReduce生成HFile，能够保证HFile与目标Region落在同一个机器上。这样就保证了Locality。由hbasebulkloadlocalitysensitiveenabled的参数控制整个逻辑，默认是true所以默认保证locality的。

如果用户MapReduce在A集群上生成HFile,通过distcp拷贝到集群B这样BulkLoad到HBase集群数据是没法保证Locality的。需要跑完BulkLoad之后再手动执行major compact，来提升loaclity。

233、BulkLoad数据复制

在13之前版本中，BulkLoad到HBase集群的数据并不会复制到备集群，这样可能无意识的导致备集群比主集群少了很多数据。在HBase13版本之后开始支持BulkLoad数据复制。需要开启开关：hbasereplicatitionbulkloadenabled=true。

hbase有本地模式和分布式模式

hbase-sitexml配置

hbasetmpdir

本地文件系统tmp目录，一般配置成local模式的设置一下，但是最好还是需要设置一下，因为很多文件都会默认设置成它下面的

线上配置

<property>

<name>hbasetmpdir</name>

<value>/mnt/路径</value>

</property>

默认值：

${javaiotmpdir}/hbase-${username}

写到系统的/tmp目录

hbaserootdir

HBase集群中所有RegionServer共享目录，用来持久化HBase的数据，一般设置的是hdfs的文件目录，如hdfs://master:9000/hbasedata

线上配置

<property>

<name>hbaserootdir</name>

<value>hdfs://master:9000/hbasedata</value>

</property>

默认值：

${hbasetmpdir}/hbase

hbaseclusterdistributed

集群的模式，分布式还是单机模式，如果设置成false的话，HBase进程和Zookeeper进程在同一个JVM进程。

线上配置为true

默认值：false

hbasezookeeperquorum

zookeeper集群的URL配置，多个host中间用逗号分割

线上配置

<property>

<name>hbasezookeeperquorum</name>

<value>master,slave,slave1</value>

</property>

默认值：localhost

hbasezookeeperpropertydataDir

ZooKeeper的zooconf中的配置。 快照的存储位置

线上配置：/home/hadoop/zookeeperData

默认值：${hbasetmpdir}/zookeeper

zookeepersessiontimeout

客户端与zk连接超时时间

线上配置：1200000（20min）

默认值：180000（3min）

hbasezookeeperpropertytickTime

Client端与zk发送心跳的时间间隔

线上配置：6000（6s）

默认值：6000

hbasesecurityauthentication

HBase集群安全认证机制，目前的版本只支持kerberos安全认证。

线上配置：kerberos

默认值：空

hbasesecurityauthorization

HBase是否开启安全授权机制

线上配置： true

默认值： false

hbaseregionserverkerberosprincipal

regionserver的kerberos认证的主体名称（由三部分组成：服务或用户名称、实例名称以及域名）

线上配置：hbase/_HOST@HADOOPxxxxxxCOM

默认：无

hbaseregionserverkeytabfile

regionserver keytab文件路径

线上配置：/home/hadoop/etc/conf/hbasekeytab

默认值：无

hbasemasterkerberosprincipal

master的kerberos认证的主体名称（由三部分组成：服务或用户名称、实例名称以及域名）

线上配置：hbase/_HOST@HADOOPxxxxxxCOM

默认：无

hbasemasterkeytabfile

master keytab文件路径

线上配置：/home/hadoop/etc/conf/hbasekeytab

默认值：无

hbaseregionserverhandlercount

regionserver处理IO请求的线程数

线上配置：50

默认配置：10

hbaseregionserverglobalmemstoreupperLimit

RegionServer进程block进行flush触发条件：该节点上所有region的memstore之和达到upperLimitheapsize

线上配置：045

默认配置：04

hbaseregionserverglobalmemstorelowerLimit

RegionServer进程触发flush的一个条件：该节点上所有region的memstore之和达到lowerLimitheapsize

线上配置：04

默认配置：035

hbaseclientwritebuffer

客户端写buffer，设置autoFlush为false时，当客户端写满buffer才flush

线上配置：8388608（8M）

默认配置：2097152（2M）

hbasehregionmaxfilesize

单个ColumnFamily的region大小，若按照ConstantSizeRegionSplitPolicy策略，超过设置的该值则自动split

线上配置：107374182400（100G）

默认配置：21474836480（20G）

hbasehregionmemstoreblockmultiplier

超过memstore大小的倍数达到该值则block所有写入请求，自我保护

线上配置：8（内存够大可以适当调大一些，出现这种情况需要客户端做调整）

默认配置：2

hbasehregionmemstoreflushsize

memstore大小，当达到该值则会flush到外存设备

线上配置：104857600（100M）

默认值： 134217728（128M）

hbasehregionmemstoremslabenabled

是否开启mslab方案，减少因内存碎片导致的Full GC，提高整体性能

线上配置：true

默认配置： true

hbaseregionservermaxlogs

regionserver的hlog数量

线上配置：128

默认配置：32

hbaseregionserverhlogblocksize

hlog大小上限，达到该值则block，进行roll掉

线上配置：536870912（512M）

默认配置：hdfs配置的block大小

hbasehstorecompactionmin

进入minor compact队列的storefiles最小个数

线上配置：10

默认配置：3

hbasehstorecompactionmax

单次minor compact最多的文件个数

线上配置：30

默认配置：10

hbasehstoreblockingStoreFiles

当某一个region的storefile个数达到该值则block写入，等待compact

线上配置：100（生产环境可以设置得很大）

默认配置： 7

hbasehstoreblockingWaitTime

block的等待时间

线上配置：90000（90s）

默认配置：90000（90s）

hbasehregionmajorcompaction

触发major compact的周期

线上配置：0（关掉major compact）

默认配置：86400000（1d）

hbaseregionserverthreadcompactionlarge

large compact线程池的线程个数

线上配置：5

默认配置：1

hbaseregionserverthreadcompactionsmall

small compact线程池的线程个数

线上配置：5

默认配置：1

hbaseregionserverthreadcompactionthrottle

compact（major和minor）请求进入large和small compact线程池的临界点

线上配置：10737418240（10G）

默认配置：2 thisminFilesToCompact thisregionmemstoreFlushSize

hbasehstorecompactionmaxsize

minor compact队列中storefile文件最大size

线上配置：21474836480（20G）

默认配置：LongMAX_VALUE

hbaserpctimeout

RPC请求timeout时间

线上配置：300000（5min）

默认配置：60000（10s）

hbaseregionserverregionsplitpolicy

split *** 作默认的策略

线上配置： orgapachehadoophbaseregionserverConstantSizeRegionSplitPolicy（采取老的策略，自己控制split）

默认配置： orgapachehadoophbaseregionserverIncreasingToUpperBoundRegionSplitPolicy（在region没有达到maxFileSize的前提下，如果fileSize达到regionCount regionCount flushSize则进行split *** 作）

hbaseregionserverregionSplitLimit

单台RegionServer上region数上限

线上配置：150

默认配置：2147483647

hbase-envsh配置

指定系统运行环境

export JAVA_HOME=/usr/lib/jvm/java-6-sun/ #JDK HOME

export HBASE_HOME=/home/hadoop/cdh4/hbase-0942-cdh421 # HBase 安装目录

export HBASE_LOG_DIR=/mnt/dfs/11/hbase/hbase-logs #日志输出路径

JVM参数调优

export HBASE_OPTS="-verbose:gc -XX:+PrintGCDetails -Xloggc:${HBASE_LOG_DIR}/hbase-gclog -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime \

-server -Xmx20480m -Xms20480m -Xmn10240m -Xss256k -XX:SurvivorRatio=4 -XX:MaxPermSize=256m -XX:MaxTenuringThreshold=15 \

-XX:ParallelGCThreads=16 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection \

-XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSMaxAbortablePrecleanTime=5000 \

"

1、FQDN：(Fully Qualified Domain Name)全限定域名：同时带有主机名和域名的名称。

2、RegionServer

HRegionServer is the RegionServer implementation It is responsible for serving and managing regions In a distributed cluster, a RegionServer runs on a DataNode

3、Regions

Regions are the basic element of availability and distribution for tables, and are comprised of a Store per Column Family The hierarchy of objects is as follows:

Table                    (HBase table)

    Region              (Regions for the table)

        Store            (Store per ColumnFamily for each Region for the table)

            MemStore    (MemStore for each Store for each Region for the table)

            StoreFile    (StoreFiles for each Store for each Region for the table)

                Block    (Blocks within a StoreFile within a Store for each Region for the table)

对应的数据存储结构：

Region结构说明

（二）单个节点停止

HBASE 节点停止分为优雅停止（Graceful Stop）和立即停止（• Stop  ）

• Graceful Stop 该方式会促使Regions重新分配到其它的RegionServer节点，下线region在新节点部署后才重新分配下一个region,当所有region都在新节点部署后才下线自己，这样增加节点断开hbase服务的有效性。该方式设置了一个超时时间，如果在指定的超时时间没有成功完成停止节点的工作，会转为使用kill -9 终止RegionServe服务。恢复时会从受影响的region开始。执行的命令:

$ /bin/graceful_stopsh

Usage: graceful_stopsh [--config &conf-dir>] [--restart] [--reload] [--thrift] [--

rest] &hostname>

thrift If we should stop/start thrift before/after the hbase stop/start

rest If we should stop/start rest before/after the hbase stop/start

restart If we should restart after graceful stop

reload Move offloaded regions back on to the stopped server

debug Move offloaded regions back on to the stopped server

hostname Hostname of server we are to stop

• Stop    刚方式RegionServer会立即关所有的region，然后关闭自己，不会将Regions重新分配到其它的RegionServer节点,这种方式当region比较多时关闭有可能需要很长时间，该方式使用ill -5 终止RegionServe服务。

$ /bin/hbase-daemonsh stop regionserver

两种方式都建议关闭Load Balancer:

关闭命令：

hbase(main):001:0> balance_switch false

开启命令：

balance_switch true

（三）、节点启动

手工启动命令：

$ /bin/hbase daemonsh start regionserver

bin/graceful_stopsh --restart --reload --debugregionserver_nodename；

他会先将需要重启的regionserver上面的所有region迁移到其它的服务器，然后重启，最后又会将之前的region迁移回来。

Hbase中每个Region自己维护其在hbase:meta表中的信息。

状态机中包括下面几种状态：

offline：region离线没有开启

opening：region正在被打开

open：region正在打开，并且region server通知了master

failed_open：regionserver打开失败

closing：region正在被关闭

closed：regionserver正在关闭，并且已经通知了master

failed_close：regionserver关闭失败了

splitting：region server通知master，region正在被切分

split：region server通知master，region已经被切分完了

spliting_new：region是切分过程中新建的文件

merging：regionserver通知master region正在合并

merged：regionserver通知master region合并完了

merging_new：region是合并新建出来的

不同的颜色是不同含义：

棕色：离线状态，属于一种短暂的瞬间状态（比如关闭后开启的中间状态）、停止状态或者初始化的时候的状态

绿色：正常的状态，可以支持请求访问

蓝色：短暂的状态

红色：失败

**：合并或者切分的状态

灰色：刚开始的状态

各个序号代表不同的 *** 作场景：

1、Master向region server发起region从offline到openning的状态请求，regionserver如果没有收到，master会尝试重试几次。RegionServer接收到请求后，regin状态变成opening

2、如果Master发起的open请求超过次数，那么无论region server是否已经打开region，master都会命令region server关闭文件，状态变为closing

3、当region server打开region后，会尝试通知master，让他把region状态修改为open，并通知regsion server。这样region才能变为open状态

4、如果region server打开四百，会尝试通知master。master会把region的状态变更为closed，并且尝试去其他的region server打开region

5、如果master尝试几次后，都没有打开region，就会把状态变更为failed_open

6、master通知region server关闭region，如果没有反应，会重试

7、如果region server没有在线，会抛出异常。然后region的状态会变成closing

8、如果region server在线，但是好几次都没响应，就会更新状态为failed_close

9、如果region server收到请求，并且关闭了region，那么会通知master把region状态修改为closed。并且把region分配给其他的server

10、在分配之前，master会先把region从closed状态转换为offline

11、如果region server正在切分region，会通知mastere。master把region状态由open变为splitting，并且把新增两个region的信息，这两个region都是splitting_new状态

12、如果region切分成功，当前的region状态从splitting变成split；新增的两个region状态从splitting_new变成open

13、如果切分失败，状态从splitting回到open，两个region也从splitting_new变成offline

14、如果region server想要合并两个region，那么也会先通知master。master把两个region从open变成merging，然后增加一个新的region，状态为merging_new

15、合并成功,旧的region从merging变为merged，新的region从merging_new变为open

16、如果合并失败，region的状态从merging变回open，新建的一个region状态又变成offline

17、如果管理员通过hbase shell *** 作分配region，master会尝试把失败的状态变成close

baiduX��,�

以上就是关于谁能说说mangodb 和 hbase的区别全部的内容，包括:谁能说说mangodb 和 hbase的区别、HBase读写 *** 作-ROOT-表和.META.表、Hfile结构等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！