大量数据的 MySQL 性能问题

Question

我有一个正在工作的软件项目让我发疯。这是我们的问题：我们有一系列数据联系人需要每秒记录一次。它需要包括时间、方位（360-1080 字节的数组）、范围和一些其他字段。我们的系统还需要能够将这些数据存储长达 30 天。实际上，最多可以有 100 个不同的联系人，因此在 30 天内最多可以有大约 150,000,000 到大约 1,000,000,000 个不同的点。

我正在尝试考虑存储所有这些数据并在以后检索的最佳方法。我的第一个想法是使用一些 RDBMS，比如 MySQL。作为一名嵌入式 C/C++ 程序员，我很少有使用 MySQL 处理如此大数据集的经验。我在小型数据集上涉足过它，但几乎没有那么大。我为两个将存储一些数据的表生成了以下架构：

CREATE TABLE IF NOT EXISTS `HEADER_TABLE` (
  `header_id` tinyint(3) unsigned NOT NULL auto_increment,
  `sensor` varchar(10) NOT NULL,
  `bytes` smallint(5) unsigned NOT NULL,
  PRIMARY KEY  (`header_id`),
  UNIQUE KEY `header_id_UNIQUE` (`header_id`),
  UNIQUE KEY `sensor_UNIQUE` (`sensor`)
) ENGINE=MyISAM AUTO_INCREMENT=0 DEFAULT CHARSET=latin1;

CREATE TABLE IF NOT EXISTS `RAW_DATA_TABLE` (
  `internal_id` bigint(20) NOT NULL auto_increment,
  `time_sec` bigint(20) unsigned NOT NULL,
  `time_nsec` bigint(20) unsigned NOT NULL,
  `transverse` bit(1) NOT NULL default b'0',
  `data` varbinary(1080) NOT NULL,
  PRIMARY KEY  (`internal_id`,`time_sec`,`time_nsec`),
  UNIQUE KEY `internal_id_UNIQUE` (`internal_id`),
  KEY `time` (`time_sec`)
  KEY `internal_id` (`internal_id`)
) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=latin1;

CREATE TABLE IF NOT EXISTS `rel_RASTER_TABLE` (
  `internal_id` bigint(20) NOT NULL auto_increment,
  `raster_id` int(10) unsigned NOT NULL,
  `time_sec` bigint(20) unsigned NOT NULL,
  `time_nsec` bigint(20) unsigned NOT NULL,
  `header_id` tinyint(3) unsigned NOT NULL,
  `data_id` bigint(20) unsigned NOT NULL,
  PRIMARY KEY  (`internal_id`, `raster_id`,`time_sec`,`time_nsec`),
  KEY `raster_id` (`raster_id`),
  KEY `time` (`time_sec`),
  KEY `data` (`data_id`)
) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=latin1;

标题表仅包含 10 行并且是静态的。它只是告诉原始数据来自哪个传感器，以及该类型传感器输出的字节数。 RAW_DATA_TABLE 本质上存储原始方位数据（一个 360-1080 字节的数组，每度最多表示三个样本）。 rel_RASTER_TABLE 保存 RAW_DATA_TABLE 的元数据，可以有多个联系人引用相同的原始数据行。在 rel_RASTER_TABLE 中找到的 data_id 指向 RAW_DATA_TABLE 中某行的 internal_id，我这样做是为了减少所需的写入量。

显然，正如您可能知道的那样，我在从该数据库读取和删除时遇到了性能问题。我们软件的操作员可以看到实时数据，还可以进入重建模式并覆盖过去的数据范围，例如过去一周。我们的后端日志服务器抓取历史记录行并通过 CORBA 接口将它们发送到显示器。虽然所有这一切都在发生，但我有一个工作线程，它一次删除 1000 行数据超过 30 天。如果会话运行时间超过 30 天，就会出现这种情况。

我们目前实施的系统适用于较小的数据集，但不适用于大型数据集。我们的 select 和 delete 语句可能需要 2 分钟以上的时间才能返回结果。这完全扼杀了我们实时消费者线程的性能。我怀疑我们没有正确设计我们的模式，选择错误的键，没有正确优化我们的 SQL 查询，或者每个子集。除非其他操作运行时间过长，否则我们的写入不会受到影响。

这是我们用来获取历史数据的示例 SQL 查询：

SELECT 
  rel_RASTER_TABLE.time_sec, 
  rel_RASTER_TABLE.time_nsec, 
  RAW_DATA_TABLE.transverse, 
  HEADER_TABLE.bytes, 
  RAW_DATA_TABLE.data 
FROM 
  RASTER_DB.HEADER_TABLE, 
  RASTER_DB.RAW_DATA_TABLE, 
  RASTER_DB.rel_RASTER_TABLE 
WHERE 
  rel_RASTER_TABLE.raster_id = 2952704 AND 
  rel_RASTER_TABLE.time_sec >= 1315849228 AND 
  rel_RASTER_TABLE.time_sec <= 1315935628 AND 
  rel_RASTER_TABLE.data_id = RAW_DATA_TABLE.internal_id AND 
  rel_RASTER_TABLE.header_id = HEADER_TABLE.header_id;

对于这个问题如此冗长，我提前道歉，但我已经利用了其他资源，这是我最后的手段。我想我会尽量做到描述性强，你们第一眼看到有什么方法可以改进我们的设计吗？或者，无论如何我们都可以针对如此大的数据集优化我们的选择和删除语句？我们目前正在运行 RHEL 作为操作系统，遗憾的是无法更改服务器上的硬件配置（4 GB RAM，四核）。我们正在使用 C/C++ 和 MySQL API。任何速度改进都将是非常有益的。如果您需要我澄清任何事情，请告诉我。谢谢！

编辑：顺便说一句，如果您不能提供具体帮助，也许您可​​以将我链接到您遇到的一些用于优化 SQL 查询、架构设计或 MySQL 调优的优秀教程？

Answer 1

您可以尝试的第一件事是对数据进行反规范化。在这样大小的数据集上，进行连接，即使你有索引也需要非常密集的计算。把这三张桌子变成一张桌子。当然会有重复的数据，但是没有连接它会更容易使用。第二件事，看看你能不能得到一台有足够内存的机器来容纳整个表。对于具有 24GB RAM 的机器来说，它的成本并不高（1000 美元或更少）。我不确定这是否会保存您的整个数据集，但它也将极大地帮助您获得 SSD。对于未存储在内存中的任何内容，SSD 应该可以帮助您高速访问它。第三，研究其他数据存储技术，例如 BigTable，它们旨在处理非常大的数据集。

Answer 2

我会说在这种情况下分区是绝对必须的：

• 大量数据
• 新数据源源不断
• 隐式：旧数据不断被删除。

查看this for mySQL。

查看您选择的 stmt（按时间过滤），我会说时间列上的分区。

当然，您可能想根据您想要使用的频繁查询添加一些索引。

--编辑--

我看到很多人都建议了索引。我的经验是，在具有大量行的表上建立索引要么会降低性能（最终），要么需要大量资源（CPU、内存……）才能使索引保持最新。 因此，虽然我也建议添加索引，但请注意，除非您先对表进行分区，否则它绝对没用。 最后，在添加索引时遵循 symcbean 的建议（优化索引的数量和键）。

--编辑结束--

如果您不熟悉分区，请快速了解分区。

• 通常单个表转换为单个数据文件。分区表转换为每个分区一个文件。
• 优势
  • 插入速度更快，因为它在物理上被插入到较小的文件（分区）中。
  • 删除大量行通常会转化为删除分区（比“从 xxx 中删除时间 > 100 且时间
  • 对表分区的键使用 where 子句的查询要快得多。
  • 索引构建速度更快。

Answer 3

我对 MySQL 没有太多经验，但这里有一些先验的想法。

您的选择是否在存储过程中？

select 的谓词通常按照其询问的顺序进行搜索。如果磁盘上的数据被重新排序以匹配主键，那么先执行 raster id 就可以了。不过，您将支付每次插入重新订购的费用。如果数据按时间顺序存储在磁盘上，您可能希望在raster_id 之前搜索time_sec。

WHERE 
  rel_RASTER_TABLE.raster_id = 2952704 AND 
  rel_RASTER_TABLE.time_sec >= 1315849228 AND 
  rel_RASTER_TABLE.time_sec <= 1315935628 AND 
  rel_RASTER_TABLE.data_id = RAW_DATA_TABLE.internal_id AND 
  rel_RASTER_TABLE.header_id = HEADER_TABLE.header_id;

您的索引不遵循搜索谓词。

它通常会根据键创建索引。

  PRIMARY KEY  (`internal_id`, `raster_id`,`time_sec`,`time_nsec`),
  KEY `raster_id` (`raster_id`),
  KEY `time` (`time_sec`),
  KEY `data` (`data_id`)

它可能没有使用主索引，因为您没有使用 internal_id。您可能希望将internal_id 设置为主键并根据您的搜索参数创建一个单独的索引。至少在raster_id 和time_sec 上。

连接是否太松？

这可能是我对 MySQL 的缺乏经验，但我希望看到连接的条件。在这里使用 FROM 会自然加入吗？我没有看到任何指定的外键，所以我不知道它会如何合理地加入这些表。

FROM 
  RASTER_DB.HEADER_TABLE, 
  RASTER_DB.RAW_DATA_TABLE, 
  RASTER_DB.rel_RASTER_TABLE 

通常在开发这样的东西时，我会使用较小的集合并删除谓词，以确保每个步骤都符合我的期望。如果你不小心在前面撒了一张大网，后来又缩小了，你可能会掩盖一些低效率的问题。

大多数查询优化器都有办法输出如何优化，确保它符合您的期望。其中一个 cmets 提到了解释计划，我认为这就是所谓的。

Answer 4

如果不知道所有查询是什么，很难给出具体建议，但是查看您提供的单个查询，没有非常适合解决此问题的索引。

实际上结构有点混乱——如果internal_id 是一个自动递增值，那么它是唯一的——为什么要在主键中添加其他内容？看起来 rel_RASTER_TABLE 的一个更合理的结构是：

PRIMARY KEY  (`internal_id`),
KEY (`raster_id`,`time_sec`,`time_nsec`),

对于 RAW_DATA_TABLE，它的索引远非最佳应该是显而易见的。应该是：

PRIMARY KEY  (`internal_id`,`time_sec`,`time_nsec`),
KEY `time` (`time_sec`, `time_nsec`)

请注意，删除冗余索引将加快插入/更新速度。 捕获慢查询应该会有所帮助 - 并学习如何使用“解释”来查看哪些索引是冗余/需要的。

您还可以通过调整 mysql 实例来提高性能 - 特别是增加排序和连接缓冲区 - 尝试运行 mysqltuner

Answer 5

首先，我会尝试创建一个视图，其中仅包含需要在不同表之间选择的必要信息。

顺便说一句，对于您要完成的工作，MySQL 不一定是最优化的数据库系统...查看其他解决方案，例如 Oracle、Microsoft SQL、PostgreSQL 等。此外，性能会因所使用的服务器而异用过。