我正在设计一个PostgreSQL数据库,它接收来自许多传感器源的读数.我已经对设计进行了大量的研究,我正在寻找一些新的输入来帮助我摆脱困境.
需要说明的是,我并不是在寻找描述数据来源或任何相关元数据的帮助.我特别想弄清楚如何最好地存储数据值(最终是各种类型).
进入数据的基本结构如下：
>对于每个数据记录设备,有几个通道.
>对于每个通道,记录器读取数据并将其附加到带有时间戳的记录
>不同的通道可能有不同的数据类型,但通常一个float4就足够了.
>用户应该(通过数据库功能)能够添加不同的值类型,但这种担忧是次要的.
>还将通过功能添加记录器和通道.
这种数据布局的显着特点是我有很多通道将数据点与一个带有时间戳和索引号的记录相关联.
现在,描述数据量和常见访问模式：
>每分钟将有大约5个记录器进入数据,每个记录器有48个通道.
>在这种情况下,总数据量将是每天345,600读数,每年1.26亿,这些数据至少需要在未来10年内持续读取.
>更多记录器&未来将添加频道,可能来自物理上不同类型的设备,但希望具有类似的存储表示.
>通用访问将包括在所有记录器中查询类似的通道类型以及跨记录器时间戳加入.例如,从logger1获取channel1,从logger2获取channel4,并在logger1.time = logger2.time上执行完全外连接.
我还要提到的是,每个记录器时间戳都会因时间调整而发生变化,并将在不同的表中进行描述,该表显示服务器的时间读数,记录器的时间读数,传输延迟,时钟调整以及产生的调整时钟值.对于一组记录器记录/时间戳,这将取决于检索.这是我下面的RecordTable的动机,但是现在只要我可以从某个地方引用一个(记录器,时间,记录)行来改变相关数据的时间戳,就不用太多了.
我已经考虑了很多模式选项,最简单的类似于混合EAV方法,其中表本身描述了属性,因为大多数属性只是一个称为“值”的实际值.这是一个基本布局：
RecordTable DataValueTable
---------- --------------
[PK] id <-- [FK] record_id
[FK] logger_id [FK] channel_id
record_number value
logger_time
考虑到logger_id,record_number和logger_time是唯一的,我想我在这里使用了代理键,但希望我在这里节省空间的理由是有意义的.我还考虑将一个PK id添加到DataValueTable(而不是PK是record_id和channel_id),以便从其他表中引用数据值,但我试图抵制让这个模型“过于灵活”的冲动.但是,我确实希望尽快开始获取数据,而不需要在以后需要添加额外功能或不同结构化数据时更改此部分.
起初,我正在为每个记录器创建记录表,然后为每个通道的值表并在其他地方(在一个地方)描述它们,并将视图连接到所有,但这只是感觉“错误”因为我重复同样的事情所以多次.我想我试图在太多表和太多行之间找到一个快乐的媒介,但是划分更大的数据(DataValueTable)似乎很奇怪,因为我很可能是在channel_id上进行分区,所以每个分区都有相同的值每一行.此外,在这方面进行分区需要在每次添加通道时重新定义主表中的检查条件时进行一些工作.按日期分区仅适用于RecordTable,考虑到它的相对较小(使用5个记录器每天7200行),这并不是必需的.
我还考虑在channel_id上使用上面的部分索引,因为DataValueTable会变得非常大,但是通道ID的集合仍然很小,但我真的不确定这会在多年后很好地扩展.我已经使用模拟数据进行了一些基本的测试,性能只是如此,我希望它随着数据量的增长而保持优异.此外,一些人担心抽真空和分析大型表,并处理大量索引(在这种情况下最多250个).
在一个非常小的方面,我还将跟踪对这些数据的更改并允许注释(例如,传感器上的鸟,所以这些值被调整/标记等),因此在考虑时请记住这一点.这里的设计,但现在是一个单独的问题.
关于我的经验/技术水平的一些背景,如果它有助于了解我的来源：我是CS博士生,我作为研究的一部分定期处理数据/数据库.但是,我为客户设计一个强大的数据库(这是业务的一部分)的实践经验具有特殊的长寿和灵活的数据表示,这在某种程度上是有限的.我认为我现在的主要问题是我正在考虑解决这个问题的所有方法,而不是专注于完成它,我根本没有在我面前看到一个“正确”的解决方案.
总而言之,我想这些是我的主要问题：如果你做过这样的事情,那对你有用的是什么？我没有看到我在这里提出的各种设计有什么好处/缺点？在给定这些参数和访问模式的情况下,您如何设计这样的东西？
我很乐意在需要时提供澄清/详细信息,并提前感谢您的精彩.
最佳答案 在Relational数据库中提供所有这些都没有问题. PostgreSQL不是企业级的,但它肯定是更好的免费软件之一.
需要说明的是,我并不是在寻找描述数据来源或任何相关元数据的帮助.我特别想弄清楚如何最好地存储数据值(最终是各种类型).
那是你最大的障碍.与允许分解和隔离分析/设计组件的程序设计相反,数据库需要设计为单个单元.规范化和其他设计技术需要考虑整体和上下文中的组件.数据,描述和元数据必须一起评估,而不是作为单独的部分.
其次,当您从代理键开始,暗示您知道数据以及它与其他数据的关系时,它会阻止您对数据进行真正的建模.
我回答了一组非常相似的问题,巧合的是非常相似的数据.如果您可以先阅读这些答案,那么我们可以为您的问题/答案节省大量的打字时间.
Answer One/ID Obstacle
Answer Two/Main
Answer Three/Historical
