Рассмотрим приложение, которое обеспечивает информацию
Рассмотрим приложение, которое обеспечивает информацию о состоянии заказов для телефонного бюро обслуживания. Хотя прикладная система поддерживает некоторое число различных типов пользователей, имеется одна ключевая транзакция: запрос о состоянии счета/заказа. В течение дня система должна поддерживать 120 пользователей, выполняющих запросы счет/заказ с максимальным временем ответа 2 секунды. Обычно операторы обрабатывают примерно один телефонный звонок за две минуты. (Оформление новых заказов выполняется на отдельной системе, новые заказы поступают в систему запросов по ночам после резервного копирования).
В среднем имеется 7000 активных счетов и примерно 8500 неуплаченных заказов. Всего в текущий момент времени имеется 260000 счетов и 65000 последних заказов (заказы сроком более трех месяцев архивируются и изымаются из таблицы неуплаченных счетов). Каждая строка в таблице счетов имеет объем примерно в 3 Кбайт, и таблица счетов индексируется номером заказа и фамилией заказчика. Строки в таблице неуплаченных счетов имеют размер в 90 байт; каждый заказ ссылается в среднем на 6 строк в таблице Строка_Наименование_Товара (line item); каждая Строка_Наименование_Товара содержит 30 байт. Таблица заказов индексируется номером заказа. Наконец, каждая Строка_Наименование_Товара ссылается на описание товара; в текущий момент имеется 1050 описаний товаров, длиною 200 байт каждое. Эти размеры данных приведены в таблице 2.6.
Таблица 2.6. Размеры таблиц данных для приложения телефонных заказов
| Таблица | Кол-во строк | Размер строки | Чистый размер данных |
| Счета | 260000 (7000 активных) |
3 Кб | 780 Мб |
| Заказы | 65000 (8500 активных) |
90 байт | 5.9 Мб |
| Строка_Наименование_Товара | 390000 | 30 байт | 11.7 Мб |
| Описание товара | 1050 | 220 байт | 231 Кб |
В нормальных условиях работы оператор отвечает на телефонный звонок от покупателя, который сообщает либо номер заказа, либо имя заказчика. В редких случаях заказчик не может быть найден прямо по имени, и оператор должен запрашивать таблицу заказов по zip-коду. Это случается примерно в 5% случаев. Когда место заказа определено, строки с наименованием товара и их состояние отображаются на экране. Большая часть звонков заказчиков (более 99%) связана с запросом состояния одного заказа.
В терминах обращения к диску типовая транзакция включает чтение по ключу (произвольное) для выборки индекса счета, за которым следует чтение по ключу из таблицы счетов, которое читает 3 Кб данных. В записи счета хранится индексный ключ для поиска индекса таблицы заказов. Поскольку имеется 8500 неоплаченных заказов и только 7000 активных счетов, каждое обращение к индексу заказа приводит грубо к
8500/7000 = 1.21 обращений к диску, каждое к таблице индексов и ее индексу. Наконец, в каждом заказе имеется ссылка на 6 строк Строка_Наименование_Товара; поскольку они очень малы по размеру и записаны в базу данных в одно и то же время, обычно уместно предположить, что они будут генерировать обращение к индексу и затем только одно обращение к данным (6 строк по 30 байт на строку (это намного меньше, чем типовой блок данных СУБД размером 2 Кб). Последнее обращение происходит к описанию товара; однако, поскольку объем этих данных очень мал (вся таблица составляет всего
230 Кб) и они очень часто используются, можно предположить, что они кэшированы в памяти и возможно обращения к диску не происходят.
Рассмотрев эти цифры, мы можем вывести заключение, что обработка каждого звонка заказчика возможно будет вызывать одно обращение к диску за индексом счета, 1.5 обращения к таблице счетов (строка составляет 3 Кб, но большинство блоков данных имеют размер 2 Кб), примерно 1.2 обращений к таблице заказов и 1.2 обращений к индексу таблицы заказов, и каждый из них к таблице Строка_Наименование_Товара и ее индексу, т.е. всего примерно 6 операций чтения диска. Почти все из них выполняются в режиме произвольного доступа.
Поскольку ожидается, что каждый запрос будет приводить к 6 операциям чтения диска, и что 120 операторов будут генерировать 120 запросов каждые 2 минуты, среднее число запросов будет составлять один запрос в секунду. Поскольку для обработки каждого запроса требуется 6 обращений к диску ясно, что даже одной дисковой системы будет вполне достаточно для обработки запросов в установившемся режиме работы. (Напомним, что всегда рекомендуется иметь отдельный диск для ведения журнала, поскольку это связано не с обеспечением необходимой производительности, а скорее с вопросом обеспечения безопасности данных и стратегии выживания). Поскольку дисковый накопитель способен выполнить примерно 60 полностью произвольных операций ввода/вывода в секунду, отдельная дисковая система очевидно может обработать десять запросов возникших почти в один и тот же момент времени, так что если остальная часть системы имеет достаточно ресурсов, дисковая подсистема может обработать почти все, что пользователи запросят.
Имеется еще одно соображение касающееся 5% транзакций, записи счетов которых должны отыскиваться с помощью zip-кода. Поскольку таблица счетов не индексируется с помощью zip-кода, поиск должен осуществляться последовательно. Это означает, что чтобы обработать один такой запрос, для определения местоположения правильной записи счета система должна в среднем прочитать в течение 2 секунд (!) 260000/2=130000 строк. Поскольку каждая строка составляет 3 Кб, для каждой строки требуется 1.5 операции ввода/вывода, всего 195000 операций ввода/вывода (строк) по 2 Кб. Обращаясь к таблице 5 находим, что диск емкостью 535 Мб способен выполнить около 450 последовательных операций ввода/вывода в секунду, а четыре таких диска (общей емкостью 2.1 Гб) способны выполнить примерно 1800 операций в секунду. Даже при использовании 16 дисков (в 4 раза превышая требуемую емкость памяти) можно обеспечить обработку только 7200 операций в секунду. Отсюда ясно, что экономически невыгодно конфигурировать дисковую подсистему, которая будет обеспечивать необходимую пропускную способность. Единственный альтернативный вариант заключается в том, чтобы разрешить этой транзакции выполняться гораздо дольше, чем обычно, или проиндексировать таблицу счетов с помощью zip-кода.
В конце концов, возможно наилучшей конфигурацией дисков является 4 диска по 535 Мб, сконфигурированных на двух главных адаптерах SCSI, если это представляется возможным по экономическим соображениям. Журнальный файл будет иметь очень небольшой объем и потому может размещаться на системном диске. Поскольку тип СУБД не был определен, а также не было никакой информации о количестве времени, связанного с обработкой самого приложения, невозможно точно оценить количество процессоров в системе. Каждый пользователь выполняет одну транзакцию за каждые две минуты, а каждая транзакция требует тривиального количества обработки: 6 операций с диском отнимают по 1.7 мс процессорного времени каждая, или примерно 1% от каждой минуты работы процессора. Для обработки запросов всех операторов потребуется примерно 10 мс процессорного времени на каждый запрос ( 120 пользователей / 120 секунд = 10 мс процессорного времени в секунду. Ясно, что любой процессор легко справится с такой нагрузкой. Поскольку имеется 120 пользователей, рекомендуются процессоры с большими внешними кэшами, поэтому SPARCstation 10 Model 51 является наиболее подходящим процессором. При данном уровне загрузки процессора никакой дополнительный процессор возможно не потребуется.
Что касается объема основной памяти, то ясно, что необходим минимальный объем в 128 Мб, поскольку с ней будут работать 120 пользователей. Если выделить под каждого пользователя 1 Мбайт памяти, 16 Мб под базовую операционную систему и 8 Мб для кэша разделяемых данных СУБД (1% от размера базы данных), то минимальный объем основной памяти составит 144 Мб, а 160 Мб возможно представляют собой более безопасную оценку. Поскольку операции обновления СУБД отсутствуют, отсутствуют и требования к использованию NVSIMM для ускорения работы с журнальным файлом.
Наконец, 120 пользователей должны быть подсоединены к терминальным серверам. Другие требования к Ethernet для периода опытной эксплуатации системы отсутствуют, поэтому терминальные серверы не создадут каких либо проблем с использованием полосы пропускания Ethernet.
Таким образом, в состав конечной оцениваемой конфигурации входит SPARCstation 10 Model 51 с 160 Мб основной памяти, одним FSBE/S, четырьмя дисками по 535 Мб для СУБД и один 1.05 Гб внутренний диск для операционной системы и разнообразных функций СУБД. Требуются также 2 сетевых терминальных сервера по 64 порта.
