SQL.RU
 client/server technologies
 Главная | Документация | Статьи | Книги | Форум | Блоги | Опросы | Гостевая | Рассылка | Работа | Поиск | FAQ |

Почему нежелательно использовать компрессию файлов баз данных и журналов SQL Server

ПУБЛИКАЦИИ  

По материалам статьи Ken Henderson: Why you shouldn't compress SQL Server data and log files
Перевод Ирины Наумовой

Наиболее опытные SQL Server DBA знают, что не стоит использовать автоматическое сжатие файлов данных и журналов, но я могу поспорить, что лишь немногие из них знают, почему это является таким уж плохим решением. Основным ответом на этот вопрос может быть "снижение производительности", и это правильно, но предположение о том, что производительность снижается из-за сжатия \ декомпрессии данных, это только отчасти правильное утверждение. Есть еще более важная причина.
Дело в том, что SQL Server связывает все операции ввода - вывода в файлы данных и журналов внутренним планировщиком потоков SQL Server (UMS). UMS позволяет SQL Server самому управлять выполнением операций ввода - вывода, не делая прямые вызовы WIN 32 API. Такой подход позволяет поддерживать нити, без дополнительного кода программ, реализующих потоки и нити, что предоставляет возможность работать в версиях Windows, которые не поддерживают асинхронный ввод - вывод в файл (Win9x, WinME) без написания дополнительного кода для реализации асинхронного и синхронного ввода - вывода. Повторю, что SQL Server использует способность NT выполнять операции ввода - вывода асинхронно и исполнять ввод - вывод случайным образом или одновременно (scatter / gather). Windows 9x/ME не поддерживает ни асинхронный ввод/вывод, ни технологию scatter / gather. Если абстрагироваться от UMS, SQL Server просто планирует работу, которую нужно сделать, и UMS выполняет это наиболее эффективным способом.
Один из нюансов асинхронного ввода - вывода в Windows состоит в том, что, в зависимости от того используете ли Вы API или нет, на самом деле Вы можете и не добиться асинхронного выполнения операции от операционной системы. Другими словами, хотя Вы запрашиваете асинхронное выполнение операции, Windows все же может выполнить ее синхронно и может удерживать ваш вызов API, пока операция не завершится. Относительно целесообразности выполнения асинхронного ввода-вывода решение принимает операционная система. Что произойдет, если Windows решит не выполнять запрос на асинхронный ввод - вывод, зависит от API. В случае использования функций ReadFile/WriteFile, происходит блокирование ресурсов до тех пор, пока операция не завершится и вернет значение TRUE. Вы должны отслеживать возвращаемые значения и действовать в соответствии с полученным результатом - Вы не можете написать код, который ожидает, что операция завершит в некоторый момент в будущем, если операция в действительности закончилась немедленно. При использовании ReadFileEx/WriteFileEx, использование API отрабатывает неверно - поскольку эти два API не поддерживают синхронный ввод - вывод. Если операция, которая была запрошена, не может быть выполнена асинхронно, она не будет выполнено вообще, если при этом вызывались ReadFileEx или WriteFileEx.
На Win9x/ME, UMS автоматически выполняет весь ввод - вывод в файла в синхронном режиме. Он знает, что данная версия Windows не поддерживает асинхронный ввод - вывод и поэтому выбирает соответствующий режим для выполнения операций ввода- вывода. Для NT, он всегда пытается выполнять операции ввода - вывода асинхронно, но, как я уже сказал, Windows может принять решение выполнять операции ввода / вывода в синхронном режиме.
Единственный вариант, при котором Windows никогда не использует асинхронный ввод - вывод, это когда чтение\запись производятся в сжатый файл. При выполнении ReadFile или WriteFile из сжатого файла, Windows всегда выполняет операцию синхронно, независимо от того, требовала ли вызывающая программа асинхронную операцию ввода - вывода. Это всегда истинно: сжатие файла отключает способность приложения производить чтение или запись в него асинхронно.
Таким образом, мало того, что Вы платите за сжатие/декомпрессию, когда используете сжатие файлов баз данных и журналов, но еще платите за переключения между асинхронным и синхронным вводом - выводом, и это изменение может привести к большой разнице в производительности RDBMS, таких как SQL Server. Даже если не обращать внимание на то, что теряемая функциональность является залогом надежности SQL Server, снижение производительности редко того стоит, и это даже если не брать во внимание то, как сжатие затрагивает надежность и восстанавливаемость системы. Жесткие диски достаточно дешевы, поэтому лучше не используйте сжатие данных и журналов, если только у Вас нет другого выбора.

[В начало]

Перевод: Ирины Наумовой  2005г.

Rambler's Top100 Рейтинг@Mail.ru  Administrator: Обратная связь 
Copyright: SQL.Ru 2000-2013