对数据库进行时间序列访问的设计决策
本文关键字：决策 访问 时间序列 数据库 | 更新日期: 2023-09-27 18:11:01
我正在寻找一种"最佳实践"的方式来处理传入的时间序列数据。
一个数据点包括时间，高度，宽度等每一个"tick"。用集合类在内存中保存n个数据点，然后在达到集合限制后将这些点"刷新"到数据库，这是一个好主意吗?
或者数据点应该直接写入数据库，以便我的对象可以对它运行查询?我知道这是关于我的需求的一点信息，所以问题是与内存和数据库混合解决方案相比，数据访问数据库的速度有多快。
假设每秒最多有500个数据点要处理，并且必须在上以某种方式计算每个传入的点。对于纯数据库解决方案，必须对每个传入点运行存储查询。我猜这是无效的，但我不知道这样的数据库是否能够"倾听"并做到这一点快。
数据库的一个很好的特性是将积分发送给订阅者。这是可能的SQL服务器?
谢谢,Juergen
把"发送给订阅者"的要求放在一边，不要陷入过早优化的陷阱。
我会先尝试最简单的解决方案，这可能只是在数据到达时将数据写入数据库。然后进行压力测试。如果性能没有达到标准，找到瓶颈并对其进行优化。
转到"发送到订阅者"的需求，这并不是关系数据库平台通常设计的(它们更多地是关于存储数据并将其公开以供按需检索)。发布-sub类型需求通常最好使用某种消息总线来解决。也许我们可以看看NServiceBus。
如果不是多用户，那么内存中的数据点与集合类是确定的赢家。
如果它是多用户的，那么我会在服务器端使用某种共享内存数据结构
我想说更大的问题是您打算如何在SQL中存储它。我会将数据点在内存中排队一段时间(1秒?)，然后用blob字段或nvarchar字段写一行到数据库，其中包含该秒的所有数据，因为这将意味着数据库将进一步扩展，行可以包含这一秒发生的事情的一些摘要信息，您可以在对数据执行查询时使用，以减少您在做选择时的负载…当然，如果要对这些数据执行直接查询，这是不可行的。