Сердцем хорошей СУБД является надежная и производительная подсистема ввода/вывода. Поэтому проектирование подсистемы ввода/вывода — важная тема при создании любого приложения с использованием VLDB.
На самом высоком уровне абстракции определение требований к системе является простым делом, поскольку все мы желаем трех вещей:
производительности, надежности и низкой
стоимости. Однако когда мы преобразуем эти общезначимые цели во что-то конкретное, мы сталкиваемся с решениями, основанными на компромиссах. Для понимания возникших конфликтов, Вы должны сделать две вещи: (1) понять Ваши цели и (2) разобраться в Ваших технологиях. Весь фокус заключается в поиске верной микстуры из скорости, надежности и стоимости, которая удовлетворит специфичные нужды Вашего бизнеса. Это означает что решение, верное для Вас, не всегда будет подходящим для Вашего соседа.
Архитектурные ограничения приходят к нам из двух источников: (1) это экономические ограничения и (2) это технологические ограничения. Экономические ограничения Вам должны быть ясны очень хорошо, и я уверен, Вы не желаете иметь с ними дело. Однако, даже если вообразить, что Вы можете приобрести любое оборудование и программное обеспечение, какое только пожелаете, Вы все равно столкнетесь с ограничениями технологическими.
Предположим, к примеру, что Вы имеете OLTP-приложение и Вы оптимизировали дисковую конфигурацию Вашего сервера Oracle для достижения максимальной производительности при случайном вводе/выводе в ущерб производительности последовательного доступа к данным. Такое решение может выглядеть вполне разумным, поскольку доступ к файлам OLTP-базы данных в подавляющем большинстве основан на операциях чтения с использованием хорошо определенных индексов или хэш-структур, а также произвольных (scattered) операциях записи.
Однако первый же опыт реорганизации индекса на дисковом массиве, оптимизированном исключительно для доступа в условиях высокого параллелизма, потребует на 300–500 процентов больше времени, чем это могло бы занять в другой дисковой конфигурации. Ваше бескомпромиссное решение об оптимизации OLTPпроизводительности напрямую снизит доступность Вашей системы вследствие увеличения продолжительности недоступности индекса во время его реорганизации.
Этот пример, как сотни подобных, указывают нам на важность и трудоемкость понимания Ваших требований и постижения Ваших технологий. Наиболее важным Вашим инструментом должен стать метод структурного анализа, который поможет Вам найти правильные ответы на Ваши вопросы. В этой статье мы будет структурировать анализ конструкции подсистемы ввода/вывода с помощью разбиения на производительность, доступность и стоимость:
-
Производительность
- Скорость случайного чтения
- Скорость случайной записи
- Скорость последовательного чтения
- Скорость последовательной записи
- Влияние параллелизма
-
Доступность
- Частота отказов
- Продолжительность простоя
- Снижение производительности при отказах
-
Стоимость
- Стоимость приобретения
- Стоимость обслуживания
В статье мы оценим несколько инструментов и техник в контексте этих категорий. Их описание дано в последующих разделах.
- Производительность случайного чтения — примером могут служить запрос с использованием индексов или хэш-структур, чтение из сегментов отката. По-видимому, эта категория составляет основную массу вызовов операций чтения в высокоактивной OLTP-системе. Для хранилищ данных, эта категория представляет лишь незначительную часть от общей нагрузки.
- Производительность случайной записи — примером могут служить все операции записи данных, индексов и сегментов отката процессом DBWR. Эта категория составляет существенную часть общей массы операций записи в OLTP-системах в период основной работы. Для хранилищ данных данная категория составляет незначительную или нерегулярную долю нагрузки.
- Производительность последовательного чтения — примерами могут служить резервное копирование, полное сканирование таблиц, создание индексов, параллельное выполнение запросов, чтение из временных сегментов, операции восстановления и доката из журнальных файлов. Даже для хорошо оптимизированных OLTP-приложений, эта категория должна рассматриваться как составная часть нагрузки, особенно для систем с интенсивными пакетными заданиями. Для хранилищ данных последовательное чтение может может быть практически единственным видом чтения.
- Производительность последовательной записи — примером служит работа LGWR-процесса, запись во временные сегменты, прямые загрузки данных (direct-load), создание индексов, создание табличных пространств и операция восстановления. Проектировщики, акцентируясь на транзакциях и обработке запросов иногда забывают эту категорию. Хотя во время первичной загрузки данных и в течении всей эксплуатации база данных любого типа генерирует большое число операций последовательной записи.
- Влияние параллелизма — в каждой из категорий, упомянутых выше, архитектор должен рассмотреть влияние различных уровней параллелизма.
- Стоимость приобретения — экономическая оценка закупки системы.
- Стоимость обслуживания — стоимость эксплуатации и поддержания системы. Стоимость обслуживания состоит из эксплуатационных издержек, которые зависят от надежности системы и из административных затрат, зависящих от сложности системы. Например, система сложная в обращении, требующая более подготовленных операторов и техников по ремонту, будет иметь более высокую стоимость обслуживания.
Декомпозиция на производительность, надежность и стоимость дает нам важный инструмент для построения хорошей системы. Он позволяет нам оценить компромиссы как в пределах одной категории (например — скорость выполнения случайного чтения за счет последовательного чтения), так и понять влияние одной категории на другую (например — сильную связь между скоростью выполнения последовательной записи и продолжительностью простоя).
Эти категории также позволяет нам формализовать наши рассуждения о системе. К примеру, понимание разных составляющих понятия надежности дает нам возможность изучать их независимо: (1) мы можем фокусировать усилия на снижении частоты отказов или (2) мы можем попытаться снизить продолжительность простоев вследствие отказов, которые мы предотвратить не в силах. И это напоминает нам еще раз, что продолжительность простоя является частично вопросом надежности, а частично — вопросом производительности.
Последующие разделы помогут Вам провести высокоуровневый анализ взаимосвязей производительности, доступности и стоимости при проектировании подсистемы ввода/вывода для СУБД Oracle. Этот раздел поможет Вам лучше понять Ваши задачи и технологии, поможет сделать Вам более информированные решения, чтобы Вы получили наилучший результат от Ваших инвестиций.
Назад Содержание Вперёд
\
