代码之家 › 专栏 › 技术社区 › supercat

高效的数据库设计,可频繁记录小事情

database-design sql

supercat · 技术社区 · 14 年前

我有一个数据库,其中存储了各种仪器的温度记录数据。数据可以每分钟记录一次。设计日志表的一种方法是将每个日志条目与设备ID、时间戳和序列号一起放在自己的行中(即使设备上的时钟发生了变化,也应该可以按照实际测量的顺序对条目进行排序)。然而,这似乎极为低效,因为除了系统为索引添加的任何内容外,每16位测量值可能都会附加16字节的其他数据。我认识到,试图优化数据库中的每一个字节通常是毫无意义的,但将数据按9:1或更糟的比例扩展似乎很愚蠢。

目前,我将这些记录聚合为一组等间距的读数,并以可变长度的不透明二进制格式为每条记录存储一组数据,以及设备ID、第一次读数的时间戳和序列号以及读数之间的间隔。这工作得很好,据我所知,这可能是最好的方法,但它不允许太多的查询。

有没有什么好的方法来处理这样的数据集而不需要过多的冗余?

3 回复 | 直到 14 年前

Remus Rusanu 14 年前

你的数据不会扩大到9倍。你的数据保持大致相同,因为你没有一个16位的测量开始。你的尺寸是 . 所以你的数据在将它们添加到数据库之前,就要有一个序列号、设备ID和时间戳,不管您是否愿意对此进行说明。

如果将数据存储在关系表(SQL)中,请以关系格式存储:normalized。每行一条记录。以可查询格式存储信息。'以不透明的二进制格式聚合“记录”会使整个数据库毫无用处,因为数据不能被查询、聚合、过滤,什么都不能。你对“这个很好用”的定义基本上是“我能写数据,没有人能利用它”,这很难说是“很好”。你不妨把数据转储到 /dev/nul ...

将数据存储为适当的记录。将数据存储为正确的数据库类型,不要使用“不透明blob”。而且“数据可能每分钟记录一次”在任何数据库标准中都不是“频繁”的。如果你说“每秒100次”,那我们就有话要说了。

Clueless 14 年前

这真的是个问题吗?假设我们高估了一点,并说每个度量值有50字节的数据+元数据。 Google

lashtal 14 年前

我相信你应该用 RRDtool 存储这样的数据。 Wikipedia article

推荐文章

Community wiki · 在进行TDD和增量添加功能时,我是提前设计数据库还是在编码时添加表和列?

1 年前

Michael Samuel · MYSQL在以下情况下自动创建索引

6 年前

user9659025 · 如何正确存储必要的信息以注册用户和大会的其他参与者?(方案1有效,但方案2和3无效)

6 年前

Patricia Rozario · 数据库设计确保一对一关系

6 年前

dryhay · MySQL“多对多”关系错误

6 年前

L. Fox · 我在这里用的是什么样的Laravel雄辩的关系

7 年前

Geoff Harper · 我应该如何构建关系松散的SQL db

7 年前

waroxx · SQL—当多个表具有相同的列时,最好怎么做

7 年前

Lumpi01 · SQL 2不同的注释类型-最佳解决方案?

7 年前

Hayreddin Tüzel · 预约系统数据库建模[关闭]

7 年前