浅谈系统架构级的数据库性能提升方案

 

数据库性能的提升最常采用的手段是纵向提升，即通过更换更强大的数据库服务器来增强服务器的处理能力。

而横向提升是比较困难的。在Web服务器解决方案领域经常采用的动态负载均衡的横向可扩展架构一般来讲是不适合于数据库应用的。原因主要是由于数据库本身的复杂性造成的。负载均衡所依赖的前提是：两个请求之间没有内在的联系；就算有内在联系，为使这种联系在不同的服务器上能够一致地处理所需要保存的状态信息是非常少的。这在Web服务器所处理的逻辑上是没有问题的。而对于数据库服务，前后两个请求之间的联系是非常多且非常复杂的。一个请求的结果很可能受另一个请求的处理结果的影响（只需要考虑读写同一个表的两个不同的请求就很容易理解了）。在这种情况下，可以说几乎整个数据库所存储的数据就是需要保持的状态数据。而要在两个数据库的不同存储间保持一致几乎是不可能的。

另外，采用共享存储阵列的解决方案也无法适用于动态负载均衡。因为作为前面所提到的状态的集合不仅仅是外部存储设备上的数据，还包括内存中的数据，因为数据库引擎在处理过程中大量用到了在内存中的缓存处理。如果要共享这一部分状态信息则需要共享内存资源，而这种方法只在大型矩阵超级计算机中才能够见到，因为硬件成本极其高昂，需要快速内存共享交叉开关这种成本极高、应用面极窄的硬件设备。

（注意，经常在数据库服务器物理部署上所采用的共享磁盘阵列多机备份或群集方案是为了解决高可用性而采取的技术，不属于性能提升范畴。）

实际上，广为应用的SMP多处理机服务器其实就是这样一种共享除CPU之外所有硬件资源的解决方案。它能够完整地在两个处理器间保持状态信息的一致性。但这种方式习惯上被归结为纵向性能提升（因为是通过更换处理能力更强，包含CPU数量更多的服务器硬件来完成的）。

通过创建合适的索引，分散表空间等数据库技术的手段不属于我们在这里所探讨的系统架构级的性能提升方案。所以这里就不过多说明了。

之所以动态负载均衡无法解决横向性能提升问题，其根源在于动态负载均衡机制对于数据应用的逻辑一无所知，因而无法正确做出分担负载的决策。而横向性能提升仍然要在减少应用请求对单一服务器的压力方面想办法。因此，静态的负载均衡在这里恰恰是可以采用的手段。

我们可以将不同业务领域的数据分别用不同的数据库服务器来承担，这样就从根本上减少了对单台服务器的访问压力。但这需要软件的配合，尤其是应用软件需要有能力根据业务处理的不同领域来使用不同的数据库服务器。而且，这种能力应当是通过调整配置来解决的。这就需要应用软件有检测配置修改和平滑迁移数据访问流量的能力。

事实上，这种平滑迁移数据访问流量的逻辑是极其复杂的，以至于一般的应用软件没有能力或不值得提供这种能力。在不间断提供处理能力的前提下，应用新的配置分散流量是极其困难的，以至于实现成本高得吓人。所以一般的解决方案是在经过测试验证的前提下，在对业务影响最小的可控的时间段内引入系统维护间歇。在此间歇内，系统将停止对相关业务的服务，将相关数据从原有服务器上同步至新服务器上面，然后调整配置重新开启系统服务。

毫无疑问，这种方式必然造成业务的暂时中断。为使这种暂时中断在可控的范围内完成，就需要做好计划和测试工作，还要准备好应急方案和数据备份，以防止万一发生任何问题，系统还能够在原先的配置情况下继续运行。其重点是安排合理的操作规程，并严格按照规程操作。