大型数据库要求使用并行计算资源来实现良好的性能。目前我们使用的有几个截然不同的并行体系结构；在本贴中，Dave DeWitt、Mike Stonebraker、和我回顾这三种方法，并对每种方法都进行了正反两方面的评价。尽管在二十年前研究机构就已经阐述了这三种方法的利弊权衡，不过我们希望在发表讨论并行数据库设计发展的新贴之前，让读者温故知新，加强对这些问题的理解。
当共享总线成为瓶颈时，共享内存系统的伸缩性不佳
在共享内存方法中，由于在很多对称多处理器计算机上执行，因此所有的 CPU 共享一个内存和唯一磁盘集合。相对来说，这种方法较易于实现。不需要复杂的分布式锁定和提交协议，因为锁管理器和缓冲池都储存在内存系统中，所有的处理器都可以很容易地访问它们。
遗憾的是，共享存储系统存在重大的可伸缩性局限，因为所有的 I/O 和内存请求都必须通过所有处理器共享的同一总线进行传输。这使得总线的带宽很快便成为瓶颈。此外，共享内存多处理器需要复杂的自定义硬件以保证L2 数据高速缓存的一致性。因此，很少看到有超过 8 或 16 个处理器的共享内存计算机，除非它们是按客户要求定制的非商品组件（如果它们是定制的，那么价格将非常昂贵）。因此，共享内存系统的可扩展性并不好。
共享磁盘系统的可扩展性也不理想
共享磁盘系统也有同样的可伸缩性限制。共享磁盘体系结构有很多独立的处理器节点，每个都带有自己的内存。通常，利用存储区域网络 (SAN) 系统或附加网络存储 (NAS) 系统的形式，所有这些节点访问唯一磁盘集合。这种体系结构起源于DEC (Digital Equipment Corporation)二十世纪 80 年代初的 VAXcluster，后来得到 Sun Microsystems 和 Hewlett-Packard 公司的广泛应用。
共享磁盘体系结构存在一些不足，严重限制了其可扩展性。首先，将每台计算机的 CPU 连接到共享磁盘子系统的互连网络可能成为 I/O 瓶颈。其次，因为没有供所有处理器共享的内存池，所以也没有统一的空间来保留锁定表或缓冲池。要设置锁，要么必须在一个处理器上集中锁管理器，要么使用复杂的分布式锁定协议。该协议必须在软件中使用消息来实现高速缓存一致性协议，其与共享内存多处理器在硬件中实现的类似。在进行系统扩展时，这两种锁定的方法都有可能成为瓶颈。
为了使共享磁盘技术能够更好地发挥作用，供应商通常要实施一种叫“共享高速缓存”设计。共享高速缓存与共享磁盘非常相似，不同之处是当并行集群中的一个节点需要访问磁盘页时，它首先要确定该页是否在其本地的缓冲池（“高速缓存”）中。如果不在，它需要确定该页是否在集群中其它节点的高速缓存里。如果都没有，则从磁盘上读取该页。
这种高速缓存似乎在 OLTP 上运行得相当好，但是它在处理数据仓库的工作负荷时不是很理想。共享高速缓存设计的问题在于缓存命中不太可能发生，因为数据仓库的查询通常使用顺序扫描事实表（或通过物化视图）的方法来解决。除非整个事实表已在集群的聚集内存中，否则顺序扫描一般不会受益于大高速缓存。因此，应答这类查询的所有工作负荷都落在磁盘子系统上。结果，共享高速缓存只是产生了额外的开销并限制了可扩展性。
此外，共享内存模型中存在的可扩展性问题也同样存在于共享磁盘体系结构中。磁盘和处理器之间的总线将可能成为瓶颈，尤其随着 CPU 数量的增加，对某个磁盘块的资源冲突也成为一个问题。为了减少总线冲突，客户经常利用许多光纤通道控制器（磁盘总线）来配置他们的大型集群，但是，这使系统设计变得更加复杂，因为管理员现在必须将数据分区保存到附加着不同控制器的磁盘上。
零共享方案的可扩展性能最好
相比之下，在零共享方案中，每个处理器都有其自己一套磁盘。数据可以在各节点之间进行“水平分区”。在数据库中，每个节点都有每个表的行子集。然后，每个节点只负责处理自己磁盘上的行。这种体系结构特别适合于数据仓库工作负荷中出现的星型查询，因为只需要数量非常有限的通信带宽就可以连接一个或多个（通常很小的）维表和（通常比较大的）事实表。
此外，每个节点都维护自己的锁表和缓冲池，避免了需要复杂锁定和软硬件一致性的机制。因为零共享方案一般没有和共享存储或共享磁盘计算机那样严重的总线或资源冲突，所以该方案可以用来扩展到数百台甚至数千台计算机。因此，它通常被看作是具有最佳可扩展性的体系结构。
零共享方案完善了其它增强功能
最后一点，我们注意到，零共享方案与我们在本博客中已经讨论的其它高级数据库技术（如压缩和垂直分区）是完全兼容的。与比较传统的体系结构相比较，综合了所有这些技术的系统可能会提供最好的性能和可扩展性。
1163
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
