有一天我正在听Hanselminutes，这个问题出现了。 在什么情况下应该从代码中分离数据？ 例如，我在DB上工作的一个系统与服务器上的Web内容在同一个框中。 在另一种情况下，我们把他们分开。 哪一个更好，为什么你觉得这样？
我个人认为，如果你负担得起，分离是好的。
数据更好的保护免受入侵者的侵害。 分离允许更好的故障转移控制。 分离使您能够更好地pipe理和负载均衡stream量。
这确实成了一个问题，就是数据访问时间。 当两者都在一起时，盒子上的延迟显着减less，而networking上则显着减less。
你在想什么？
有几个原因可以考虑分离数据库和Web服务器，有些会回应已经提到的内容。
首先，这是潜在的性能问题。 通常，数据库服务器喜欢内存。 可以分配给caching数据的内存越多，从磁盘读取所需的访问就越less。 所以记忆有一个好处。 因此，您可能在Web服务器和数据库服务器之间存在内存争用问题。 就这点而言，数据库服务器与Web服务器在同一个服务器上运行的情况很多，例如MySQL或SQL Server Express，甚至SQL Server 2005报告服务的全面SQL Server。
其次，您的应用程序可能会使用一些而不是全部数据。 如果内部系统也触及数据库，情况尤其如此。 这不是在一个虚拟主机环境，我猜你正在寻找基于您的标签的可能情况。 但是在这种情况下，您可以将Web服务器对数据库的访问权限限制在所需的范围内。 是的，如果Web服务器受到攻击，他们可以获得访问权限，但是如果这些权限是有限的，那么他们就无法获得所有的东西。 将其托pipe在同一个Web服务器上，这是一个完全不同的故事。
第三是因为通过使用IDS / IPS查看Web服务器和数据库服务器之间的networkingstream量，您可以了解您的Web服务器是否受到攻击。 例如，如果我们正在谈论SQL Server，并将xp_cmdshell发送到数据库服务器，或者sp_configure，那么应该告诉IDS / IPS一些事情已经结束。 这让你立即警告Web服务器已经被入侵。
四是职责分离。 如果您有负责部署Web应用程序的人员，他们可能需要升级Web服务器的权限才能这样做。 什么样的权利取决于你在做什么，什么操作系统，什么networking服务器等，但你明白了。 如果这些人不应该访问数据库服务器中的所有内容，并且数据库服务器的更新由不同的人员（如DBA）处理，则可以通过使用不同的服务器来更好地保护公司。
非常糟糕的主意至less。 我已经在同一台服务器上安装了Apache + MySQL之前进行了一次安装，它将定期超过10次平均负载，并且这些页面将永久加载。 我们拆分这两个服务，把MySQL放在一个更小的服务器上。 两台服务器永远不会超过负载平均值的0.35。
做math…将Web服务器+数据库服务器放在同一台服务器上会有很大的损失。
埃文也有一个好点。 把东西合并成一台机器往往会导致很多捷径，使得扩展困难得多。 一个服务=一个操作系统是一个好的经验法则（会说一个服务=一台机器，但现在有虚拟化）。
我想到的第一个想法是不要过度devise解决scheme。
把所有东西都放在一个盒子里是可以的。 全能的Stack Overflow也是这样开始的。
当你有足够的需求（和资源）来certificate多个盒子的时候，就这样做。 build立完美的设置不会在第一时间发生。
无论您如何设置快速恢复和恢复，都要保持出色的备份。 将数据库复制到异地，以便您可以在任何地方重build和恢复数据库（进入云，其他主机等）
祝你好运！
从安全的angular度来看，它应该在分离的盒子上。 但是，根据预算，应该是接受风险的商业决策。
这是为什么？ 首先，最佳做法build议：
如果您的数据库位于独立的机器上，则需要额外的步骤才能对其进行攻击。 如果你深入的跟踪防御，networking服务器将无法访问分贝框除了数据库以外的任何东西（所以，没有shell，没有运行脚本等）。 这就是为什么防火墙也适合内部控制的原因。
如果你的安全性确实很好，你的web-2-db用户将拥有db的最小权限，只能访问/修改他真正需要的东西（所以没有drop table等等）。 有趣的是，我们经常在数据库上看到GRANT *，对于只需要从几张表中select和更新的用户。
所以，只是因为很多人在一台机器上运行db + web服务器+邮件服务器+ DNS，并不意味着这是最好的安全决策，只是基于$$的公认风险。
需要注意的一件重要的事情是，当你从一台机器转到两台机器时，停机时间可能会加倍 – 也就是说，如果你的站点依赖数据库来运行。 如果正常运行时间对您来说很重要，您可能正在查看4个（或更多）服务器 – 然后您就是金牌。
我不认为你需要担心数据库与networking服务器通信的速度。 通过添加一台机器，您获得的CPU功率将加速数据库查询本身的速度，甚至在100Mb的服务器之间的传输应该可以忽略不计，相比之下，您可以在网上直播服务器的网页速度。
我不认为安全是一个单独的盒子好得多。 如果攻击者损害networking服务的框，那么无论如何，这可能会导致数据库崩溃。 故障转移和负载平衡/可伸缩性参数要好得多。
但是，如果你只有一个networking框，我一定会喜欢把数据放在同一个盒子里。
如果他们可以访问你的web机器，他们可以从你的configuration文件中获取数据库详细信息，加载一个php shell，并从那里转储数据。 一个安全优势是如果在同一台机器上有多个数据库。
但是，它可以让你分散负载，如果你需要这样做的performance，这是很好的，只要你有一个快速的连接，如上所述。
如果你担心冗余，那么把所有的数据放在一个盒子里，备份就好了。
我同意，如果可以提供，分离会更好。
如果这个盒子可以处理加载CPU / RAM的话，那么在同一个盒子上使用它们可能会更好，因为性能方面的原因是networking服务器和数据库服务器之间没有networking延迟。
我没有一个强烈的意见与其他方式。 但是，如果您打算“扩大规模”，则可以考虑使Web服务器尽可能无状态，以便在不重新devisedevise的情况下进行扩展。
如果您有一个相对静态的小型数据库，并且频繁访问，那么将其存储在与Web服务器相同的服务器上可能是有益的（因为您将利用内存中的数据高速caching）。 但是，对于其他任何场景，如果您可以为另一台服务器支付额外的$ 1-2K，则最好将这两个angular色分开。
我认为将数据库和Web服务器分离到不同的机器上可能会为入侵者增加另一层，但却非常薄弱。
如果您想以这种方式“入侵”入侵者，您可以在单独的机器上使用反向代理或Webcaching。 入侵者将转到这台机器，并将find没有数据以及如何到达数据库机器的详细信息。 只有Web服务器将被定义在反向代理服务器上，并且可以在服务于网页的端口之外被阻止。
安全性：代理服务器可以通过分离或伪装逆向代理背后的服务器types来提供额外的防护层。 这种configuration可能会保护链上的服务器 – 主要是通过混淆。