一.维度
1.数据模型
数据有多种存储的方式，包括键值对【类似Map】、半结构化的列式存储和文档结构存储。
2.存储模型
内存还是磁盘持久化可以和RDBMS进行比较，它们通常持久化存储数据到磁盘中。即使需要的是纯粹内存模式，也仍旧有其他方案。一旦考虑持久化存储，就需要考虑选择的方案是否影响到访问模式。
3.一致性模型
严格一致性还是最终一致性？问题在于存储系统如何实现它的目标：是否必须降低一致性要求?虽然这种问题很粗浅，但是在特定的场景中会产生巨大影响。因为一致性可能会影响操作延迟，即系统响应读写请求的速度。这需要权衡投入和产出后得到一个折中结果。
4.物理模型
分布式模式还是单机模式？这种架构看起来像什么？是仅仅运行在单个机器上，还是分布在多台机器上，但分布及扩展规则由客户端管理，换句话说，由用户自己的代码管理？也许分布式模式仅仅是个事后的工作，并且只会在用户需要扩展系统时产生问题。如果系统提供了一定的扩展性，那么需要用户采取特定的操作吗？最简单的解决方案就是一次增加一台机器，并且设置好分区（这点对于不支持虚拟分区的系统非常重要），设置时需要考虑同时提高每个分区的处理能力，因为系统的每个部分都需要提供均衡的性能。
5.读/写性能
用户必须了解自己的应用程序的访问模式。是读多写少还是读写相当，或者是写多读少。是用范围扫描数据好，还是用随机读请求数据更好？有些系统仅仅对这些中的一种支持的非常好，有些系统则对各种情况都提供了很好的支持。
6.辅助索引
辅助索引支持用户按不同的字段和排序方式来访问表。这个维度覆盖了某些完全没有辅助索引支持且不保证数据排序的系统（类似于HashMap，及用户需要知道数据对应键的值），到某些可能通过外部手段简单支持这些功能的系统。如果存储系统不提供这项功能，用户的应用应该可以应对或自己模拟辅助索引。
7.故障处理
机器会崩溃是一个客观存在的问题，需要有一套数据迁移方案来应对这种情况。每个数据存储如何进行服务器故障处理？故障处理完毕之后是否可以正常工作？这与一致性模式维度有关系，因为失去一台服务器可能会造成数据存储的空洞。甚至使整个数据存储不可用。如果替换故障服务器，那么恢复100%服务的难度有多大？从一个正在提供服务的集群中卸载一台服务器时，也会遇到类似的问题。
8.压缩
当用户需要存储TB级的数据时，尤其当这些数据差异很小或由可读性文本组成时，压缩会带来非常好的效果，即能节省大量原始数据存储。有些压缩算法可以将此类的数据压缩到原始文件大小的十分之一。有可选择的压缩组件，有哪些压缩算法可用。
9.负载均衡
假如用户有高读写吞吐量的需求，就要考虑配置一套能够随着负载变化自动均衡处理能力的系统。虽然这样不能完全解决该问题，但是也可以帮助用户设计高读写吞吐量的程序。
10.原子操作的读-修改-写
RDBMS提供了很多这类的操作（因为它是一个集中式的面向单服务器的系统），但这些操作在分布式系统中较难实现，这些操作可以帮助用户避免多线程造成的资源竞争，也可以帮助用户完成无共享应用服务器的设计。有了这些比较并交换操作，或者说检查并设置操作，在设计系统的时候可以有效地降低客户端的复杂度。
11.加锁、等待和死锁
众所周知，复杂的事务处理，如两阶段提交，会增加多个客户端竞争同一个资源资源的可能性。最糟糕的情况就是死锁，这种情况也很难解决。用户需要支持的系统采用哪种模型？这种锁模型能否避免等待和死锁。
二.可扩展性
RDBMS非常适合事务性操作，但不见长于超大规模的数据分析处理，因为超大规模的查询需要进行大规模的数据记录扫描或全表扫描。分析型数据库可以存储数百或数千TB的数据，在一台服务器上做查询工作的响应时间，会远远超过用户可接受的合理响应时间。垂直扩展服务器性能，即增加CPU核数和磁盘数目，也并不能很好地解决该问题。
更糟糕的是，RDBMS的等待和死锁的出现频率，与事务和并发的增加并不是线性关系，准确地说，与并发数目的平方以及事务规模的3次方甚至5次方相关。分区通常是一个不切实际的解决方案，因为它需要客户端采用非常复杂的方式和较高的代价来维护分区信息。
一些商业RDBMS也解决过类似的问题，但它们往往只是特定地解决了问题的某几个方面，更重要的是，它们非常的昂贵。而一些开源的RDBMS解决方案中，往往放弃了其中的一些甚至全部的关系型特性，如辅助索引，来换取更高的性能拓展能力。
问题是，为了性能而一直放弃以上关系型特征是否值得？用户可以反范式化数据模型来避免等待，并且可以通过降低锁粒度的方式来尽量避免死锁。数据增长时，无需重新分区迁移数据并内嵌水平扩展性的方法。最后，用户还要面对容错和数据可用性问题，采用提高扩展性的机制，用户最终会得到一个NoSQL的解决方案，更确切地说，HBase可以满足这些需求。
三.数据库的范式化和反范式化
不同的规模，经常需要设计不同的系统结构，对这种原则的最佳描述是：反范式化、复制和智能的主键。这就需要重新思考在类似BigTable的存储系统中如何才能高效合理地存储数据。
部分原则是采用反范式化模式，例如将数据之前存放在多张表中的数据存储在一张表中，这样在读取的时候就不需要从多张表中聚合数据。或者预先物化所需的视图，一次优化从而避免进一步的处理来提高读取性能。
有非常多的方法来转换一对一、一对多、多对多的关系，以适应HBase的底层架构。用户需要充分理解HBase存储设计的潜在能力，然后深思熟虑地决定用哪一种实现方式。对稀疏矩阵、宽表、列式存储的支持使得数据在存储的时候无需规范化，同时也可以避免查询时采用开销很大的JOIN操作聚合数据。使用智能的主键可以控制数据怎样去存储以及存储在什么位置。由于可以使用行键的部分内容进行范围检索，行键作为组合键设计时，与字典序左部分为头的索引效果相似。因此，正确的设计能够使性能不会因为数据的增长而下降，例如，当数据从10条增加到1000万条时，系统仍旧可以保持相同的读写性能【只限少量数据的rowkey读写】。