LW_ICE

环境CentOS7、MongoDB-4.4.13端口/角色mongosconfigsvrshard1shard2shard3192.168.56.155270172701929017(主节点)29018(仲裁节点)29019(副节点)192.168.56.156270172701929017(副节点)29018(主节点)29019(仲裁节点)192.168.56.157270172701929017(仲裁节点)29018(副节点)29

相信长时间运维HBase集群的童鞋肯定都会对RIT（Region-In-Transition，很多参考资料误解为Region-In-Transaction，需要注意）有一种咬牙切齿的痛恨感，一旦Region处于长时间的RIT就会有些不知所措，至少以前的我就是这样过来的。正所谓“恐惧来源于未知”，不知所措意味着我们对RIT知之甚少，然而“凡事都有因果，万事皆有源头”，处于RIT状态的Region只是

HBase发展到当下，对其进行的各种优化从未停止，而GC优化更是其中的重中之重。从0.94版本提出MemStoreLAB策略、Memstore Chuck Pool策略对写缓存Memstore进行优化开始，到0.96版本提出BucketCache以及堆外内存方案对读缓存BlockCache进行优化，再到后续2.0版本宣称会引入更多堆外内存，可见HBase会将堆外内存的使用作为优化GC的一个战略方向

背景介绍在HBase1.1.0发布之前，HBase同一集群上的用户、表都是平等的，没有优劣之分。这种’大同’社会看起来完美，实际上有很多问题。最棘手的主要有这么两个，其一是某些业务较其他业务重要，需要在资源有限的情况下优先保证核心重要业务的正常运行，其二是有些业务在某些场景下会时常’抽风’，QPS常常居高不下，严重消耗系统资源，导致其他业务无法正常运转。这实际上是典型的多租户问题，社区针对

HBase采用类LSM的架构体系，数据写入并没有直接写入数据文件，而是会先写入缓存（Memstore），在满足一定条件下缓存数据再会异步刷新到硬盘。为了防止数据写入缓存之后不会因为RegionServer进程发生异常导致数据丢失，在写入缓存之前会首先将数据顺序写入HLog中。如果不幸一旦发生RegionServer宕机或者其他异常，这种设计可以从HLog中进行日志回放进行数据补救，保证数据不丢失。

任何系统都会有各种各样的问题，有些是系统本身设计问题，有些却是使用姿势问题。HBase也一样，在真实生产线上大家或多或少都会遇到很多问题，有些是HBase还需要完善的，有些是我们确实对它了解太少。总结起来，大家遇到的主要问题无非是Full GC异常导致宕机问题、RIT问题、写吞吐量太低以及读延迟较大。Full GC问题之前在一些文章里面已经讲过它的来龙去脉，主要的解决方案目前主要有两方

上一篇文章主要介绍了HBase读性能优化的基本套路，本篇文章来说道说道如何诊断HBase写数据的异常问题以及优化写性能。和读相比，HBase写数据流程倒是显得很简单：数据先顺序写入HLog，再写入对应的缓存Memstore，当Memstore中数据大小达到一定阈值（128M）之后，系统会异步将Memstore中数据flush到HDFS形成小文件。HBase数据写入通常会遇到两类问题，一类是

和写流程相比，HBase读数据是一个更加复杂的操作流程，这主要基于两个方面的原因：其一是因为整个HBase存储引擎基于LSM-Like树实现，因此一次范围查询可能会涉及多个分片、多块缓存甚至多个数据存储文件；其二是因为HBase中更新操作以及删除操作实现都很简单，更新操作并没有更新原有数据，而是使用时间戳属性实现了多版本。删除操作也并没有真正删除原有数据，只是插入了一条打上”deleted”标签的

成功启动MongoDB后，再打开一个命令行窗口输入mongo，就可以进行数据库的一些操作。输入help可以看到基本操作命令：show dbs:显示数据库列表 show collections：显示当前数据库中的集合（类似关系数据库中的表） show users：显示用户use ：切换当前数据库，这和MS-SQL里面的意思一样 db.help()：显示数据库操作命

MongoDB是一个非常有前途的数据库，MongoDB官方对自己的定位是通用数据库，其实这个定位跟MySQL有些像。虽其流行度还远未达到MySQL的水平，但笔者有个可能不恰当的比较，MongoDB就像N年前的MySQL，随着时间的推移，会变得越来越强大，也会越来越流行。下面结合MongoDB的几大特色来谈谈MongoDB的适用场景。首先，MongoDB是文档型（Document store

上一篇文章主要基于工作流程对compaction进行了介绍，同时说明了compaction的核心作用是通过合并大量小文件为一个大文件来减少hfile的总数量，进而保证读延迟的稳定。合并文件首先是读出所有小文件的KVs，再写入同一个大文件，这个过程会带来严重的IO压力和带宽压力，对整个系统的读请求和写请求带来不同程度的影响。因此HBase对于compaction的设计总是会追求一个平衡点，一

了解HBase的童鞋都知道，HBase是一种Log-Structured Merge Tree架构模式，用户数据写入先写WAL，再写缓存，满足一定条件后缓存数据会执行flush操作真正落盘，形成一个数据文件HFile。随着数据写入不断增多，flush次数也会不断增多，进而HFile数据文件就会越来越多。然而，太多数据文件会导致数据查询IO次数增多，因此HBase尝试着不断对这些文件进行合并，这个合

HBase自身具有极好的扩展性，也因此，构建扩展集群是它的天生强项之一。在实际线上应用中很多业务都运行在一个集群上，业务之间共享集群硬件、软件资源。那问题来了，一个集群上面到底应该运行哪些业务可以最大程度上利用系统的软硬件资源？另外，对于一个给定业务来说，应该如何规划集群的硬件容量才能使得资源不浪费？最后，一个给定的RegionServer上到底部署多少Region比较合适？想必这些问题都曾经困惑