Заправка компрессора zlib для большого количества похожих пакетов?

Question

Возможно ли «заправить» компрессор zlib (или какой-либо другой механизм сжатия с открытым исходным кодом), подав ему набор общих строк, чтобы повысить эффективность сжатия большого количества очень похожих текстовых пакетов один за другим?

Я пытаюсь улучшить мою схему для регистрации миллионов XML-пакетов, которые не только очень избыточны, но и очень похожи. Обычно количество байтов, измененных между сообщениями, составляет менее одного процента. Тем не менее, одной из целей ведения журнала является устранение неполадок полуквалифицированных клиентских приложений. Вот почему я не могу просто пойти и нормализовать сообщения или извлечь только важную информацию: сообщения должны регистрироваться точно так же, как они попали по проводу, байт для байта.

В настоящее время единственным способом использования избыточности между сообщениями является объединение большого количества их вместе в один сжатый пакет, скажем 100 или 1000, или стоимость всего дня. Однако это сделает логику регистрации слишком сложной для моего вкуса и гораздо менее надежной. Не говоря уже о трудностях, связанных с параллельными процессами и произвольным доступом к конкретным сообщениям.

Вот почему я подумал, что могу взять некоторый поток компрессора и передать ему кучу общих строк P, чтобы получить сжатый текст ZP, а затем разработать стабильный префикс, подав ему сообщение P + [i] для некоторых i и сравнивая сжатые результаты с ZP. То, что входит в базу данных, будет сжатым текстом без общего префикса, а затем известный общий префикс будет повторно добавлен перед распаковкой. После декомпрессии я бы взял часть после общего префикса P, очевидно.

Некоторые тесты показывают, что увеличение степени сжатия будет один или два порядка для небольших сообщений, но, к сожалению, такой трюк не работает с методом Zlib выкачать ...

Существуют ли другие способы получения аналогичных улучшений (требования к хранилищу сокращены на порядок) без хлопот упомянутого выше метода связывания сообщений? В идеале интерфейс должен быть просто foo_deflate (text) и foo_inflate (compression_text), при этом вся обманка скрыта внутри реализации этих двух функций. Я не боюсь выбить компилятор и заразиться, но вся сложность должна быть ограничена модулем сжатия. Другими словами, единственным приемлемым изменением интерфейса является изменение имени для функций дефляции/раздувания. Метод связывания не соответствует этому требованию и добавляет множество скрытых осложнений.

Вот пример того, что сообщения выглядят, переформатировать для удобства чтения и слегка взломан, чтобы защитить виновных:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> 
    <SOAP-ENV:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xmlns:xsd="http://www.w3.org/2001/XMLSchema" > 
     <foobarMeowMeow xmlns="http://bungle-and-botch.com/spec/abrechnungsservice/types"> 
      <foobarMeowHiss xmlns=""> 
       &lt;?xml version="1.0" encoding="iso-8859-15"?&gt; 
       &lt;foobarMeowHiss xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
        xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
        xmlns="http://bungle-and-botch.com/spec/abrechnungsservice"&gt; 
       &lt;woeM&gt; 
       ... 
       &lt;/woeM&gt; 
       &lt;foobarMeowHiss;&gt; 
      </foobarMeowHiss> 
      <foobarHissMeow> 
       &lt;?xml version="1.0" encoding="iso-8859-15"?&gt; 
       &lt;foobarHissMeow xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
        xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
        xmlns="http://bungle-and-botch.com/spec/abrechnungsservice"&gt; 
       &lt;jbrZ;&gt; 
       ... 

Answer 1

Ответ, который уже размещен в Is there a way to store gzip's dictionary from a file?.

Магическая функция даже объясняется в zlib manual которой я не РТФ достаточно thouroughly:

int deflateSetDictionary (z_streamp strm, const Bytef *dictionary, uInt dictLength); 

покаянием.