最近IT圈有很多关于Non-SQL数据模型，放宽数据一致性，以换取高可伸缩性的讨论 。在美国旧金山近期就有这样的会议。

　　对各种模型进行了讨论，包括：Memcached、分布式Hashtable、Column-数据存储等数据访问模型。这些Non-SQL存储解决方案主要的侧重点在于高可伸缩性上，主要的特点是：

　　数据分布在大量服务器上

　　每台服务器独立运行 (例：最低限度的相互协作)。

　　有了这样的分布式环境，提供严密的数据整合是一个巨大的挑战，因此某种程度的一致性会有所丢失。 (但也取决于执行，丢失的东西是不一样的)。我严重怀疑这是否是可行的，添加到数据分区到传统的RDBMS，而不改变它的数据完整性的要求。

　　从数据访问模式的角度来看，memcache代表ad/hoc访问方式的结束，倾向于一个更小的数据子集，而且用户数据完全不可预测。这显示出对要求ACID原子操作的巨大挑战。当然，人们可以理论上可以让这些 Non-SQL 系统使用2PC，PAXOs 等事务处理协议，但没有人使用，因为它会很慢。当你正在使用Memcached，那么应用程序必须有一个相当宽松的数据一致性的要求。

　　从另外一方面来说，如果我们可以“限制”数据访问模型，那么我们可以建立一个高度专业化的数据布局与精密的执行计划，我们甚至可以消除并发的情况。根据这一办法将可实现非常高的可扩展性。 Map/Reduce是这一方法的典型例子。目前的挑战是需要 一个额外的算法转换步骤以重新部署应用到有限的MapReduce模型。

　　不过，我认为比较不同的数据库模型而不关注不同层面(比如线程)，是没有多大意义的。

　　什么是数据访问模式

　　Batch-oriented，要求扫描整个数据集(比如Map/Reduce 类型)

　　Ad/hoc， 小的、未知数据子集的访问不可预测性(使用当前访问)

　　一个集合内基于key-based 查找

　　一个集合内基于Value-based 查找(作为布尔表达式的标准)

　　标准如何定义 (等于、多于/少于、前缀匹配、相似性匹配)

　　内部/外部加入横跨多个集合

　　在数据的“结构布局“和相应指标起着很大的作用。

　　key/value 存储

　　Relational 存储

　　Column-oriented 存储

　　什么是数据一致性要求

　　每个人任何时候必须能够随时看到更新的信息

　　可以看过时信息，只要每个人都能看到同样的图片。

　　可以看过时信息，如果过时程度有时间限制(最新20分钟内)

　　“数据更新”机构扮演重要角色。

　　隔离机制 (LOCK, MVCC)

　　更新协作机制(2PC, PAXOS, Async Gossip)

　　需要更多的研究，权衡各种决策，以及它如何影响可伸缩性。这将需要一段时间让该行业找到各种应用类型的最佳模式。