Mysql:使用192万亿条记录......(是的,192万亿)

Modified on: Wed, 17 Jul 2019 20:40:02 +0800

以下是问题......

考虑到192万亿条记录,我的考虑应该是什么?

我主要担心的是速度。

这是表格......

    CREATE TABLE `ref` (
  `id` INTEGER(13) AUTO_INCREMENT DEFAULT NOT NULL,
  `rel_id` INTEGER(13) NOT NULL,
  `p1` INTEGER(13) NOT NULL,
  `p2` INTEGER(13) DEFAULT NULL,
  `p3` INTEGER(13) DEFAULT NULL,
  `s` INTEGER(13) NOT NULL,
  `p4` INTEGER(13) DEFAULT NULL,
  `p5` INTEGER(13) DEFAULT NULL,
  `p6` INTEGER(13) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY (`s`),
  KEY (`rel_id`),
  KEY (`p3`),
  KEY (`p4`)
    );

以下是查询...

SELECT id, s FROM ref WHERE red_id="$rel_id" AND p3="$p3" AND p4="$p4"

SELECT rel_id, p1, p2, p3, p4, p5, p6 FROM ref WHERE id="$id"

INSERT INTO rel (rel_id, p1, p2, p3, s, p4, p5, p6)
VALUES ("$rel_id", "$p1", "$p2", "$p3", "$s", "$p4", "$p5", "$p6")

以下是一些注释......

  • SELECT将比INSERT更频繁地完成。但是,偶尔我想一次添加几百条记录。
  • 负载方面,几个小时都没有,可能一下子就有几千个查询。
  • 不要以为我可以再标准化(需要组合中的p值)
  • 整个数据库非常关系。
  • 这将是迄今为止最大的表格(下一个最大的约为900k)


更新(08/11/2010)

有趣的是,我已经获得了第二个选择......

而不是192万亿,我可以存储2.6 * 10 ^ 16(15个零,意味着26万亿)......

但在第二个选项中,我只需要将一个bigint(18)存储为表中的索引。就是这样 - 只有一栏。所以我只是检查是否存在值。偶尔添加记录,永远不要删除它们。

所以这让我觉得必须有一个更好的解决方案,然后mysql只是存储数字......

鉴于第二种选择,我应该接受还是坚持使用第一种选择......

[edit]刚刚收到一些测试的消息 - 使用此设置的1亿行在0.0004秒内返回查询[/ edit]

最佳答案

pQd对7PB的估计看似合理,这是RDBMS的大量数据。我不确定我是否听说有人在使用任何共享磁盘系统进行7PB,更不用说MySQL了。
使用任何共享磁盘系统查询此数据量将会非常缓慢。即使在针对大型流式查询进行调整时,最快的SAN硬件最高可达20GB /秒。如果你能负担得起这个规范的SAN硬件,你可以使用比MySQL更适合工作的东西。

事实上,我正在努力设想一个场景,你可以为这个规范的磁盘子系统预算,但不是为了更好的DBMS平台。即使使用600GB磁盘(目前市场上最大的15K'企业级硬盘),您也可以使用12,000个物理磁盘驱动器来存储7PB。 SATA磁盘会更便宜(使用2TB磁盘需要大约1/3的数量),但速度要慢一些。

来自EMC或日立等主要供应商的此规范的SAN将达到数百万美元。上次我使用主要供应商的SAN设备时,IBM DS8000的空间传输成本超过1万英镑/ TB,不包括控制器的任何资本限额。

对于这么多数据,你真的需要一个像Teradata或Netezza这样的无共享系统。对MySQL数据库进行分片可能有效,但我建议使用专门构建的VLDB平台。无共享系统还允许您在节点上使用更便宜的直接连接磁盘 - 看看Sun的X4550(捶击器)平台是否有可能。

您还需要考虑您的性能要求。

  • 查询的可接受运行时间是多少?
  • 您多久会查询一次数据集?
  • 可以使用索引来解析大多数查询(即他们是要查看一小部分 - 比如说:不到1%的数据),还是需要进行全表扫描?< / LI>
  • 数据加载到数据库的速度有多快?
  • 您的查询是否需要最新数据,或者您是否可以使用定期刷新的报告表?

简而言之,针对MySQL的最强有力的论据是,如果可能的话,你将在后空翻中获得超过7PB数据的良好查询性能。这些数据实际上会让您进入无共享区域,以便能够快速地查询它,并且您可能需要一个从一开始就设计用于无共享操作的平台。仅使用磁盘将使任何合理的DBMS平台的成本相形见绌。

注意:如果您确实拆分了运营数据库和报告数据库,则无需为两者使用相同的DBMS平台。从同一个7PB表中获取快速插入和亚秒级报告至少是一项技术挑战。

根据您的评论,您可以在报告中遇到一些延迟,您可能会考虑单独的捕获和报告系统,并且您可能不需要在操作捕获系统中保留所有7PB数据。考虑一个操作平台,例如Oracle(MySQL可以用InnoDB执行此操作)来进行数据捕获(同样,单独使用磁盘的成本会使DBMS的成本相形见绌,除非您拥有 lot 用户)和一个VLDB平台,如Teradata, Sybase IQ, RedBrick, Netezza(注意:专有硬件)或Greenplum报告


相关问答

添加新评论