2

我想就事件记录器的 mysql 表设计提供建议。

我们的需求： - 跟踪大量动作 - 10 000 次动作/秒 - 此时 10 亿行

我们的硬件： - 2*Xeon（系统视为 32 CPU） - 128 GB RAM - 6*600 SSD with Raid 10

我们的餐桌设计：

CREATE TABLE IF NOT EXISTS `log_event` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `id_event` smallint(6) NOT NULL,
  `id_user` bigint(20) NOT NULL,
  `date` int(11) NOT NULL,
  `data` bigint(20) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `id_event_2` (`id_event`,`data`),
  KEY `id_inscri` (`id_inscri`),
  KEY `date` (`date`),
  KEY `id_event_4` (`id_event`,`date`,`data`)
) ENGINE=InnoDB  DEFAULT CHARSET=latin1 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8


ALTER TABLE `log_event`
  ADD CONSTRAINT `log_event_ibfk_1` FOREIGN KEY (`id_inscri`) REFERENCES `inscription` (`id_inscri`) ON DELETE CASCADE ON UPDATE CASCADE;

我们的问题： - 我们有一个自动增量作为主要，但它并没有真正使用。删除它有问题吗？如果我们删除它，我们将没有主键 => 如何识别一行？

  • 我们想做partionning，但是用foreign似乎是不可能的？

  • 我们不做批量插入。在没有索引的内存表中插入并每 5 分钟复制一次数据是个好主意吗？

你有什么优化的想法吗？你有这种系统的最佳实践吗？

谢谢 ！

弗朗索瓦

4

1 回答 1

0

关系表（关系）的主键可能有两种类型：

  1. 自然——存在于主题区，完全确定关系表的每一行。自然主键可能很简单（如果仅包含一列），也可能很复杂（如果包含多列）。不建议在大字符串列上设置自然主键。

  2. 人工- 特殊列，由数据库设计人员/开发人员注入以提高表性能，如果自然键很复杂，并且必须在相关表中使用（对于某些东西来说是外键），或者如果它很简单，但很大并且会产生在相关表中作为外键复制时的数据开销，或者如果搜索复杂（例如，对 ID 的 CRUD 操作VARCHAR可能比对INTID 的操作要慢）。可能还有其他原因。TL;DR : 人工键 - 一个特殊的列，用于完全确定关系表的每一行并提高其对 CRUD 操作的性能。

我们有一个自动增量作为主要，但它并没有真正使用。删除它有问题吗？如果我们删除它，我们将没有主键 => 如何识别一行？

如果您不需要将您的表引用到另一个表（作为源），那么您可能会删除人工密钥而不会产生任何后果。不过，我建议您在此表中设置任何其他内容PRIMARY KEY，以避免数据重复和明显性（如果重要）。

您的表本身（如果正确规范化）将具有自然键作为“关键候选者”之一。它可能很复杂（由几列组成）。这是正常的。但是不要给字符串设置primary，因为PRIMARY总是有索引，会产生数据开销。如果是组合INT或“小”VARCHAR列，则属正常。

考虑作为一个选项： id_event + id_user+ date。

我们不做批量插入。在没有索引的内存表中插入并每 5 分钟复制一次数据是个好主意吗？

这不是一个坏主意。但这不是一个好主意，直​​到它经过适当的测试。在实际使用之前尝试执行负载测试。

如果您不MEMORY向其他人引用表格，那么您仍然可以将其与任何其他InnoDB表格联接。但是您将失去InnoDB功能（参照完整性）。如果父表ON DELETE CASCADE ON UPDATE CASCADE的丢失不是问题，那么它可能会完成。至于我，InnoDB在你的情况下切换表引擎并没有那么慢。

于 2013-05-17T08:07:42.430 回答