5

我有这种情况：

您有一条 24/7 运行的工厂生产线。停机时间非常昂贵。控制所有不同部分的软件必须使用数据库存储的共享形式。这样做的主要原因是要知道工厂处于哪种状态。例如，某些产品在使用同一组设备时可以混合使用，而其他产品则绝对不能。

要求：

  • 我希望软件能够检测到工厂某一部分的错误必须导致 1 公里以外的某些机器停机。所以在PLC中存储数据不是一种选择。
  • 工厂环境更新升级频繁
  • 负载（在计算机方面）将非常低。

系统每天处理数百个任务，这些任务完成计算/检查，然后向工厂机器发送指令。系统大部分时间都会感到无聊。最重要的要求是中央计算机系统必须正确并始终工作。

我正在考虑使用基于发电机的数据库（riak 或 cassandra），其中数据被写入多台机器，每台机器都有整个数据库

当一个系统出现故障时，它会在不知不觉中下降。当表发生变化并且这个主从更难以配置时，传统的 sql 数据库可能更难以升级。

你的解决方案是什么？

网络已变得冗余，并且大多数其他单点故障。数据库系统至关重要，因为数据库的停机时间意味着整个工厂的停机时间，而不仅仅是一台可以接受的机器。

  • 如何解决共享状态问题。
  • 数据库的复杂性不会成为问题。我将更像一个简单的键值存储来获取最新和正确的数据。
4

3 回答 3

3

我不认为这是一个 sql/nosql 问题。所有 Postgres、MySQL 和 MS SQL Server 都有某种集群或热备用选项。

配置是一次性的事情，但是如果你试图在一个为了运行而放弃关系的平台上做一些根本上是关系的事情，任何 NoSQL 选项都会让你从上到下的代码头疼像亚马逊或 Facebook。配置一次，编码永远。

所以我会说坚持使用经过验证的真实解决方案并进行热复制。

这也为升级提供了解决方案。典型的顺序是“故障转移”到备用服务器，升级主服务器，翻转回主服务器，升级备用服务器，然后恢复。当然有具体情况的细节。

于 2011-01-19T23:24:40.957 回答
2

使用已建立的原生支持此类事物的 RDBMS

您真的想在任何时间点都可能保持一致的东西上运行一个 24/7 的关键任务系统吗？

于 2011-01-22T08:33:08.797 回答
1

您需要避免单点故障。

我们 dbms 世界中的所有主要参与者都提供了至少一种方法来避免使数据库本身成为单点故障。我可能会质疑他们是否可以足够快地为您的制造过程传播更改。（或者数据更新不是真正的问题？不能从你的问题中真正看出。）我在制造业的数据库工作仅限于汽车和化学工业。微秒对他们来说并不重要。

但 dbms 并不是唯一可能失败的东西。“一直在工作”意味着客户也必须一直在工作。客户端硬件、网络连接、网络和网络服务器本身都可能存在单点故障。容错服务器具有多个电源、多个 NIC 等。

“一直工作”真的很贵。我感觉数据库不会成为贵公司最大的问题。

于 2011-01-22T13:32:29.257 回答