几个星期之前，我写了一篇文章描述了常被称作 NOsql 的一类新型数据库的背后驱动。几个星期之前，我在Qcon上发表了一个演讲，其中，我介绍了一个可伸缩（scalable）的 twitter 应用的构建模式，在我们的讨论中，一个显而易见的问题就是数据库的可扩展性问题。要解答这个问题，我试图寻找隐藏在各种 NOsql 之后的共有模式，并展示他们是如何解决数据库可扩展性问题的。在本文中，我将尽力勾勒出这些共有的原则。

假设失效是必然发生的

与我们先前通过昂贵硬件之类的手段尽力去避免失效的手段不同，NOsql实现都建立在硬盘、机器和网络都会失效这些假设之上。我们需要认定，我们不 能彻底阻止这些时效，相反，我们需要让我们的系统能够在即使非常极端的条件下也能应付这些失效。Amazon S3 就是这种设计的一个好例子。你可以在我最近的文章Why Existing Databases (RAC) are So Breakable! 中找到进一步描述。哪里，我介绍了一些来自Jason McHugh 的讲演的面向失效的架构设计的内容（Jason 是在 Amazon做 S3 相关工作的高级工程师）。

对数据进行分区

通过对数据进行分区，我们最小化了失效带来的影响，也将读写操作的负载分布到了不同的机器上。如果一个节点失效了，只有该节点上存储的数据受到影响，而不是全部数据。保存同一数据的多个副本.大部分 NOsql 实现都基于数据副本的热备份来保证连续的高可用性。一些实现提供了 API，可以控制副本的复制，也就是说，当你存储一个对象的时候，你可以在对象级指定你希望保存的副本数。在GigaSpaces，我们还可以立即复制一个新的副本到其他节点，甚至在必要时启动一台新机器。这让我们不比在每个节点上保存太多的数据副本，从而降低 总存储量以节约成本。你还可以控制副本复制是同步还是异步的，或者两者兼有。这决定了你的集群的一致性、可用性与性能三者。对于同步复制，可以牺牲性能保障一致性和可用 性（写操作之后的任意读操作都可以保证得到相同版本的数据，即使是发生失效也会如此）。而最为常见的 GigaSpaces 的配置是同步副本到被分界点，异步存储到后端存储。

动态伸缩

要掌控不断增长的数据，大部分 NOsql 实现提供了不停机或完全重新分区的扩展集群的方法。一个已知的处理这个问题的算法称为一致哈希。有很多种不同算法可以实现一致哈希。一个算法会在节点加入或失效时通知某一分区的邻居。仅有这些节点受到这一变化的影响，而不是整个集群。有一个协议用于掌控需要在原有集群和新节点之间重新分布的数据的变换区间。另一个（简单很多）的算法使用逻辑分区。在逻辑分区中，分区的数量是固定的，但分区在机器上的分布式动态的。于是，例如有两台机器和1000个逻辑 分区，那么每500个逻辑分区会放在一台机器上。当我们加入了第三台机器的时候，就成了每 333 个分区放在一台机器上了。因为逻辑分区是轻量级的（基于内存中的哈希表），分布这些逻辑分区非常容易。第二种方法的优势在于它是可预测并且一致的，而使用一致哈希方法，分区之间的重新分布可能并不平稳，当一个新节点加入网络时可能会消耗更长时间。一个用户在这时寻找正在转移的数据会得到一个异常。逻辑分区方法的缺点是可伸缩性受限于逻辑分区的数量。
更进一步的关于这一问题的讨论，建议阅读Ricky Ho 的文章NOsql Patterns 。

查询支持

在这个方面，不同的实现有相当本质的区别。不同实现的一个共性在于哈希表中的 key/value 匹配。一些市县提供了更高级的查询支持，比如面向文档的方法，其中数据以 blob 的方式存储，关联一个键值对属性列表。这种模型是一种无预定义结构的（schema-less）存储，给一个文档增加或删除属性非常容易，无需考虑文档结 构的演进。而 GigaSpaces 支持很多 sql 操作。如果 SQL查询没有指出特定的简直，那么这个查询就会被并行地 map 到所有的节点去，由客户端完成结果的汇聚。所有这些
都是发生在幕后的，用户代码无需关注这些。

出处不详