2

我正在设计一个系统,该系统将用于为全国多个生产站点提供数据(所有信息都在一个站点中),并有可能添加更多。最初我认为我可以只使用一个数据库就可以逃脱。我现在正在重新考虑我的原始设计并倾向于一个更具可扩展性的解决方案。保持每个数据库/表的大小也很重要。

将有一个“主”数据库,其中包含跨越站点概念的信息,然后为每个站点创建一个单独的数据库,其中包含特定于站点的信息。

我的斗争是在哪里分离数据。这些数据都是相当相关的。无论我在哪里做,我都会失去一些参照完整性。我读到的所有内容都说要不惜一切代价避免这种情况,因为我认为这是非常好的理由,但我看不到解决办法。

我已经研究过触发器,但如果数据库位于不同的服务器上,我认为它们不会起作用(虽然不确定——我认为 Oracle 会这样做)。我仅限于开源解决方案,因此如果有帮助的话,它将是 MySQL 或 postgre。

有没有人有一些建议来缓解这个问题或有其他设计建议?

4

5 回答 5

1

在不了解您的具体情况的情况下,有点难以提供帮助 - 但这是我的直觉......

我猜你建议的信息应该放在你的“主”数据库中,可能比每个站点的数据库更稳定(对数据的更改次数很少)。

也许您可以查看一个解决方案,其中“主”数据库中的数据也存储在每个站点的数据库中。然后,您可以查看某种复制系统,以将对主数据库所做的更改传播到站点数据库。

这样,您仍然可以在每个站点的数据库中维护参照完整性。

于 2008-10-21T23:44:09.897 回答
0

MySQL 有联合表,但尚不清楚外键约束是否会在它们之间起作用。我有点怀疑——但应该触发。

否则,您必须将参照完整性上移一层 - 进入应用程序。

于 2008-10-21T23:37:54.560 回答
0

你在说多少数据?你真的需要这种架构吗?数据库可以驱动大量容量。

“不要这样做”的警告来自艰难而痛苦的经历。分布式数据集的维护和管理真的很痛苦。所以,认真考虑一下。

也许考虑将数据分解为运营存储与报告存储或数据仓库,您可以每晚或每周提供它们(取决于您需要分析报告的最新程度)。许多运营数据存储不需要那么大。

关于仅在后端维护的表(例如,出于数据完整性目的)与那些经常由用户更新和添加的操作表,这也是一个不同的问题。可以认为更“静态”的表 - 只是静态的。如有必要,有一个可靠的过程可以在您的节点上更新它们,理想情况下,很少。

一旦您的数据分解到“动态”与“静态”表中,分区会更容易一些,因为您的静态数据可以根据需要进行单一主控和复制(从根实例),而分区存储是真实数据的单一来源用于为后端数据仓库和报告系统提供数据。然后几乎不需要实际的复制,而是更多的“它在哪台机器上”的问题,可以很容易地自动化。

于 2008-10-21T23:54:42.280 回答
0

如果正确理解您,您是否希望(也许)使用触发器来检查每次插入/更新/删除是否将参照完整性保留在远程数据库上?

如果是这样,我认为您应该避开这一点,我只是认为性能开销太大了。特别是如果您希望解决方案具有可扩展性。

我会担心数据是如何插入的,并且对此非常严格,您的应用程序逻辑应该涵盖这是一个高级别的细节。您可以运行每周报告以查看哪些数据不正确并查看其插入错误的原因等,但我认为如果您的应用程序正确完成,多数据库引用完整性将难以实施。

但不要误会我的意思,我 100% 保证数据处于稳定、稳健的状态,但有时这并不总是可执行的。

但正如前面所说,如果没有关于解决方案的更多信息,很难给出建议...... :)

于 2008-10-22T00:11:08.440 回答
0

让我看看我是否可以为问题域提供更好的概要:

希望创建一个“企业”解决方案,其中有 n 个生产站点,其中 n 将增加。

我们处理数据以创建 Web 和打印文档。

系统将管理流程以将数据文件从提交(通过集中式网站)到打印机或网络或两者兼而有之。

每个生产站点都有自己的客户等。所有这些信息都将存储在数据库中。该信息的大部分管理将在中心站点进行

由于我们使用的软件的许可限制,我们在一台服务器上处理所有数据。

所以会有一个守护进程查看队列(在数据库中)并处理作业。流将由数据库中的状态列控制,以便其他进程知道它在进程中的位置。

大量数据来自我们的网络工具。我们需要为我们为网络生成的每个文档存储搜索索引。这变得相当大相当快。这些记录不会永远保留,但至少在大多数情况下会很大(估计有 5 亿行)。

我认为摆脱表大小问题单独的数据库可能是答案以及在不同服务器上分离生产站点的能力。

问题是我不知道何时会收购另一个站点或它将有多大。

我想我想将可扩展性的东西扼杀在萌芽状态,而不是在一年后获得一个将我们推向边缘的网站,而不必购买更好的服务器来容纳这个怪物。不幸的是,金钱是一个对象。

如果增长不是未知数,我什至不会考虑数据库。

我还考虑过为每个站点完全创建单独的数据库。这使得我们的应用程序的管理以及其他问题变得更加困难。

我为漫不经心的回应道歉。这是一个12小时的一天。我真的可以永远继续下去,但希望无论如何都能提供更多的见解。

与一个数据库的示例关系

网站有很多客户 客户有很多提交者 提交者有很多提交 提交有很多文档 文档有很多索引

所以我可以通过连接轻松计算客户的文档数量

于 2008-10-22T00:40:58.800 回答