SQL Server. Диета для баз данных: сжатие строк и реализация сжатия типа ROW
Содержание:
1. Сжатие в операционной системе;
2. Сжатие строк и реализация сжатия типа ROW (Вы читаете данный раздел);
3. Применение сжатия типа ROW.
Внесение этого изменения в десятичное значение часто приводит к заметному уменьшению размера базы данных без негативных последствий для производительности. На самом деле производительность даже слегка повышается, поэтому почему бы не пойти этим путем?
В версии SQL Server 2008 появилось два типа сжатия таблиц: ROW и PAGE. К сожалению, указанные возможности имеются только в редакции Enterprise Edition, но клиент, о котором идет речь в статье, располагает Enterprise Edition. Хотелось бы, чтобы сжатие таблиц было доступно и в других выпусках. Впрочем, используя "костыли", вполне можно реализовать данные типы сжатия и в других редакция, однако на это вам придется посидеть за компьютером пару-тройку часов, - если в процессе у вас заболит копчик, тогда обязательно прочитайте статью по адресу http://spinous.ru/pain/pri-kakix-boleznyax-bolit-kopchik-pri-dlitelnom-sidenii.html (http://spinous.ru/pain/pri-kakix-boleznyax-bolit-kopchik-pri-dlitelnom-sidenii.html).
При сжатии типа ROW изменяется способ хранения содержимого строки, чтобы разместить больше строк на одной странице. Клиенты часто удивляются, что таким образом удается повысить производительность приложений, но тому есть несколько причин.
• Если база данных совершает много операций ввода-вывода, то любые меры, способствующие снижению интенсивности ввода-вывода, обычно благоприятно отражаются на производительности. Например, если удается уменьшить размер строк на 30%, то на 30% снижается объем данных, пересылаемых в процессе ввода-вывода. Очевидно, ситуация может измениться в случае преобладающей нагрузки на процессор, но у большинства моих клиентов системы ориентированы на ввод-вывод.
• Для таблиц на диске, поскольку в буферах SQL Server хранятся копии страниц базы данных, больше строк данных теперь входит в те же буферы. Это означает, что больше строк размешается в памяти сервера, без сопутствующего увеличения доступной памяти.
• Обработка каждой страницы сопряжена с увеличением нагрузки на процессор, но возможности большинства серверов ограничиваются операциями ввода-вывода при обилии ресурсов процессора. Мне приходилось наблюдать ситуации, в которых нагрузка на процессор снижалась при сжатии таблиц.
Я могу объяснить это только тем обстоятельством, что, несмотря на увеличение затрат на обработку одной страницы, число обрабатываемых страниц уменьшается.
• Первое изменение заключается в уменьшении количества метаданных, связанных с каждой строкой (в частности, сведений о столбцах и их длине).
• Следующее изменение распознает, что многие столбцы пусты или содержат нулевое значение. Хранение таких столбцов оптимизировано до такой степени, что нулевые значения и NULL вообще не занимают места.
• Еще одно изменение относится к типу vardecimal. Vardecimal устранен, и для числовых типов используются форматы хранения переменной длины (smallint, int, bigint, decimal, numeric, smallmoney, money, float, real, timestamp/rowversion). Эффективность хранения улучшается благодаря сокращению метаданных и уменьшению размеров некоторых значений, относящихся к дате (datetime, datetime2, datetimeoffset).
• Строковые значения в целом остаются прежними, но конечные символы заполнения удалены из значений типов char и nchar.
• Конечные нули удалены из двоичных значений.
Как выяснилось, сжатие типа ROW удивительно эффективно. В большинстве таблиц транзакционной системы сокращение достигало приблизительно 30%.
1. Сжатие в операционной системе;
2.
3. Применение сжатия типа ROW.
Внесение этого изменения в десятичное значение часто приводит к заметному уменьшению размера базы данных без негативных последствий для производительности. На самом деле производительность даже слегка повышается, поэтому почему бы не пойти этим путем?
В версии SQL Server 2008 появилось два типа сжатия таблиц: ROW и PAGE. К сожалению, указанные возможности имеются только в редакции Enterprise Edition, но клиент, о котором идет речь в статье, располагает Enterprise Edition. Хотелось бы, чтобы сжатие таблиц было доступно и в других выпусках. Впрочем, используя "костыли", вполне можно реализовать данные типы сжатия и в других редакция, однако на это вам придется посидеть за компьютером пару-тройку часов, - если в процессе у вас заболит копчик, тогда обязательно прочитайте статью по адресу http://spinous.ru/pain/pri-kakix-boleznyax-bolit-kopchik-pri-dlitelnom-sidenii.html (http://spinous.ru/pain/pri-kakix-boleznyax-bolit-kopchik-pri-dlitelnom-sidenii.html).
При сжатии типа ROW изменяется способ хранения содержимого строки, чтобы разместить больше строк на одной странице. Клиенты часто удивляются, что таким образом удается повысить производительность приложений, но тому есть несколько причин.
• Если база данных совершает много операций ввода-вывода, то любые меры, способствующие снижению интенсивности ввода-вывода, обычно благоприятно отражаются на производительности. Например, если удается уменьшить размер строк на 30%, то на 30% снижается объем данных, пересылаемых в процессе ввода-вывода. Очевидно, ситуация может измениться в случае преобладающей нагрузки на процессор, но у большинства моих клиентов системы ориентированы на ввод-вывод.
• Для таблиц на диске, поскольку в буферах SQL Server хранятся копии страниц базы данных, больше строк данных теперь входит в те же буферы. Это означает, что больше строк размешается в памяти сервера, без сопутствующего увеличения доступной памяти.
• Обработка каждой страницы сопряжена с увеличением нагрузки на процессор, но возможности большинства серверов ограничиваются операциями ввода-вывода при обилии ресурсов процессора. Мне приходилось наблюдать ситуации, в которых нагрузка на процессор снижалась при сжатии таблиц.
Я могу объяснить это только тем обстоятельством, что, несмотря на увеличение затрат на обработку одной страницы, число обрабатываемых страниц уменьшается.
Как реализовано сжатие типа ROW?
• Первое изменение заключается в уменьшении количества метаданных, связанных с каждой строкой (в частности, сведений о столбцах и их длине).
• Следующее изменение распознает, что многие столбцы пусты или содержат нулевое значение. Хранение таких столбцов оптимизировано до такой степени, что нулевые значения и NULL вообще не занимают места.
• Еще одно изменение относится к типу vardecimal. Vardecimal устранен, и для числовых типов используются форматы хранения переменной длины (smallint, int, bigint, decimal, numeric, smallmoney, money, float, real, timestamp/rowversion). Эффективность хранения улучшается благодаря сокращению метаданных и уменьшению размеров некоторых значений, относящихся к дате (datetime, datetime2, datetimeoffset).
• Строковые значения в целом остаются прежними, но конечные символы заполнения удалены из значений типов char и nchar.
• Конечные нули удалены из двоичных значений.
Как выяснилось, сжатие типа ROW удивительно эффективно. В большинстве таблиц транзакционной системы сокращение достигало приблизительно 30%.
