数据库设计 – 设计平台：一个数据库还是多个数据库？

我们正在构建一个包含多个服务的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,并且您只是因为后勤原因而不同团队/供应商正在构建此平台的组件服务,请坚持使用单个数据库并完全忽略上述所有内容！

（编辑：常州站长网）

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