【问题标题】:Indexing usefulness in sorted data set排序数据集中的索引有用性
【发布时间】:2015-12-30 04:59:42
【问题描述】:

我的数据库中有一个包含以下字段的表。

日期/时间、设备 ID、传感器 1 值、传感器 2 值。

这是物联网项目的一部分,其中电子传感器每秒将数据发送到数据库以进行数据分析

我们最初将设备 ID 设置为预测客户端将仅使用来自某些传感器的数据的索引。

但是,我们发现我们的客户主要要求提供基于日期的数据(例如 2013 年全年的数据)。

由于 e 记录的大小,仅对 1 年的数据(估计有 1000 万个条目)运行 Select * 过滤的日期时间查询需要几天时间。

我的问题是,索引日期/时间以加快查询速度是否有意义,因为日期时间字段在插入期间已排序?

如果是这样,有什么建议可以加快这样的查询速度吗?

谢谢。

【问题讨论】:

  • 表是否有聚集的主键或索引?这就是您的数据“排序”的依据。默认情况下没有排序顺序,因此即使您按时间顺序插入记录,也没有默认排序顺序,除非您有聚集键或索引。
  • 我的建议是:给数据源添加分页,那么你只需要一个数据分区而不是获取全年的数据,另外,添加索引会占用更多的内存,因为大量数据。
  • @Jeremy 我们没有主键或索引。因为我们的数据集中没有唯一的字段。是的,你是对的,我们是按时间顺序插入的。
  • @sean 查看这篇文章stackoverflow.com/questions/20050341/… 如果您要按列排序或选择,应该有一个索引

标签: sql indexing


【解决方案1】:

嗯,这有点道理。 “某种”是因为您正在获取大量价值列表 - 整整一年。索引应该有帮助,因为数据都在相邻的数据页上,应该加载到缓存中。但是,仍然存在大量行,因此索引增加了开销(以及跳过读取一堆行)。

也许更好的方法是按日期进行分区。然后您可以构造查询,这样一年(或一个月或一天)的数据只需要一个分区。根据您的说法,我将研究分区;详细信息取决于您的数据库。

【讨论】:

    【解决方案2】:

    您使用了“主要”一词,这表明您的客户也可能不时进行其他类型的查询。

    所以我的建议是对设备 ID 使用复合聚集索引,然后使用 DateTime 进行更灵活的查询,并使用 Google Big Query(或类似的东西)进行整体分析。例如2013年全年数据

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2013-10-08
      • 2021-09-12
      • 2014-12-05
      • 2021-08-10
      • 2021-11-24
      • 2020-03-19
      • 2020-07-22
      • 2020-06-21
      相关资源
      最近更新 更多