在NoSQL存储系统选型中，有很多的维度可以区分系统给的特定优势所在，这里挑选几种维度介绍，注意不全面，也不是唯一的区分方式。没有哪种方案能够完 美的解决问题，重要的是正确的评估需求，然后做出明智的选择，有需要的话甚至可以采用混合使用的方案。对于一个问题，我们只有知道了有哪些可用的解决方 案，然后才能找到最合适解决该问题的方案。
1、数据模型
数据有多种存储的方式，包括键/值对（类似HashMap），半结构化的列式存储和文档结构存储。用户的应用如何存储数据？同时数据模式是否随着时间而变化？
2、存储模型
内存还是持久化？一旦考虑持久化存储，就需要考虑选择的方案是否会影响到访问模式。
3、一致性模型
严格一致性，还是最终一致性？一致性可能会影响操作延时，即系统响应读写请求的速度。
4、物理模型
分布式模式还是单机模式？系统的扩展性如何？
5、读/写性能
需要考虑自己的应用程序的访问模式，是读多写少，还是读写相当，或者写多读少？是用范围扫描数据好，还是用随机读请求数据更好？有些系统可能仅对这些情况中的一种支持的好。
6、辅助索引
辅助索引支持用户按不同的字段和排序方式来访问表。这个维度覆盖了某些完全没有辅助索引支持且不保证数据排序的系统（类似HashMap，即用户需要知道 数据对应键的值），到某些可能通过外部手段简单支持这些功能的系统。如果存储系统不提供这项功能，用户的应用可以应对或自己模拟辅助索引吗？
7、故障处理
机器会崩溃是一个客观存在的问题，需要有一套数据迁移方案来应对这种情况。每个数据存储如何进行服务故障处理？故障处理完毕之后是否可以正常工作？从一个正在提供服务的集群中卸载一台服务器时，也会遇到类似的问题。
8、压缩
需要存储TB级的数据时，尤其当这些数据差异性很小或由可读性文本组成时，压缩会带来非常好的效果。有些压缩算法可以将此类数据压缩到原始文件大小的十分之一。有可选择的压缩组件吗？又有哪些压缩算法可用？
9、负载均衡
加入用户有高读写吞吐率的需求，就要考虑配置一套能够随着负载变化自动均衡处理能力的系统。虽然这样不能完全解决这个问题，但是也可以帮助用户设计高读写吞吐量的程序。
10、原子操作的读-修改-写
RDBMS提供了很多这类的操作（因为它是一个集中式的面向单服务器的系统），但这些操作在分布式系统中较难实现，这些操作可以帮助用户避免多线程造成的资源竞争，也可以帮助用户完成无共享应用服务器的设计。有了这些比较并交换（compare and swap，CAS）操作，或者说检查并设置（check and set）操作，在设计系统的时候可以有效地降低客户端的复杂度。
11、加锁、等待和死锁
复杂的事务处理，如两阶段提交，会增加多个客户端竞争同一个资源的可能性。最糟糕的情况就是死锁，这种情况也很难解决。用户需要支持的系统采用哪种锁模型？这种锁模型能否避免等待和死锁？
转载请注明：爱开源 » 存储系统选型中考虑的维度