4

У меня есть столбец, в котором я хотел бы хранить много текстовых данных в (XML-данных). Примерно 8000 символов в строке и около 100-500 строк в минуту.Сжатие уровня столбца в SQL Server

Значительное количество данных означает, что я буду достаточно агрессивно очищать колонку. (Поскольку мне нужно разместить мой SQL Server в SAN нашей компании, объем памяти довольно дорог.) Но если я смогу найти способ сжать эти данные, я смогу сохранить его дольше.

Я видел вещи, как эта статья на using CLR Integration to compress BLOBs в SQL 2005.

Я также видел инструмент SQLCompress.NET для SQL Server 2005.

И, кажется, говорят, что они делают именно то, что я хочу. Сжатие данных одного столбца при его сохранении.

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

Итак, вот мой вопрос. Я использую SQL Server 2008 R2. Будет ли любой из этих решений SQL Server 2005 работать для меня хорошо?

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

Примечание: Row Compression и Page Сжатие не поможет то, что мне нужно (. По крайней мере, насколько я могу могу видеть) Строка Сжатие хранение данных фиксированной длиной в поле переменной длиной и сжатии страниц уменьшают случаи избыточности данные. Ни один из них не поможет с большими блоками текста.

ПРИМЕЧАНИЕ II: Я видел это question, но его ответ использует сжатие строк и страниц или FILESTREAM. Я не хочу использовать FILESTREAM, потому что теряю способность зеркалировать мою базу данных.

+0

Что вы используете для записи данных (и считывать данные из SQL Server)? Некоторые приложения C#? –

+0

@ChrisShain - я использую приложение C# (WCF/NServiceBus, размещенное в IIS), чтобы написать ему. Я использую SSMS для его чтения. – Vaccano

+1

Учитывая текущие два ответа, может кто-то прокомментировать «Я мало знаю о CLR Integration, кроме того, что слышал, что это может вызвать проблемы»? Недавно я использовал интеграцию CLR (не зная об этом, признаюсь), и проблем не было. – bfavaretto

ответ

0

Я думаю, что, используя вашу лучшую ставку, вы должны либо использовать клиентскую библиотеку для сжатия и распаковки данных, прежде чем помещать их в SQL Server, и если вы хотите запросить конкретные элементы или атрибуты XML, вы можете извлечь те и хранить их в отдельных столбцах или нормализованных строках (которые вы хотите делать в любом случае - запросы больших столбцов текста XML, особенно для вложенных элементов, - это slow).

+0

Мне не нужно запрашивать внутри XML, просто получите весь XML в запросе SSMS. (Как если бы это были обычные текстовые данные.) Я бы предпочел не сжимать на стороне клиента, потому что тогда я не могу использовать SSMS для просмотра данных. Является ли сжатие уровня столбца с использованием CLR-интеграции плохим идеей? Это необычная территория для SQL Server? – Vaccano

+0

Когда клиент сжимает и декомпрессирует. Не так хорошо, как сжатие столбцов в SQL Server, но я возьму то, что могу получить. – Vaccano

0

Вы можете попробовать использовать фильтр для хранения XML-документов и использовать NTFS для их сжатия.

Смотрите эту artcle

Using Filestream in SQL2008

+1

Увы, когда вы используете FileStream, вы теряете способность зеркалировать вашу базу данных. Это функция, которую мне нужны администраторы баз данных. В противном случае, я бы выбрал это решение. – Vaccano

Смежные вопросы