*
  Мысли   Галерея   Проекты   Тексты  
  Мысли   Галерея   Проекты   Тексты  
Giver: BinData в MongoDB  (2012-03-26 10:00:49)

Удивительное дело обнаружилось при работе с 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]. Так что монго сортирует любые наборы бинарных данных как числа, а не как строки и нет никакого способа поменять это поведение. Так и живем, приходится выравнивать все бинарные записи по одной длине.


Giver: Компрессоры  (2012-01-26 15:25:57)

Решил погонять разные компрессоры и выбрать нужный под конкретную задачу, для этого протестировал тройку самых популярных: 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);

Компрессор Время сжатия Выходной размер Время расжатия Java
gzip 1:02,71 404M 0:11,351 0:11,029
bzip2 4:29,65 204M 1:19,91 3:24,169
xz 14:09,06 136M 0:14,905 0:23,444
xz -1 1:46,64 197M 0:21,330 0:31,429

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