Question

对于我们的应用程序，我们保留大量数据，这些数据由三个整数列（源，类型和时间）索引。加载大量数据可能需要一些时间，我们已经实施了各种措施来减少为更大的查询搜索和加载的数据量，例如为不需要高分辨率的查询存储更大的粒度（时间-wise）。

在我们的备份存档中搜索数据时，数据存储在bzip压缩文本文件中，但结构基本相同，我注意到通过grep解压缩stdout并通过grep将其解压缩要快得多磁盘和grep文件。事实上，对于未经压缩的文件（即将文档折扣到磁盘上）来说，无管道甚至要快得多。

这让我想知道磁盘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 );

在quickdata中为每一行提供大约100-300行数据，并在解压缩和解码blob字段期间动态搜索所需的时间戳。

这对你有意义吗？我应该调查哪些参数？可以附加什么字符串？存在哪些DB功能（任何DBMS）以实现类似的效果？

Answer 1

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

当然。如果你必须转到磁盘，性能命中比内存大许多个数量级。这让我想起了经典的吉姆格雷论文，Distributed Computing Economics：

计算经济学正在发生变化。今天（1）一个数据库访问，（2）十个字节的网络流量，（3）100,000个指令，（4）10个字节的磁盘存储，以及（5）一个兆字节的磁盘带宽之间存在粗略的价格平价。这对于如何构建互联网规模的分布式计算具有影响：一个将计算尽可能接近数据，以避免昂贵的网络流量。

那么，问题是你拥有多少数据以及你能承受多少内存？

如果数据库真的大 - 就像在没有人能够承受这么多内存的情况下，即使在20年内 - 你需要聪明的分布式数据库系统，如Google的BigTable或{ {3}}

Answer 2

我在Python上使用数据库时发现了类似的发现：访问磁盘的成本非常非常高。事实证明，要求整个数据块并在python中迭代它比创建七个更窄的查询要快得多（即接近两个数量级）。（数据每天一个）

当我获得每小时数据时，它进一步爆炸了。很多24x7很多查询！