对于我们的应用程序，我们保留由三个整数列(源，类型和时间)索引的大量数据。加载大量数据会花费一些时间，我们已经采取了各种措施来减少较大查询所要搜索和加载的数据量，例如为不需要高分辨率(时间)的查询存储较大的粒度。 -明智的)。

在我们的备份档案中搜索数据时，数据存储在bzip压缩的文本文件中，但结构基本相同，我注意到将其解压缩到stdout并通过grep通过管道传输要比将其解压缩到磁盘和grep明显要快得多。文件。实际上，untar-to-pipe甚至比仅仅grep未压缩的文件(即打折untar-to-disk)还要快得多。

这让我想知道磁盘I / O的性能影响实际上是否比我想象的要重得多。所以这是我的问题：

我们是否认为将多行的数据放入单行的(压缩)blob字段中并在提取过程中快速搜索单行可能比通过表索引搜索相同的行更快？

例如，代替使用此表

CREATE TABLE data ( `source` INT, `type` INT, `timestamp` INT, `value` DOUBLE);

我会

CREATE TABLE quickdata ( `source` INT, `type` INT, `day` INT, `dayvalues` BLOB );

快速数据中的每一行都有大约100-300行的数据，并在对Blob字段进行解压缩和解码时动态地搜索所需的时间戳。

你能理解这个吗？我应该调查哪些参数？可能会添加哪些字符串？存在哪些DB功能(任何DBMS)可以达到类似的效果？

解决方案

回答

This made me wonder if the performance impact of disk I/O is actually much heavier than I thought.

确实。如果我们必须使用磁盘，那么性能损失要比内存大许多数量级。这让我想起经典的Jim Gray论文《分布式计算经济学》：

Computing economics are changing. Today there is rough price parity between (1) one database access, (2) ten bytes of network traffic, (3) 100,000 instructions, (4) 10 bytes of disk storage, and (5) a megabyte of disk bandwidth. This has implications for how one structures Internet-scale distributed computing: one puts computing as close to the data as possible in order to avoid expensive network traffic.

那么问题是，我们拥有多少数据，我们可以负担多少内存？

而且，如果数据库真的变得很大(即使在20年之内，没人能负担得起这么大的内存)，则我们需要聪明的分布式数据库系统，例如Google的BigTable或者Hadoop。

回答

在数据库上使用Python进行操作时，我也有类似的发现：访问磁盘的成本非常高。事实证明，请求整个数据块并在python中遍历要比创建七个更窄的查询要快得多(即，接近两个数量级)。 (每天有问题的数据之一)

当我获取每小时的数据时，它进一步消失了。全天候24x7的查询！