Истории о данных: завершающий штрих
❤ 512 , Категория: Новости, ⚑ 14 Авг 2017гСжатие в базе данных?
Если бы я, как это часто бывает, не смог модифицировать приложение, мне пришлось бы заменить таблицу представлением с тем же именем и выполнить компрессию и декомпрессию данных внутри базы данных. Однако не забывайте, что в большинстве случаев такую работу лучше выполнять вне базы данных. Однако, если по каким-то причинам это нужно делать внутри базы данных, руководствуйтесь настоящим разделом.
Одна из примечательных новых особенностей версии SQL Server 2016 состоит в том, что в нее включены собственные функции COMPRESS () и DECOMPRESS (). Именно благодаря им новая ревизия данной СУБД стала такой яркой, как светодиодная лента (приобрести ее, кстати, можно тут). Подробное описание оператора утверждения COMPRESS можно найти в руководстве по адресу: msdn.microsoft.com/en-us/library/mt622775.aspx. Подробное описание утверждения DECOMPRESS содержится в руководстве по адресу: msdn.microsoft. com/en-us/library/mt622776.aspx. Если бы наш клиент к тому времени использовал версию SQL Server 2016, это было бы просто, но, увы, в его распоряжении была более старая версия системы.
В версиях, которые поддерживают технологию SQLCLR, функции для выполнения компрессии создаются относительно просто. Пример кода для решения этой задачи приведен в коде ниже.
Файлы изображений в PDF
Итак, объем данных, хранящихся в базе данных, сократился до 880 Гбайт. Из них 350 Гбайт использовалось для хранения файлов PDF в столбцах формата varchar (max). Эти файлы тоже заслуживали внимания.
Разумеется, работа с файлами PDF не входит в круг тем, связанных с эксплуатацией SQL Server, и все же есть смысл уделить внимание модификациям, которым мы подвергли упомянутые файлы.
• Разрешение текста было сокращено с 1200×1200 до 150×150 точек на дюйм. Даже при использовании разрешения 75×75 точек
на дюйм я не встречал ни одного пользователя, который был бы способен увидеть разницу.
• Существующие в новых файлах изображения TIFF были заменены более миниатюрными (и высококачественными) изображениями PNG. Это не только привело к уменьшению размеров, по и позволило повысить качество увеличенных картинок. Такое изменение нельзя было осуществить в старых файлах. В них я понижал качество хранимых изображений с помощью функций из библиотеки PDF до тех пор, пока не достигал приемлемого баланса размера и качества.
• Ненужные шрифты, которые хранились буквально в каждом файле PDF, были удалены.
В результате объем данных в PDF, изначально составлявший 350 Гбайт, сократился до 120 Гбайт. В большинстве случаев у нас имеется ряд возможностей для сокращения общего объема баз данных, и выше я уже писал о том, почему достижение этой цели имеет столь важное значение. Но вернемся к нашей клиентской базе данных. Сокращение общего объема базы данных с 3,8 Тбайт до 550 Гбайт обеспечило выполнение следующих модификаций:
• реализация сбалансированного подхода к выбору алгоритмов ROW и PAGE при сжатии данных;
• сжатие объемных строковых данных;
• сокращение размеров изображений в формате PDF.
С точки зрения нашего клиента это было значительным достижением. Наконец, финальная (и, можно сказать, неожиданная) выгода состояла в том, что теперь база данных почти полностью умещалась в памяти. Система клиента была оснащена оперативной памятью объемом 512 Гбайт. Так что вы можете себе представить, насколько повысились в результате такие показатели, как общая производительность и степень управляемости.
