2010-07-07 51 views
0

我正在为记录多个不同节点的数据的应用程序创建数据库。数据记录看起来像这样:跨多个节点建模时间日志记录

  • 时间戳
  • 几个整数值
  • 几个浮点值
  • 也许一个字符串或两个

每个节点分别轮询。

我会在每10分钟和每10秒(可变记录间隔)之间创建一个日志条目,所以我会查看每个节点每天10k条目以下(最多)。

我想知道如何构建数据库以获得最佳数据访问/管理。我想我会想要访问至少30天的历史数据,并且我想为100个节点做好准备。

最初我想创建一个包含日志数据的单个表,并通过1:1关系将每个日志条目链接到一个节点,但是恐怕我的表在这种情况下会变得太大。

是为每个节点创建一个单独的表一个可行的选项?

任何意见/建议将有帮助,

谢谢!

+0

一些问题:插入数据(行)。一旦插入,数据是否更新?是否有超过30天的数据被定期删除,还是只是永远堆积起来?您必须能够报告当前数据,还是可以在生成数据和将数据提供给用户之间存在延迟(一小时,一天)?他们将如何使用数据进行大报告,趋势分析,并将其输入到后续系统中?对于输入或输出来说,亚秒级性能至关重要?这些和类似的问题将推动OLTP与仓库设计决策。 – 2010-07-07 17:57:34

+0

答案,按问题顺序:数据一旦记录就不会更新。在30天之后,我想它会被移到一个档案数据库,在那里它确实会永远堆积(如果可能的话)。报告当前数据的能力至关重要,但我们可能会延迟几分钟。数据将用于报告,分析,可能会导入后续系统。秒以下的表现不是一个因素,秒的分辨率已经足够。 – Goro 2010-07-07 20:27:31

回答

1

读你的上述评论,我会去几乎你先想通方式:

与所有必要的信息创建一个表。你的想法看起来很好,因为架构很小,这对任务来说就足够了。

在30天后归档数据的cron作业是个不错的主意。如果您不想将其移动到其他数据库(表格),则可以将其导出为CSV(或类似文件)并将其存储在某个地方。

有些事情你应该记住:

  • 在每个数据库服务器,尤其是存储
  • 出口比例如不同格式的数据足够的空间CSV可能不是最好的主意。如果您的应用程序具有可以更容易存储的另一种格式,则您可以使用使用另一种格式。