由于允许和单一系统的特征，数据库和内部企业系统的扩展成本会很高。因此，我们希望它们能专注于执行特定的义务。就数据库而言，我们希望它们能够专注于事务而不是产物智能。就后台办公系统(商业智能)而言，我们不希望产物与系统的扩展能力联系在一起。对于营业系统的数据，接纳异步传输模式。
我们经常告诉客户，要制止在关系数据库中使用存储历程。他们的第一反映通常是:“你们为什么这么憎恶存储历程呢?”实在我们并不憎恶存储历程，我们在许多情形下也在用它们。但问题在于，存储历程经常在解决方案中被过分使用，而这种过分使用有时会造成系统中的扩展瓶。既然这个原则强调的是数据库方面的问题，那为什么不把这个原则放在数据库那章中呢?事实上我们关注存储历程的真正缘故原由是，我们主张把商业智能和产物智能与事务处置区离开来。一般说来，这个主张可以进一步归纳综合为“把相似的事务放在一起(或者说把差别的事务离开)以获取最大的可用性和可扩展性以及最低的成本”。这样的表述可能不太好明白，因此让我们仍以存储历程和数据库为例，说明为什么需要这种区分。
在你的架构中、数据库可能是最贵的系统或服务之一。纵然接纳的是开源数据库，这些系统所在的服务器也可能会连接到成本相对较高的存储解决方案(相对于你其他的解决方案而言)，它们具有最快、最大数目的处置器以及最大数目的内存。在成熟的环境中中，这些系统通常都被用于做一件事情、即执行关系操作，并把事务尽可能快地提交给稳固的存储引。这些系统上的每个盘算周期的成本都比架构中的其他解决方案或服务(如应用服务器或web服务器)要高。这些系统是某些服务的汇集点、也是泳道的界说点。在极端情形下，如在架构的初期，这些系统所占的比例可能更为伟大的，那么它们显然是影响整个环境的扩展的决定性因素。
出于以上这些缘故原由，把这种昂贵的盘算资源用于营业逻辑几乎是毫无意义的。这时每个事务所花的成本会增添，由于处置这些事务的系统的操作成本更为昂贵了。同日时这个系统自己也可能是影响我们扩展的决定性因素，那么为什么我们还要虚耗生产力在它上面运行与事务处置不相关的操作呢?因此，我们应该让这些系统只处置与数据库(或相关的存储或 NOSQL)相关的事务，以便让它们做自己最善于的事情。这样我们不仅提高了可扩展性，还能削减扩展成本。
(责任编辑：网络)
评论列表