0

在此处输入图像描述

我们得到了这个数据模型。知道有限的树深度，我们当前的表与模型是 1:1 的，外键指向父节点。Channel到Station,Measurement到Channel和Station. 90% 的查询是：

select value from measurements where
fk_station=X and fk_channel=Y and timestamp>=A and timestamp<=B
order by timestamp asc

其余 10% 与其他带时间戳的表类似，只是由于缺少fk_channel.

我们面临的问题：表中有数亿个唯一[station,channel,timestamp]行Measurement并且还在增长。时间戳索引已经非常大，排序子句非常慢，以至于我们不得不开始按Station Id拆分它；所以我们有表Measurement_<Station Id>，Station外键被省略了。它有很大帮助，但仍有一些表有数千万行。在负载高峰期，我们每分钟大约有 80000 个查询，并且这些更大的表上的查询明显更懒惰。我们仍然从一个 MySQL/ISAM 实例运行，没有任何花哨的优化技巧。文件系统上大约 150GB。

  1. 是否有任何显着不同/更好的方式来存储这种数据模型？
  2. 对于当前的结构，我们在这种大小/负载下遇到这种性能问题是否正常？机器是今天的平均硬件，没有嵌入式原子也没有8+核心野兽
  3. 拆分Measurement表是正确的做法吗？我们不是 SQL 专家，但查询和所需的索引看起来如此明显，以至于我们甚至没有考虑“优化”它。拆分有很大帮助，但其他东西也可能
  4. 有没有其他加速索引的方法？我们必须一遍又一遍地执行相同的索引，获得相同结果的子集，这有点愚蠢。我们永远不会使用任何其他索引，甚至不会更改为desc. 这是非常专业的设备。如果索引以某种方式是“本机顺序”会很好:-)
  5. 是否有助于分发/分片拆分的Measurement表？正如我所说，有些表仍然很大，问题感觉是关于索引大小的分布无济于事，所以也许只是降低查询负载......
4

2 回答 2

1

在 mysql 等关系数据库中考虑的简单规则：

  1. 获取太多数据永远不会很快。汇总一下就可以了。- 您的示例查询没有汇总任何内容。让我想知道您是否在应用程序中处理和汇总这些价值。提示：使用列存储引擎进行聚合，例如。infinidb，它也支持查询执行的并行性，innodb 不支持。
  2. 对大量数据进行排序永远不会很快 - 问问自己，如果查询返回 10 万条记录，那么您的处理工作/前端网格等会消耗多少？网络用户可以在屏幕上消耗 100K 数据吗？不是真的，然后限制它。此外，按自动增量 ID 而不是时间戳排序。关系数据库引擎不适合对大量数据进行排序，您很快就会遇到天花板。
于 2012-10-01T09:06:20.967 回答
0

是否有可能将测量数据拆分到多个表中可以减小大小？如果 90% 的查询是过去 24 小时的时间戳，那么您可能需要微调该数据，并将其余的存储在单独的表甚至数据库中。我相信Measurement应该有一个FK只到Channel，它的ID只有PK，还有一个FK到Station。

于 2012-09-29T22:07:06.000 回答