MySql - 大表 IP 配对的更好架构？

Question

我正在尝试管理一些互联网日志。我本质上是在捕捉哪些 IP 与其他 IP 联系并对其进行报告。

问题是有大量的喋喋不休，我不确定我是否可以让我的架构变得更好。

我的表架构：

CREATE TABLE `IpChatter` (
  `Id` bigint(20) NOT NULL AUTO_INCREMENT,
  `SourceIp` bigint(20) NULL,
  `DestinationIp` bigint(20) NULL,
  `SourcePort` int(11) NULL,
  `DestinationPort` int(11) NULL,
  `FKToSomeTableWithExtraMetaDataId` bigint(20) NOT NULL,
  CONSTRAINT `PK_IpChatter` PRIMARY KEY (`Id` ASC)
) ENGINE=InnoDB;


CREATE INDEX `IX_IpChatter_FKToSomeTableWithExtraMetaDataId` ON `IpChatter`  (`FKToSomeTableWithExtraMetaDataId`) using HASH;
CREATE INDEX `IX_IpChatter_Main_Query_SourceIp` ON `IpChatter`        (`SourceIp`);
CREATE INDEX `IX_IpChatter_Main_Query_DestinationIp` ON `IpChatter`   (`DestinationIp`);
CREATE INDEX `IX_IpChatter_Main_Query_SourcePort` ON `IpChatter`      (`SourcePort`);
CREATE INDEX `IX_IpChatter_Main_Query_DestinationPort` ON `IpChatter` (`DestinationPort`);


ALTER TABLE `IpChatter` ADD CONSTRAINT `FK_IpChatter_FKToSomeTableWithExtraMetaData` 
FOREIGN KEY (`FKToSomeTableWithExtraMetaDataId`) REFERENCES `FKToSomeTableWithExtraMetaData` (`Id`)
ON DELETE CASCADE;

现在我有 2mill 行数据并在大约 4 秒内拉回我需要的数据。然而，这是使用相对较轻的测试数据。我想在最终产品中数据的大小会大 30 倍。所以这 4 秒肯定意味着最终产品的 2 分钟。有没有更好的方法可以使这些数据正常化，或者我遇到瓶颈而我无能为力？另外，我选择的索引好吗？

Answer 1

没关系，我想通了。我想我只需要输入问题来帮助我想出一个解决方案。

因此，在查看我的数据后，我注意到很多配对重复但在不同的 FKToSomeTableWithExtraMetaDataId 值下。

所以告诉我，我可以通过创建一个具有不同 SourceIp,DestinationIp,SourcePort,DestinationPort 配对的表来规范化数据。然后创建一个查找表以将该表与 ToSomeTableWithExtraMetaData 表连接起来。

这将我的原始 IP 数据减少了 1700%！在搜索一系列 IP 时，这将大大提高性能，现在它必须经过更少的行。加上查找表，我可以更灵活地查询。

CREATE TABLE `IpChatter` (
  `Id` bigint(20) NOT NULL AUTO_INCREMENT,
  `SourceIp` bigint(20) NULL,
  `DestinationIp` bigint(20) NULL,
  `SourcePort` int(11) NULL,
  `DestinationPort` int(11) NULL,
  `FKToSomeLookupTableId` bigint(20) NOT NULL,
  CONSTRAINT `PK_IpChatter` PRIMARY KEY (`Id` ASC)
) ENGINE=InnoDB;


CREATE INDEX `IX_IpChatter_FKToSomeLookupTableId` ON `IpChatter`  (`FKToSomeLookupTableId`) using HASH;
CREATE INDEX `IX_IpChatter_Main_Query_SourceIp` ON `IpChatter`        (`SourceIp`);
CREATE INDEX `IX_IpChatter_Main_Query_DestinationIp` ON `IpChatter`   (`DestinationIp`);
CREATE INDEX `IX_IpChatter_Main_Query_SourcePort` ON `IpChatter`      (`SourcePort`);
CREATE INDEX `IX_IpChatter_Main_Query_DestinationPort` ON `IpChatter` (`DestinationPort`);


ALTER TABLE `IpChatter` ADD CONSTRAINT `FK_IpChatter_FKToSomeLookupTable` 
FOREIGN KEY (`FKToSomeLookupTableId`) REFERENCES `FKToSomeLookupTable` (`Id`)
ON DELETE CASCADE;


CREATE TABLE `FKToSomeLookupTable` (
  `FKToSomeTableWithExtraMetaDataId` bigint(20) NOT NULL,
  `IpChatterId` bigint(20) NOT NULL,
  CONSTRAINT `PK_FKToSomeLookupTable` PRIMARY KEY (`Id` ASC)
) ENGINE=InnoDB;

CREATE INDEX `IX_IpChatter_FKToSomeTableWithExtraMetaDataId` ON `FKToSomeLookupTable`  (`FKToSomeTableWithExtraMetaDataId`) using HASH;
CREATE INDEX `IX_IpChatter_IpChatterId` ON `FKToSomeLookupTable`  (`IpChatterId`) using HASH;

ALTER TABLE `FKToSomeLookupTable` ADD CONSTRAINT `FK_FKToSomeLookupTable_FKToSomeTableWithExtraMetaData` 
FOREIGN KEY (`FKToSomeTableWithExtraMetaDataId`) REFERENCES `FKToSomeTableWithExtraMetaData` (`Id`)
ON DELETE CASCADE;

ALTER TABLE `FKToSomeLookupTable` ADD CONSTRAINT `FK_FKToSomeLookupTable_IpChatter` 
FOREIGN KEY (`IpChatterId`) REFERENCES `IpChatter` (`Id`)
ON DELETE CASCADE;

Answer 2

缩小表格大小。较小是帮助（某些）提高速度的一种方法。

IPv4 可以打包成INT UNSIGNED，与您当前的 8 字节 BIGINT 相比，它是 4 个字节。另一方面，IPv6 需要BINARY(16)；你所拥有的将不起作用。

我认为端口号适合 2 字节的 SMALLINT UNSIGNED。

您是否希望您的表大于 40 亿行？如果没有，请使用 INT UNSIGNED 而不是 BIGINT 作为 id。

摆脱FOREIGN KEYs，它们会减慢速度；同时，约束从未触发错误，不是吗？你真的用CASCADE的开销吗？

不要索引每一列。查看您的查询并索引列或列组合，这将使SELECTs、UPDATEs 和DELETEs 受益。

请显示查询；没有它们，我们就无法判断性能。