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

Question

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

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

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

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

Например, вместо этой таблицы

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

Я бы получил

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

с приблизительно 100-300 строками данных для каждой строки в быстрых данных и поиском нужных временных меток на лету во время распаковки и декодирования поля большого двоичного объекта.

Имеет ли это для вас смысл? Какие параметры я должен исследовать? Какие строки могут быть прикреплены? Какие функции БД (любая СУБД) существуют для достижения аналогичных эффектов?

Answer 1

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

Определенно. Если вам нужно перейти на диск, производительность падает на много порядков больше, чем память. Это напоминает мне классическую бумагу Джима Грея Distributed Computing Economics :

Компьютерная экономика меняется. В настоящее время существует приблизительный ценовой паритет между (1) одним доступом к базе данных, (2) десятью байтами сетевого трафика, (3) 100 000 инструкций, (4) 10 байтами дискового хранилища и (5) мегабайтом полосы пропускания диска. Это имеет значение для того, как структурировать распределенные вычисления в масштабе Интернета: каждый размещает вычисления как можно ближе к данным, чтобы избежать дорогостоящего сетевого трафика.

Тогда возникает вопрос, сколько у вас данных и сколько памяти вы можете себе позволить?

И если база данных становится действительно большой - как никто никогда не мог бы позволить себе столько памяти, даже через 20 лет - вам нужны умные системы распределенных баз данных, такие как BigTable от Google или Hadoop .

Answer 2

Я сделал подобное открытие, работая в Python над базой данных: стоимость доступа к диску очень, очень высока. Оказалось, что гораздо быстрее (т.е. почти на два порядка) запросить целый кусок данных и выполнить итерацию по ним в python, чем создать семь запросов, которые были уже (Один раз в день для данных)

Это взорвалось еще дальше, когда я получал почасовые данные. 24x7 много запросов это много!