HBase：Table Schema Rules Of Thumb

1.声明

当前内容主要用于本人学习和复习，当前内容主要为官方文档的翻译和理解

2.Table Schema Rules Of Thumb

There are many different data sets, with different access patterns and service-level expectations.Therefore, these rules of thumb are only an overview. Read the rest of this chapter to get more details after you have gone through this list.

这里有许多不同的数据集，具有不同的访问模式和服务级别期望。因此，这些规则经验只是一个概述。阅读这单元剩余部分的内容，浏览这些列表后，你将会获取更多的详情信息

1. Aim to have regions sized between 10 and 50 GB.

   1.

   目标区间大小应该在10到50GB

2. Aim to have cells no larger than 10 MB, or 50 MB if you use mob. Otherwise, consider storing your cell data in HDFS and store a pointer to the data in HBase.

   2.

   如果你使用mob,目标单元格大小应该不大于10M或者50M.如果超出了，那么你应该将单元格数据存放在HDFS中并且在HBase中存储对应数据的一个指针

   （本人表示不理解如何存储数据到HDFS并且在HBase中存储对应的指针？）

3. A typical schema has between 1 and 3 column families per table. HBase tables should not be designed to mimic RDBMS tables.

   3.在表中一个类型的schema应该具有1到3个列族。HBase表不应该被设计和关系型数据库的表一样

4. Around 50-100 regions is a good number for a table with 1 or 2 column families. Remember that a region is a contiguous segment of a column family.

   在一个具有1或者2个列族的表中，大约50到100个区间是一个最好的数字。

   记住这个区间是一段连续的一个列族

   （就是描述了区间和列族的关系，区间是列族的集合）

5. Keep your column family names as short as possible. The column family names are stored for every value (ignoring prefix encoding). They should not be self-documenting and descriptive like in a typical RDBMS.

   5.

   尽可能地保证你的列族名称简短

   。这个列族名称是存储每个排序地值(忽略前缀编码)。

   他们不应该自我记录和描述，不应该像关系型数据库一样

   （这就是说列族短，并且不应该自我描述。。。）

6. If you are storing time-based machine data or logging information, and the row key is based on device ID or service ID plus time, you can end up with a pattern where older data regions never have additional writes beyond a certain age. In this type of situation, you end up with a small number of active regions and a large number of older regions which have no new writes. For these situations, you can tolerate a larger number of regions because your resource consumption is driven by the active regions only.

   6.如果你存储基于时间机器数据或者记录信息，这个row key是基于驱动ID或服务ID+s时间，你最终会得到一个结果，即旧数据区域永远不会在某一段时间有写入。在这类情况中，你最终会得到一个没有新写入的小数量的活动区间和大数量的旧区间。为了解决这种情况，你应该容忍大量区间因为你的资源消耗都是由活动区间驱动的。

   (如果使用驱动ID或者服务ID+时间，那么驱动ID和服务ID+时间在一天中不会有很大的变化，但是该列族种的数据确实可以改变，并且这种改变时非常小的(例如驱动改变或者故障)，所以一般这个区间中的数据都是旧的数据(驱动的信息)，只有一部分数据是经常变动的(每天启动驱动的时间)，所以你每天实际上就是看这些变动的活动区间)

7. If only one column family is busy with writes, only that column family accomulates memory. Be aware of write patterns when allocating resources.

   7.如果只有一个列族是写入繁忙的，那么只有这个列族才可以积累内存。注意在资源分配时的写模式

3.RegionServer Sizing Rules of Thumb

Lars Hofhansl wrote a great blog post about RegionServer memory sizing. The upshot is that you probably need more memory than you think you need. He goes into the impact of region size, memstore size, HDFS replication factor, and other things to check.

Lars Hofhansl 写了一篇非常棒的关于RegionServer 内存大小的博文。结果就是你可能需要比你想的要更多的内存。

他研究了关于区间大小的影响，内存大小，HDFS复制因子和一些其他的东西检查

(即内存大小、HDFS复制因子和一些东西检查都会影响区间大小）

Personally I would place the maximum disk space per machine that can be

served exclusively with HBase around 6T, unless you have a very read-

heavy workload. In that case the Java heap should be 32GB (20G regions,

128M memstores, the rest defaults).

我个人认为每个服务机器上应该部署的HBase的磁盘时6T

(太大了，不愧时大数据分布式数据库)，除非你非常了解并有很大的工作量。

事实上Java堆因该是32GB（20G分区，128M内存，其他的为默认值）

4.总结

1.区间就是一段连续的列族，并且区间的大小应该是10G到50G

2.单元格的数据应该小于10M或者50M,如果超过了应该将其存放在HDFS中，并在HBase中添加一个对应的指针(如何创建指针？)

3.HBase的列族不能和关系型数据库的列一样具有描述性，并且HBase的列族名应该简短

4.HBase是用于大数据量的，当前官方文档将HBase的磁盘建议设置为6T,并且Java堆为32GB…

以上纯属个人见解，如有问题请联本人！