1

我很想听听一些关于 mysql 数据库设计的意见或想法。

基本上，我有一个 tomcat 服务器，它从现场大约 1000 个系统接收不同类型的数据。这些系统中的每一个都是独特的，并且将报告独特的数据。

发送的数据可以分为频繁数据和不频繁数据。不经常发送的数据每天只发送一次，变化不大 - 它基本上只是基于配置的数据。

频繁数据，系统开启时每 2-3 分钟发送一次。并表示系统的当前状态。

这些数据需要为每个系统建立数据库，并且可以在任何给定时间从 php 页面访问。基本上对于该领域的任何系统，PHP 页面都需要能够访问该客户端系统上的所有数据并显示它。换句话说，数据库需要显示系统的状态。

信息本身都是基于文本的，而且有很多。配置数据（变化不大）是键值对，目前大约有 100 个。

我的设计理念是拥有 100 多列，每个系统有 1 行来保存配置数据。但我担心有这么多列，主要是因为如果我将来需要添加列，这不是太面向未来。如果我这样做，我也担心插入速度。这可能会爆发到一个 2000 行 x 200 列的表，每秒访问大约 100 次，所以我需要在我的初始设计中满足这一点。

我还想知道，是否有任何设计理念可以满足基于引擎的频繁更改和很少更改的数据。这是有道理的，因为我想保持插入/更新时间较短，而且我不太关心 php 的 SELECT 时间。

我也很想知道如何拆分数据。即，如果可以以几种不同的方式对频繁更改的数据进行分类，我应该有一堆表，代表数据并在选择时加入它们吗？我对此很担心，因为我可能必须制作一份报告来显示所有系统之间的共同属性（即显示具有特定条件的所有系统）。

我希望我在这里提供了足够的信息，以便有人指出我正确的方向，任何关于此事的帮助都会很棒。或者，如果有人做过类似的事情并且可以提供建议，我将非常感激。谢谢大家:)

~ 丹

4

1 回答 1

4

我在评论中发布了一些问题。如果不了解您正在尝试做什么，就很难为您提供有关快速变化的数据的建议。

对于您的配置数据，不要使用包含 100 列的表格。众所周知，宽表在生产中难以处理。相反，请使用包含这些列的四列表：

SYSTEM_ID  VARCHAR    System identifier
POSTTIME   DATETIME   The time the information was posted
NAME       VARCHAR    The name of the parameter
VALUE      VARCHAR    The value of the parameter

这些列中的前三列是您的复合主键。

这种设计的优点是它会随着您添加（或减少）配置参数集而增长（或缩小）。它还允许存储历史数据。这意味着可以插入新数据点而不是更新数据点，这样更快。您可以运行每日或每周作业来删除您不再有兴趣保留的历史记录。

（如果您真的不需要历史记录，请编辑INSERT ON DUPLICATE KEY UPDATE，删除 POSTTIME 列并在发布内容时使用 MySQL 的不错的扩展功能。请参阅http://dev.mysql.com/doc/refman/5.0/en/insert-on -duplicate.html )

如果您快速变化的数据在形式（名称/值对）上与您的配置数据相似，您可以使用类似的模式来存储它。

您可能想为这些东西使用 MEMORY 访问方法创建一个“当前数据”表。MEMORY 表的读写速度非常快，因为数据都在 MySQL 服务器的 RAM 中。缺点是 MySQL 崩溃和重启会给你一个空表，之前的内容会丢失。（MySQL 服务器很少崩溃，但当它们崩溃时，它们会丢失 MEMORY 表的内容。）

如果您需要保存历史记录，您可以运行偶尔的作业（每隔几分钟或几小时）将 MEMORY 表的内容复制到磁盘表中。

（编辑：您将来可能会考虑将 memcached http://memcached.org/添加到您的 Web 应用程序系统中以处理高读取率，而不是为版本 1 构建处理高读取率的数据库设计。这样您可以查看您的整体应用程序设计的哪些部分难以扩展。我希望过去有人说服我这样做，而不是为早期版本过度设计。）

于 2012-08-20T01:46:52.240 回答