Сжатие избыточных текстовых данных для SQL. Фиксированный словарь?

Question

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

КакВы бы сохранили эти данные в БД?

Держу пари, что 95% + данных являются избыточными от одной записи журнала к следующей.Я запустил LZMA для объединенного текста из 100 записей, и его размер составил 2%.

Текст извлекается для отображения только по первичному ключу.Он никогда не запрашивается для целей фильтрации или поиска.Текст в среднем около 25 КБ для каждой записи.

Если я сожму текст для каждой записи, у меня будет сжатие ~ 10% ... против сжатия 2% (для объединенных 100 записей).

В идеале, я 'Мне бы хотелось использовать какой-то фиксированный словарь, сгенерированный из огромного количества существующих данных.

Мы используем SQL 2005. Я знаю, что в SQL 2008 есть опции сжатия на уровне строк и страниц ... но мы получаем весь наш клиентВ настоящее время база для обновления неосуществима.

Мысли?спасибо!

ОБНОВЛЕНИЕ: Вот что я сделал.После недели чтения эксперимента я написал процедуру для создания словаря строк в стиле LZW на объединенном тексте из 1000 записей.Затем я расставил приоритеты для словаря различными способами, включая: - общую ожидаемую экономию (в байтах, путем подстановки) - ожидаемую экономию, включая только записи словаря, присутствующие 1 или меньше раз на запись.из словарных записей X (между 100 и 1000) с наивысшим приоритетом в выборочной записи.Затем использовали LZMA alg.чтобы сжать закодированный вывод.

Играя с различными конфигурациями для словаря ... Я обнаружил, что в лучшем случае я могу улучшить сжатие LZMA примерно на 1%.В большинстве случаев я ввожу больше энтропии, чем извлекаю, поэтому закодированные сжатые данные LZMA на больше , чем исходные сжатые данные с LZMA.

Я определил, что естьбольше избыточностей в тексте каждой записи, которые могут быть использованы LZMA, чем между строками.

Так что, скорее всего, я просто LZMA весь текст и назову это день.

Answer 1

Единственный способ, которым я могу думать о выполнении этого типа сжатия в SQL 2005, - это создание собственной инфраструктуры с вашими собственными объектами SQL CLR.Это было бы довольно сложным решением, но оно может работать для ваших целей.Обновление до SQL 2008 может быть намного проще и экономичнее.

Функции и / или триггеры SQL CLR можно использовать для управления операциями сжатия и распаковки в рассматриваемой таблице ... производительность может быть ниже оптимальной, Я не знаю.Вам также понадобятся утилиты для управления словарями.Может быть создано какое-то плановое обслуживание, которое будет регулярно обновлять и оптимизировать фиксированный словарь (при необходимости).

Хотя это не является прямым решением вашей проблемы, я думаю, что вам может быть интересна следующая статья о проекте кода -

Использование интеграции CLR для сжатия BLOB / CLOB в SQLServer 2005

Как видите, автор статьи очень умно использует SQL CLR для решения другой проблемы сжатия в SQL 2005.

Answer 2

Если это в основном один и тот же текст, возможно, можно использовать более реляционный подход, при котором вы сохраняете диапазон выходных сообщений в БД и имеете таблицу с messageID и различными параметрами, которые делают сообщение уникальным?