mysql 万亿数据,Mysql：处理192万亿条记录…（是，192万亿条）

pQd对7PB的估计似乎是合理的，而对于RDBMS来说，这是很多数据。我不确定我是否听说过有人使用任何共享磁盘系统执行7PB，更不用说MySQL。用任何共享磁盘系统查询此数据量将变得非常缓慢。即使针对大型流查询进行了调整，最快的SAN硬件也可以达到20GB /秒的速度。如果您负担得起该规格的SAN硬件，则可以尝试使用比MySQL更适合该工作的东西。

实际上，我正在努力设想一个方案，在该方案中，您可以为该规格的磁盘子系统安排预算，但没有更好的DBMS平台预算。即使使用600GB磁盘(当前市场上最大的15K“企业”驱动器)，您仍需要约12,000个物理磁盘驱动器来存储7PB。SATA磁盘会更便宜(而使用2TB磁盘则需要大约1/3的磁盘)，但速度要慢得多。

来自主要供应商(如EMC或Hitachi)的这种规格的SAN可能要花费数百万美元。上次我与一家主要供应商的SAN设备一起使用时，IBM DS8000上的空间转移成本超过1万英镑/ TB，这不包括控制器的任何资本补贴。

您真的需要像Teradata或Netezza这样的无共享系统来处理大量数据。分片MySQL数据库可能有效，但我建议使用专用的VLDB平台。无共享系统也使您可以在节点上使用便宜得多的直接连接磁盘-看看Sun的X4550(thumper)平台是否可行。

您还需要考虑性能要求。

查询可接受的运行时间是多少？

您将多久查询一次数据集？

是否可以使用索引来解决大多数查询(即它们将只查看一小部分数据(例如：少于1％的数据))，还是需要进行全表扫描？

数据要多快被加载到数据库中？

您的查询是否需要最新数据，还是可以使用定期刷新的报表？

简而言之，针对MySQL的最强论据是，如果有可能，您将进行反向翻转以在7PB的数据上获得不错的查询性能。如此大量的数据确实使您进入了无共享领域，可以进行一些合理的查询，并且从一开始就可能需要一个专为无共享操作而设计的平台。单凭磁盘将使任何合理的DBMS平台的成本相形见war。

注意：如果确实要拆分运营数据库和报告数据库，则不必为这两个数据库使用相同的DBMS平台。从同一个7PB表中获取快速插入和亚秒级的报告至少将是一项技术挑战。

从您的评论中可以看出，报告可能会存在一些延迟，您可以考虑使用单独的捕获和报告系统，并且可能不需要将所有7PB数据保留在您的操作捕获系统中。考虑一个用于数据捕获的操作平台，例如Oracle(MySQL可以使用InnoDB进行此操作)(同样，除非您有很多用户，否则单独的磁盘成本将使DBMS的成本相形见))和诸如Teradata， Sybase 的VLDB平台IQ，RedBrick， Netezza(注：专有硬件)或Greenplum用于报告