database - 数据压缩如何比索引更有效地提高搜索性能？

Question

对于我们的应用程序，我们将大量数据保存在三个整数列(来源、类型和时间)的索引中。加载大量数据可能需要一些时间，我们已经实现了各种措施来减少必须为更大的查询搜索和加载的数据量，例如为不需要高分辨率的查询存储更大的粒度(时间-明智的)。

当在我们的备份文件中搜索数据时，数据存储在 bzip 文本文件中，但结构基本相同，我注意到解压缩到标准输出并通过 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 );

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

这对你来说有意义吗？我应该研究哪些参数？可能附加什么条件？存在哪些数据库功能(任何 DBMS)可以实现类似的效果？

Answer 1

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

当然。如果你必须去磁盘，性能损失比内存大很多数量级。这让我想起了经典的 Jim Gray 论文，Distributed Computing Economics :

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 .