我们这次性能改造主要是针对mysql数据库中一张存在瓶颈问题的表进行迁移至Hbase，希望通过Hbase来解决当前的瓶颈性问题，在前期个方面调研后我们觉得这件事是大有可为的。改造完成后服务的吞吐能力也将带来成倍的提升。
业务场景：业务通过调用我们基础服务后会将记录保存到一张log表中，后续关于所有的动作和结果也会根据这条log记录ID进行更改（通过回调的方式）。因为我们现在服务能力有限每天只会产生200-300w条数据，后期如果全量接入后每天的数据量预估是5000w条左右。
行键方案1: MYSQL 表自增主键作为Hbase行键 操作说明：bigint可以精确地表示从-2^63到2^63-1，即从-9,223,372,036,854,775,808到 9,223,372,036,854,775,807之间的整数都可以由bigint表示，它占用了八个字节的存储空间。
每天5千万数据多少年可以触发范围异常呢？
9,223,372,036,854,775,807/50000000/365 = 505390248（年）
在数据库中创建一张表，主键ID类型为bigint 长度为20，自增。每次10分钟清理一次数据。基础服务创建log前往该表插入一条数据获得id，作为hbase行键id。
优点：行键方案2: 日期-行键-zk/redis 由zk和redis生成行键的ID 操作说明：完全不用考虑因为id带来的逻辑问题和分布式id问题
优点：在创建记录前，先通过zk/redis生成id，然后标注通过zk/redis标示由谁生成，如果只是用zk或redis其一负责id生成可以忽略最后表示
行键方案3: uuid 或者 分布式ID生成器 操作说明：可以直接使用zk和redis相关接口进行创建，比较灵活。
优点：使用相关工具类即可，分布式ID生成器可能需要引入外部第三方jar包
缺点：简单
总结1.长字符串存储比较占空间，同时要选择比较稳定的分布式ID生成器，避免出现相同ID出现导致问题
2.无法根据行键进行范围比较（数字范围）
因为我们是提供基础服务的，考虑到数据回调场景，我们选择了第一种通过MYSQL 表来管理Hbase的行键。这样可以降低我们的改造风险。
