前期讨论参考 #762
背景：hbase默认1个分区，容易导致分区所在的机器负载过高，出现瓶颈。region分裂时，会拆分hfile为2个引用，当下一次compaction时对实际数据进行拆分。
预分区方案1，用户手动配置，提供所有分区信息，主要包括每个分区边界。
涉及到几个变量：
- 表种类：顶点、边、索引。顶点和边可以按照顶点ID进行分区；索引分为字符索引和数字索引，字符索引可以按照field-value分区，数字索引可以按照index-label + field-value分区。
- 顶点ID（也是边ID的前缀）包含多种，可抽象为字符串和数字两种。字符串ID的长度是与原始数据的长度一致，但是前面会增加IdLen前缀；数字ID也会被压缩编码，本质上变为字符串，同样会增加IdLen前缀；
- 顶点ID如果是主键，则需要根据顶点类型和主键属性拼接成ID，"vertexLabelID:primaryValue"的形式，顶点类型ID需要在创建元数据之后才能确定。
- 总结来看，通过用户配置的方式代价是比较高的，涉及到的变量多，且还需依赖内容的长度和顶点类型ID，难度不小。
预分区方案2，用户手动配置（可选），提供分区数量即可。
- 顶点和边，以顶点ID的hash值，取1字节作为rowkey前缀。本质上是以顶点作为分区键。
- 字符索引，以索引field-value的hash值，取1字节作为rowkey前缀。
- 数字索引，需要范围检索，不增加前缀（保持原值：index-label + field-value，需要考虑手动分区，比如创建index-label的时候设置partitions）
前期讨论参考 #762
背景：hbase默认1个分区，容易导致分区所在的机器负载过高，出现瓶颈。region分裂时，会拆分hfile为2个引用，当下一次compaction时对实际数据进行拆分。
预分区方案1，用户手动配置，提供所有分区信息，主要包括每个分区边界。
涉及到几个变量：
预分区方案2，用户手动配置（可选），提供分区数量即可。