Удивительное дело обнаружилось при работе с MongoDB. При вставке бинарных данных и попытке их отсортировать получался совершенно рандомный порядок. Что же делать, пришлось открыть исходный код и удивиться:

   case BinData: {
            int lsz = l.objsize(); // our bin data size in bytes, not including the subtype byte
            int rsz = r.objsize();
            if ( lsz - rsz != 0 ) return lsz - rsz;
            return memcmp(l.value()+4, r.value()+4, lsz+1);
        }

То есть записи сортируются сначала по размеру, а только потом по содержанию, и набор данных [11,2,333] будет отсортирован как [2,11,333]. Так что монго сортирует любые наборы бинарных данных как числа, а не как строки и нет никакого способа поменять это поведение. Так и живем, приходится выравнивать все бинарные записи по одной длине.

Решил погонять разные компрессоры и выбрать нужный под конкретную задачу, для этого протестировал тройку самых популярных: gzip, bzip2, xz. Все испытания были проведены на одном и том же репрезентативном файле размером 1.6gb в tmpfs, то есть скорость винчестера никак не могла повлиять. Замеры производились с помощью команды time cat data.in | [gzip|bzip2|xz] < data.out, а распаковка с помощью [zcat|bzcat|xzcat] data.out < /dev/null. Так же немаловажным фактором для меня была скорость распаковки средствами Java. Тестовый код: byte[] buf = new byte[4096]; while (zis.available() > 0) zis.read(buf);

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