HBase 和 Schema 设计

    关于各种非 RDBMS 数据存储建模的优缺点，可以在 Ian Varley 的硕士论文 中找到。虽然有点过时，但是如果你想了解 HBase schema 的建模方式和 RDBMS 的实现方式有什么区别的话，可以当做背景知识阅读一下。另外，阅读 keyvalue 来了解 HBase 内部是如何存储数据的，以及 章节。

    Cloud Bigtable 网站上的 Designing Your Schema 是很好的相关文档，从里面学到的内容同样适用于 HBase 领域；只要把文档里任何引用的值除 10 左右即可得到对 HBase 适用的值。比如：文档中提到单个值的大小可以到约 10MBs，HBase 也类似，或者最好尽可能的小一些；同时文档中提到，Cloud Bigtable 最多有 100 个列族，在 HBase 建模时考虑改为 约 10 个列族。

    另请参阅 Robert Yokota 的 (其他 HBaser 所完成工作的最新信息)，以便对 HBase 模型上的使用案例进行有用的分类。

    HBase schemas 可以通过 The Apache HBase Shell 或者 Java API 来创建或者更新。

    当进行列族的修改时，必须禁用表，比如：

    0.92.x 可以支持在线 scheme 变更, 但是 0.90.x 版本需要禁用表。

    当表或者列族被修改时(比如 region 大小，block 大小)，这些更改会在下一次 major 合并时生效，同时 StoreFiles 会被重写。

    阅读 store 获取更多关于 StoreFiles 的信息。

    35. 表 Schema 的经验法则

    因为存在许多种不同的数据集，不同的访问模式和服务层级的要求。所以，以下经验法则只是概述。阅读完此列表后，请阅读这一章的剩余部分以获得更多详细信息。

    • 目标是把 region 的大小限制在 10 到 50 GB 之间。

    • 对于拥有 1 或 2 个列族的表来说，50-100 个 region 是比较合适的。请记住， region 是列族的连续段。

    • 保持列族名称尽可能短。每个值都会存储列族的名称(忽略前缀编码)。它们不应该像典型 RDBMS 那样，是自文档化，描述性的名称。

    • 如果只有一个列族会频繁写，那么只让这个列族占用内存。当分配资源的时候注意写入模式。