第三阶段：利用垂直分割提高数据库的性能。

虽然企业现在的数据库架构，暂时还可以满足用户性能上的需求。但是企业已经意识到，现在这种架构不会存在很久。因为现在用户的数量与信息流量都在急剧增加。主数据库服务器的负荷快要达到预计的警戒点了。现在企业技术人员已经在设计、部署新一轮的数据库升级方案了。按照技术人员的思路，这次想通过垂直分割地防范来改善主数据库服务的性能。也就是说，按照目前的应用情况，将SaaS应用的所有业务都放在一台主数据库上去进行数据更新，对于主数据库服务器的压力比较大。由于数据更新量实在太大，通过硬件升级、查询与更新数据分流等手段效果已经不是很明显。技术人员想用过垂直分割的手段，将不同的业务流量分割到不同的数据库服务器中去。即将BBS业务、OA业务、项目管理业务分别部署到三台主服务器上，而辅助服务器暂时保留原有的数量。如此通过WEB应用程序的引导，用户需要访问某个应用的话(需要对这个应用的数据进行更新操作)，WEB应用程序就会自动将其引导到合适的主服务器中去。而辅助服务器的话，仍然担任着数据查询的角色。此时由于各个主服务器之间负责各自独立的业务，所以彼此之间也不需要很严格的数据同步。即只需要实现主服务器与辅助服务器之间的数据同步即可。

第四阶段：备用解决方案。

如果后续随着用户数量的增加与业务种类的增加，上面这个解决方案还不能够满足用户访问需求的话，技术人员还涉及了一个备用的解决方案。这个备用解决方案是在上面这个解决方案的基础上，通过添加同一个业务的主服务器数量来提高SaaS应用服务的性能。或者说，更进一步的解决方案，就是实现数据库的分布式方案。毕竟当用户多了、SaaS业务多了，需要实现在各个业务之间进行统一的身份认证。即凭借一个用户名与密码就可以访问各个SaaS应用服务。现在很多大型的WEB应用，如sina等网站，在后台都实现了分布式的数据库服务架构，通过提高数据查询与更新的效率来提高SaaS应用程序的性能。

如果用户与业务数量再增加，这个分布式数据库方案还不能够解决问题的话，那么就需要在数据存储、云计算等方面努力了。不过一般来说，只要用户数量在500万以下的SaaS的应用，一般以上几个解决方案就可以了。最后笔者要强调的是，虽然从成本、风险等角度考虑，根据用户的数量与业务的种类一步步的进行数据库解决方案的升级是可行的。因为现在向SQL Server或者Oracle等数据库都集成了相关的解决方案。升级是比较简单的，风险也不是很大。但是在系统规划的时候，还是需要考虑未来业务与用户数量的增长。在成本允许的情况下，尽量采取性能比较高的解决方案。也就是说，如上的各个阶段企业不用一步步来。只要资金充裕，并对未来的应用前景比较有信心的话，可以一步到位。毕竟在升级的过程中，无论规划的多好，都会出现短暂的停机现象。