如果我们面临应用程序的设计阶段，并且我们认为HBase将是一个很好的契合，那么设计行键和模式以适合HBase数据模型和架构是正确的方法。
但是，有时移动最初为RDBMS为HBase设计的数据库是有意义的。

这种方法有意义的常见场景是达到其可伸缩性限制的MySQL数据库实例。
存在用于水平缩放MySQL实例的技术(换句话说)，但此过程通常是麻烦的并且有问题，因为MySQL最初不设计用于分片。

从关系模型转换到HBase模型是一个相对较新的学科。
然而，某些既定的思想模式正在出现并在接近过渡时结合成三个关键原则。
这些原则是Denormalization，复制和智能键(DDI)。

• Denormalization：关系数据库模型取决于A)归一化数据库模式和B)在表之间连接以响应SQL操作。数据库归一化是一种技术，该技术将防止数据丢失，冗余和其他异常，因为更新和检索数据。
  专家遵循的规则有许多规则到达标准化的数据库模式(而数据库归一化是整个研究本身)，但该过程通常涉及将较大的表划分为较小的表格并定义它们之间的关系。数据库非规范化与归一化相反，其中，更小，更具体的表格连接到更大，更大的表格中。
  这是一个常见的模式，当转换到HBase时，因为没有在表中提供连接，并且由于它们涉及昂贵的磁盘操作，所连接可以缓慢。守护到更新和检索异常现在是HBase客户端应用程序的作业，因为通过归一化提供给保护是空的，并且void。

• 复制：正如我们对数据库架构的大小化，我们可能会最终重复数据，因为它可以避免跨多个表的昂贵读取操作。不要担心额外的存储(当然也是理由的);我们可以使用HBase的自动可扩展性来实现优势。
  但是，请注意，客户端应用程序将需要额外的工作来复制数据，并记住当本身的HBase仅提供不跨行的行级原子操作(HBase-5229 Jira)或者跨表中描述的异常。

• 智能键：因为存储在HBase中的数据是由行键订购的，并且行键是系统提供的唯一本机索引，所以行键的仔细智能设计可以产生巨大的差异。例如，行密钥可以是服务订单号和放置服务订单的客户的ID号的组合。
  此行键设计将允许我们查找与服务订单相关的数据或者查找与客户相关的数据在同一表中使用相同的行键。某些查询的这种技术将更快，避免昂贵的表加入。

为了澄清这些特定的思想模式，请参加客户联系信息表并将其放在典型的服务订单数据库的上下文中。
该图显示了标准化的服务订单数据库模式可能看起来像什么。

在RDBMS归一化规则之后，设置示例客户联系信息表，以便与服务订单表分开，以避免在服务订单关闭并可能删除时丢失客户数据。
采用相同的方法表，这意味着可以独立于服务订单将新产品添加到虚构数据库中。

通过依赖RDBMS加入操作，该模式支持显示针对特定产品打开的服务订单数以及产品正在使用的客户位置的查询。

这一切都很好，也是如此，但它是你与RDBM一起使用的架构。
如何将此模式转换为HBase Schema？
下图说明了可能的HBase方案 - 遵循DDI设计模式的HBase方案。

客户联系信息表已通过包括客户名称和联系信息代替以前使用的外键。
此外，通过保持客户联系信息表如此复制数据。
现在联接跨服务订单表和客户联系信息表无需。

另外，已经采用了智能行密钥设计，其将产品编号与客户编号组合以形成服务订单号(例如A100 | 00001)。
使用此智能密钥，服务订单表可以提供关于目前体验产品问题的产品缺陷和客户的重要报告。

所有这些查询都可以以行级别原子时尚为应用程序支持。
因为我们知道HBase订单排序并以lexicographic方式对其进行排序，所以应用程序可以在发出报告时对数据通道进行某些受过教育的猜测。
(例如，所有*系列产品编号都将存储在一起。
)

由HBase Schema表示的服务订单数据库是一个相对简单的示例，但它说明了HBase如何在某些情况下与RDBMS世界相交并提供显着的值。
如果虚构有Terabytes甚至卑鄙的服务呼叫数据来存储，HBase会对成本，可靠性，性能和规模造成巨大差异。

当然，我们可以以几种不同的方式设计服务订单HBase模式。
不可否认，设计都取决于必须支持的查询，但我们可以将一些关系数据库转换为非常强大的HBase应用程序以进行生产使用，只要我们从HBase架构和DDI设计模式的稳定了解工作。

此示例假设由利用HBase客户端API的Java应用程序执行查询，或者可能通过Apache Trevift的另一种语言执行。
本申请模型可能符合要求的要求，并为虚构服务提供有用的性能和定制选项。