为什么要使用两个（或更多）数据库而不是一个？答案

【问题标题】：Why would you use two (or more) databases instead of one?为什么要使用两个（或更多）数据库而不是一个？
【发布时间】：2011-03-09 09:24:45
【问题描述】：

许多数据库库为多个数据库连接设置 - 但我从未真正知道 脚本应用程序 需要在运行期间连接到两个数据库。（编译的、守护进程运行的语言是另一回事）。

我了解拥有数据库从属服务器以便您可以分散负载 - 但通常在启动时只选择其中一个来处理脚本需要。

那么为什么 PHP 或 Ruby 应用程序需要连接到多个数据库呢？ 或者更确切地说，为什么要将数据拆分到多个数据库中？

我唯一能想到的就是一个缓慢发展的系统的糟糕设计，该系统从多个独立的部分开始。

【问题讨论】：

因为数据是永恒的，而软件是不断被替换的。
简单使用示例：迁移到新系统 -> 新应用程序已经使用新环境投入生产，但仍需要旧数据库中的一些东西（因为没有时间写一些新后端的部分......或者我不知道......）。

标签： php database scripting

【解决方案1】：

您是在谈论“模式”意义上的不同物理数据库服务器还是不同的数据库？

关于物理服务器，如果您使用 MySQL 复制，您可能会写入主服务器并始终从从服务器读取。这有助于在每个数据库之间分配负载。

【讨论】：

呃，我忘了你不写信给奴隶！所有的写作都需要一个大师！

【解决方案2】：

我有一个连接两个数据库的站点。一个驱动网站内容 (CMS DB)，另一个驱动在网站内运行的 Web 应用程序（大量非 CMS 数据）。事实上，后者使用复制。

我不认为这是糟糕的设计。如果一组数据与另一组数据没有关系，那么即使从纯粹的组织角度来看，将其存放在单独的数据库中也是有意义的。否则，人们只会将所有表放在一个数据库中。

【讨论】：

【解决方案3】：

为了增加安全性，我总是为每个数据库创建两个帐户：一个只读帐户（适用于 SELECT）和一个读写帐户（用于 SELECT、UPDATE、INSERT、DELETE 和我可能需要的任何其他内容）。在某些页面上，我可能需要同时使用两个帐户，因此我将只为一个数据库使用两个连接。

【讨论】：

【解决方案4】：

我有一个连接到多个数据库的 Ruby 应用程序。一个数据库包含用户登录凭据（在其他几个项目之间共享）。另一个数据库包含我的应用程序跟踪和比较的存档数据（只有我的应用程序访问）。另一个数据库包含有关我的应用程序用来生成新数据的物理机器资源的数据（这些资源由几个不同的应用程序使用）。通过将数据拆分到多个数据库中，不同的应用程序只访问它们需要访问的数据。

【讨论】：

+1。这种技术的常用术语是 sharding 和 partitioning。大型应用程序不会将所有数据保存在单个数据库中。例如，如果你有 500 TB 的用户数据，你认为你会如何存储它？需要大量非常昂贵的硬件才能从单个数据库中访问所有内容。

【解决方案5】：

嗯，从一个读取并写入另一个是一个非常常见的用例。编写一个从一个连接读取（从从站读取）并写入另一个连接（主站）的数据访问层既简单又有趣。单个脚本可能会在写入之前进行多次读取——例如，可能需要进行一些查找以进行验证。

脚本语言也经常用于集成。您可能有两个现成的代码库，它们都想维护自己的数据库。您的集成代码可能想与他们两个对话。

一般来说，您通常可以设计出使用多个连接，但总的来说，我认为使用与多个数据库的连接没有任何根本性的问题。

【讨论】：

这个解决方案不仅有趣（嗯……根据我的经验，它与乐趣相反），它是扩展可扩展性的基本步骤之一。有很多方法可以扩展，但如果你从一个数据库开始处理一堆不同的需求，第一步是将不同类型的数据移动到单独的数据库中，在它们自己的数据库中隔离高读/写表。这之后的下一步通常是@timdev 概述的主从场景。两者都相当容易设置，绝对不是糟糕的设计。

【解决方案6】：

简单的答案是“可扩展性”。

许多数据库产品中复制和集群的现成可用性使得多个数据库的使用成为明确的“这必须是可能的”。任何体面的 ORM 都应该知道如何根据需要连接到多个数据库。

但即使主应用程序没有连接到多个应用程序，通常也会有其他需要这样做。报告生成，无论是脚本化的还是临时的，通常涉及运行很长时间的查询。这些最好在专门（和配置）这些查询的数据库副本上运行，这样它们就不会中断主应用程序。

另一个很好的用途是一种脚本处理。许多应用程序将有一个需要翻阅大部分数据库的常规过程。 Whislt 更新显然必须交给主服务器，大读取查询可以在副本服务器上运行。

当然，显而易见的需求是简单的性能。我监督了一个 web 应用程序和数据库，它从在一个 32 位双核机器上的一个 MySQL 数据库上舒适地生存发展为需要两个 8 核 64 位服务器和 8Gb。一旦达到这个阶段，它依赖数据库处理程序将流量引导到两个服务器。我们每天有一个大约 50 分钟的窗口，它可以只在一个数据库上存活。

【讨论】：

【解决方案7】：

您需要的某些数据经常存储在错误的数据库中。有时它是 PeopleSoft (Oracle) 数据库中的人事记录。也许是 Informix 上的企业 CRM 数据。或者一些存储在 MS SQL Server 中的部门数据库。不管它是什么，它在不同的数据库中，但你仍然需要访问（希望是只读的）。

除非您的主数据库是基于魔法的，否则它将无法为您提供对所有其他数据库的远程表访问。（大多数只会提供对相同类型的其他数据库的远程访问，例如：MySQL->MySQL。）当这种情况过于频繁发生时，您将别无选择，只能拥有多个数据库连接，并且很高兴您的框架支持它。

【讨论】：

【解决方案8】：

拥有多个数据库的其他原因。我们有一个每个人都可以访问的应用程序。我们还有客户数据库，这些数据库因客户而异。如果将特定于客户的数据分离到他们自己的数据库中，则维护所有客户使用的应用程序（并且由不同的团队维护）会更容易。当客户端成为大型企业客户端而不是运行在具有许多其他客户端的服务器上的较小客户端时，将客户端移动到新服务器也更容易。

此外，还有一些类型的事务性数据需要位于设置为具有完整事务日志记录的完整恢复模式的数据库中。其他数据仅从导入中填充，不需要事务日志记录，并且随着日志增长到足以处理 10,000,000 条记录导入，这可能会减慢系统速度。这些通常被拆分到单独的数据库中，因此它们可以处于简单恢复模式，因为如果出现问题，无需从事务日志中恢复数据，可以通过重新运行导入轻松恢复。

然后将数据拆分为数据仓库，这些数据仓库针对数据报告而非交易进行了优化。同样，这些报告数据库通常是独立的数据库（通常位于不同的服务器上）。

然后，您拥有多个不同 COTS 应用程序的数据库（我们有会计数据库、信用卡交易处理数据库、人力资源数据库、我们的项目管理数据库）。一个特定的网站可能需要访问其中一个以上的站点或将信息从一个站点传输到另一个站点。相信我，供应商不会让您将他们的数据库结构复制到一个数据库中来统治它们。

我们在许多不同的服务器上拥有数百个数据库。

【讨论】：