Database 系统设计：多个数据库客户端或代理，较少的数据库连接

假设我有一个系统，其中大约1000台机器将从一个传感器生成数据，它们必须将数据发送到一个中央系统，并将数据存储在一个SQL表中

我的问题是，通常最好让每个系统直接连接到数据库并插入（这是唯一需要的操作）数据，或者使用消息服务器（如HornetQ）将数据发送到服务器，并使用一个（或几个）软件实例从HornetQ消费数据并将其写入数据库系统

我想知道这两种方法在CPU/内存成本和可伸缩性方面的比较，特别是在系统的服务器端（即，数据库系统设计用于处理大量客户端）。

我们有一个和你们差不多的系统

我们有数百个数据生产者。 我们正在和这么多的作者一起将这些数据写入mysql数据库

在任何情况下，为数据库提供1000个并发编写器客户端都不是一个好主意。根据我的经验，我绝对建议您在您的案例中使用消息队列。它将是数据生产者和消费者之间的缓冲区。所以，如果您的数据库方面出现任何问题——相信我，一定会有问题的——您不必在生产商方面对此一无所知。您可以在不接触生产商的情况下停止您的消费者、进行维护和修复等

关于消费者数量，完全取决于您和您的系统要求。您可以根据需要使用一个或多个使用者

这里有两个问题。如果您需要写入太多的数据意味着您需要写入可伸缩性，那么您可能需要使用分片，但正如我所说的，它与您需要的数据大小和事务数量有关。

---

您可能还需要注意一些事项，如不使用自动增量id字段等。

在这两者之间使用消息队列的优点是：

• 能够增加生成消息的机器的数量，更不用说扩展数据库服务器了
• 控制队列消耗以保持数据库健康
• 在数据库维护或崩溃的情况下，您的计算机数据不会丢失

---

我不想说得太详细，还有其他好处，但我想你已经了解了。

你有没有任何支持这一点的参考资料？->“在任何世界上，为数据库提供1000个并发编写器客户端都不是一个好主意。”，在这种情况下，自动递增字段有什么问题？在一天结束时，您将写入磁盘。我不确定应该写入多少数据，但每个写入程序至少要等待磁盘io完成写入操作。由于1K数据库连接等原因，也会产生开销。如果您尝试插入到具有1000个并发线程的同一个表中，每个线程都应该等待获得自动递增的id，并且在数据库端AFAIK上有某种互斥来防止id重复。