3

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

在我们的备份存档中搜索数据时，数据存储在 bzip 压缩文本文件中，但结构基本相同文件。事实上，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 字段的解压缩和解码期间动态搜索所需的时间戳。

你能理解这个吗？我应该调查哪些参数？可能附加什么条件？存在哪些 DB 功能（任何 DBMS）来实现类似的效果？

4

2 回答 2

4

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

确实。如果你必须去磁盘，性能损失比内存大很多数量级。这让我想起了经典的 Jim Gray 论文，分布式计算经济学：

计算经济学正在发生变化。如今，(1) 一次数据库访问、(2) 10 字节网络流量、(3) 100,000 条指令、(4) 10 字节磁盘存储和 (5) 1 兆磁盘带宽之间的价格大致相当。这对如何构建互联网规模的分布式计算有影响：将计算尽可能靠近数据，以避免昂贵的网络流量。

那么，问题是你有多少数据，你能负担多少内存？

如果数据库变得非常大——就像在 20 年后没有人能负担得起这么多内存——你需要聪明的分布式数据库系统，比如谷歌的BigTable或Hadoop。

于 2008-08-25T13:43:41.643 回答
0

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

当我获得每小时数据时，它进一步爆发。24x7 的大量查询！

于 2008-08-25T14:12:29.657 回答