数据库计划 – 计划平台：一个数据库照旧多个数据库？

我们正在构建一个包括多个处事的Web平台,每个处事都有本身的底层数据.这些处事是凭证 Service-Oriented Architecture的原则独立构建的,但它们可以针对隐藏的相干数据举办买卖营业.我们正在思量这些处事是应该共享一个大型数据库照旧每个都有本身的数据库. (我们打算在Windows 2008聚集上行使SQL Server 2008 Enterprise.)

我们已经思量过的每种要领的一些利益包罗：

单个数据库

>关联来自差异处事的数据可以通过外键束缚绑定在一路
>说明提取更易于编写,执行速率更快
>假如产生劫难,将平台规复到同等状态会更轻易
>对付由多个处事引用的数据,一个处事缓存的数据很也许很快被另一个处事行使
>预先打点和监控更简朴,更自制

多个数据库

>维护事变,硬件题目,安详裂痕等不必然会影响整个平台
>假设每个数据库都在差异的硬件上,扩展多台计较机比扩展一台大型计较机发生更多的机能上风

从运营的角度来看,这个平台中的每个处事都有本身的数据库,可能它们都在统一个数据库中,这样更有利吗？哪些要害身分可以答复这个题目？

办理要领

在这种环境下,为每个处事疏散底层数据库是合乎逻辑的或必须的.可是,假如你有彼此依存的处事,那么从破碎中得到的对象很少(大概没有).

我提议阅读诸如HighScalability.com这样的网站,这些网站深入研究了永不失莠民型网站所回收的架构.我最近最喜好的一个是在Coding Horror上提到的Netflix Chaos Monkey的故事.

办理你题目中的几点：

In the event of a disaster,restoring the platform to a consistent
state is easier.

这是究竟,但你应该思量怎样更好地解耦这些处事,这样就不会成为题目.可能,有一些要领可以确保跨多个数据库的同步,譬喻transaction marks in SQL Server.

For data that is referenced by multiple services,data cached by one
service is likely to be used soon after by another service.

漫衍式缓存办理方案(memcached等)可以在这方面提供辅佐,可是你违背了处事独立性原则.这可以与两个处事直接彼此通讯,可能更糟糕的是具有处事会见和其他数据存储,完全绕过处事接口.不行停止地,数据将是相干的,而且将由挪用平台在处事之间转达,棘手的抉择倾向于环绕哪个处事将拥有哪些数据. StackOverflow或Programmers站点也许更得当辅佐办理更常见的SOA题目.

Assuming each database is on separate hardware,scaling up yields more
performance benefits.

虽然,超过多个较低规格的呆板扩展比扩展单个呆板更自制.尽量云云,当思量特殊开拓事变和操纵伟大性的软本钱时,较低的硬件本钱也许在总体拥有本钱中相形见绌.

假如这不是SOA,而且您只是由于后勤缘故起因而差异团队/供给商正在构建此平台的组件处事,请僵持行使单个数据库并完全忽略上述全部内容！

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!