Как сжатие данных более эффективно, чем индексирование для производительности поиска?

В нашем приложении большие объемы данных индексируются тремя целочисленными столбцами (источник, тип и время). Загрузка значительных фрагментов этих данных может занять некоторое время, и мы внедрили различные меры для уменьшения объема данных, которые должны быть найдены и загружены для больших запросов, таких как хранение больших гранулярностей для запросов, которые не требуют высокого разрешения (с точки зрения времени).

При поиске данных в наших архивах резервных копий, где данные хранятся в текстовых файлах bzipped, но имеют в основном ту же структуру, я заметил, что значительно быстрее распаковать stdout и передать его через grep, чем распаковать его на диск и grep файлы. Фактически, untar-to-pipe был даже заметно быстрее, чем просто захват несжатых файлов (т. е. дисконтирование untar-to-disk).

Это заставило меня задуматься, действительно ли влияние производительности дискового ввода-вывода намного тяжелее, чем я думал. Итак, вот мой вопрос:

Считаете ли вы, что помещение данных из нескольких строк в (сжатое) поле 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 строк в данных для каждой строки в quickdata и поиска нужных меток времени на лету во время декомпрессии и декодирования поля blob.

Это имеет смысл для вас? Какие параметры я должен исследовать? Какие ниточки могут быть привязаны? Какие функции DB (любые DBMS) существуют для достижения аналогичных эффектов?