维度

数据类型:
    数据有多种存储的方式,包括建\值对(类似于 HashMap)半结构化的列式存储和文档结构存储,用户的应用如何存储数据?同事数据模式是否随着时间而变化?

存储类型

内存还是持久化?  主要的原因是,我们可以将其与RDBMS进行对比,他们通常持久化存储数据到磁盘中,即使需要的是存粹的内存模式,也仍旧有其他方案,一旦考虑持久化存储,就需要考虑选择的方案是否会影响到访问模式

一致性模式

严格一致性还是最终一致性?  问题是存储系统如何实现它的目标.必须降低一致性要求? 在特定的场景中会产生巨大的影响. 因为一致性可能会影响到操作延时.即系统响应读写请求的速度.这需要权衡投入和产出后得到一个这种结果.

物理模式

分布式模式还是单机模式. 这种架构看起来想什么? 是仅仅运行在单个机器上 ? 还是分布在多台机器上, 但分布及扩展规则由客户端管理. 换句话说,由用户自己的代码管理. 也许分布式模式仅仅是个事后的工作, 并且只会在用户需要扩展系统时产生问题 如果系统提供一定的扩展性,并且设置好分区(这点对于不支持虚拟分区的系统非常重要),设置时需要考虑同时提高每个分区的处理能力,因为系统的每个部分都需要提供均衡的性能,

读\写性能

用户必须了解自己的应用程序的访问模式,是读多写少?还是读写相当? 或者是写多读少? 是用范围扫描数据好,还是随机读请求数据更好?有些系统仅仅对这些情况中的一种支持得非常好,有些系统则对各种情况都提供了很好得支持

辅助索引

辅助索引支持用户按不同得字段和排序方式来访问表.这个维度 覆盖了某些完全没有辅助索引支持且不保证数据排序得系统(类似于HashMap , 用户需要知道数据对应建得值),到某些可能通过外部手段简单支持这些功能得系统.如果存储系统不提供这项功能,用户得应用可以应对或自己模拟辅助索引?

故障处理

机器会崩溃是一个客观存在得问题.需要有一套数据迁移方案来应对这种情况.每个数据存储如何进行服务器故障处理. 故障处理完毕之后是否可以正常工作, 这与"一致性模式"维度有关系.因为失去一台服务器可能会造成数据存储的空洞,甚至使整个数据存储不可用.如果替换故障服务器,那么恢复100%服务的难度有点大..... 从一个正在提供服务的集群中卸载一台服务器时,也会遇到类似的问题

压缩

当用户需要存储TB级的数据时.尤其当这些数据差异性很小或由可读性文本组成时,压缩会带来非常好的效果.既能节省大量的原始数据存储,有些压缩算法可以将此类的数据压缩到原始文件大小的十分之一.

负载均衡

假如用户高读写吞吐率的需求.就要考虑配置一套能够随着负载变化自动均衡处理能力的系统.虽然这样不能完全解决该问题,但是也可以帮助用户设计高读写吞吐量的程序

原子操作的读-修改-写

RDBMS提供了很多这类的操作(因为它是一个集中式的面向单服务器的系统).但这些操作在分布式系统中较难实现,这些操作可以帮助用户避免多线程造成的资源竞争.也可以帮助用户完成无共享应用服务器的设计,有了这些比较并交换(CAS)操作.或者说检查并设置操作.在设计系统的时候可以有效的降低客户端的复杂度.

加锁\等待\死锁

复杂的事物处理,如两阶段提交,会增加多个客户端竞争同一个资源的可能性.最糟糕的情况就是思索,这种情况也很难解决.用户需要支持的系统采用哪种锁模式,能否避免等待和死锁..