Сервери баз даних: проблеми оцінки конфігурації системи, Інші СУБД, Бази даних, статті

В.З. Шнітман, www.osp.ru
Зміст
1. Короткий екскурс в історію

2. Основи конфігурування серверів баз даних
3. Характеристики основних підсистем серверів баз даних
Висновок
Література

1. Короткий екскурс в історію

Протягом 80-х років постачальники мейнфреймів і міні-комп’ютерів намагалися вирішити задачу створення систем обробки транзакцій на базі мови SQL, здатних обробляти більше 1000 транзакцій в секунду.

У період з 1989 по 1992 роки за такими параметрами, як продуктивність і ставлення вартість / продуктивність, першість належала патентованим системам. Зокрема, кращі показники мали комп’ютери VAX компанії Digital і Cyclone / CLX компанії Tandem. Найкраща продуктивність комп’ютерів компанії HP була зареєстрована для її продукту Allbase. У той же час лінія виробів AS/400 компанії IBM також мала вражаючі параметри (істотно перевершують відповідні характеристики виробів серії RS/6000-AIX). Характерно, що компанія IBM ніколи не публікувала результати тестування системи DB2 на своїх мейнфреймах. Звичайно, СУБД DB2 мала чудову продуктивність (оцінюється в сотнях транзакцій в секунду), але вона працювала на дорогих мейнфреймах. Найімовірніше, IBM не хотіла показувати неекономічність своїх мейнфреймів шляхом публікації результатів контрольних випробувань на тесті TPC-A. Єдиним постачальником мейнфреймів, який ризикнув опублікувати результати тестування, виявилася компанія Unisys, система якої показала ставлення вартість / продуктивність приблизно на рівні 45 K $ / tps. У той час цей показник удвічі перевищував відповідні показники її конкурентів.

У період між 1989 і 1993 роками операційні системи (SCO Unix, NetWare, NT), системи управління базами даних (Oracle, Informix, Sybase, Ingres) і монітори транзакцій (Tuxedo, VIS / TP, Encina), які сьогодні сміливо можна віднести до розряду продуктів масового споживання, різко покращили свою продуктивність при вирішенні задач обробки простих транзакцій.

У 1993 році комбінація продуктів Unix / Oracle / Tuxedo стала лідером по відношенню вартість / продуктивність. Oracle, Tuxedo і операційна система Dynix, що працюють на многопроцессорной системі компанії Sequent, побудованої на базі процесорів Intel 486, були першими, що подолали бар’єр 1 Ktps, який протримався більше десятиліття. Трохи пізніше СУБД Rdb і Oracle подолали цей бар’єр з дещо кращим ставленням вартість / продуктивність при виконанні тестів на шестіпроцессорной системі Alpha AXP компанії Digital, що працює під управлінням ОС VMS. Аналогічних результатів домоглися і компанії HP і Sun. У 1994 році лідером по відношенню вартість / продуктивність виявилася комбінація продуктів Compaq / SCO Unix / Oracle. Системи компаній Digital, HP і Sun мали більш високу продуктивність, але і більш дорогі рішення.

Пікова продуктивність систем і їх вартість у перерахунку на одну транзакцію продовжують швидко поліпшуватися. В даний час лідерство по відношенню вартість / продуктивність належить комбінації продуктів Compaq / Windows NT / Microsoft SQL, хоча, як і колись, системи компаній Digital, HP і Sun мають більш високу продуктивність (див. таблицю 1).

TPC-C Results
Company
System
Thrughput (tpmC)
Price/Perf ($/tpmC)
Database Software
Compaq
ProLiant 5000 6/166 4/Pentium Pro/200MHz
6184.90
$111
Microsoft SQL Server 6.5
Digital
AlphaServer 8400 5/350 8/DECchip21164/350MHz
14227.25
$269
Oracle Rdb7 V 7.0
Digital
AlphaServer 4100 5/400 4/DECchip21164/400MHz
7985.15
$174
Oracle Rdb7 V 7.0
Digital
AlphaServer 4100 5/400 4/DECchip21164/400MHz
7998.63
$152
Sybase SQL Server 11.0
HP
HP 9000 Model D370 2/PA-RISC 8000/160MHz
5822.23
$148
Sybase SQL Server 11.0
HP
HP 9000 Model K460 4/PA-RISC 8000/180MHz
12321.87
$187
Sybase SQL Server 11.0
IBM
RS6000 Power PC Server J40 8/Power PC 604/112MHz
577.07
$243
Sybase SQL Server 11.0
SGI
Challenge XL Server 16/R4400/250MHz
6313.78
$479
Informix OnLine V.7.11.UDI
Sun
Ultra Enterprise 4000 12/UltraSPARC/167 MHz
11465.93
$189
Sybase SQL Server 11.0.2
Sun
Ultra Enterprise 3000 6/UltraSPARC/167 MHz
6662.47
$152
Sybase SQL

Таблиця 1.

Ще кілька років тому про комп’ютери, побудованих на базі платформи Intel (наприклад ПК-сумісних системах компанії Compaq), порівнюючи їх з системами компаній Digital, HP, IBM і Sun, можна було сказати, що в них відсутній контроль парності в пам’яті або процесорі, що вони використовують порівняно малонадійні диски, або що для них, наприклад, відсутня програмне забезпечення для оперативної обробки транзакцій (OLTP). Природно, такі машини, просто кажучи, не були конкурентоспроможними. Сьогодні ситуація повністю змінилася. Компанія Compaq є не тільки найбільшим в світі постачальником серверів рівня робочих груп, але і найбільшим постачальником дискових масивів рівня RAID-5. “Корпоративні” версії її продуктів мають потужні засоби вбудованої діагностики, віддаленого обслуговування, інтегровані джерела безперебійного живлення і навіть деякі засоби резервування вузлів. Широке поширення отримують комбінації продуктів SCO-Unix/Tuxedo/Oracle, Novell NetWare / Oracle, Microsoft NT / Sybase та ін

На жаль, ці системи масового застосування в даний час все ще не мають повністю відпрацьованих засобів кластеризації. Кластерні архітектури дають можливість безлічі процесорів обслуговувати безліч клієнтів, забезпечують однаковий програмний інтерфейс і інтерфейс управління загальними ресурсами. Засоби кластеризації потрібні, перш за все, для побудови дійсно великомасштабних систем, включають десятки і сотні дисків і обслуговуючих тисячі клієнтів. Ці кошти потрібні також для побудови систем високої готовності. У разі відмови будь-якого пристрою або процесора в кластері інші пристрої автоматично перемикаються і забезпечують доступ до точної копії сервера або даних.

Ще два роки тому найбільш відпрацьована технологія кластеризації була обмежена операційною системою Guardian компанії Tandem, системою DBC/1024 компанії Teradata і операційною системою VMS компанії Digital. Проте вже в той час практично кожен великий постачальник обчислювальних систем пропонував свої кошти кластеризації на базі операційних систем Unix і NT. Очікувалося, що для повного “дозрівання” відповідного програмного забезпечення буде потрібно кілька років і що воно буде готове до кінця 1996 – початку 1997 року.

Крім того, виявилося, що нове програмне забезпечення істотно простіше використовувати. На приклад, комбінація продуктів NT / Sybase забезпечує однаковий механізм доменів найменування і секретності, графічний інтерфейс для адміністрування і роботи, а також сучасні інструментальні засоби розробки. Збережені процедури SQL, генератори додатків типу PowerBuilder, SQLWindows, Windows 4GL та інші засоби значно спрощують побудову TP-додатків клієнт-сервер, що підтримують більше сотні користувачів на кожному сервері. Правда, масштабування системи для обслуговування значно більшого числа користувачів вимагає поділу завдання на кілька менших серверів або використання традиційних моніторів обробки транзакцій типу Tuxedo, Encina, ACMSxp або CICS. Програмне забезпечення для автоматизації побудови подібного роду систем клієнт-сервер може бути реалізовано за допомогою інструментальних засобів типу Ellipse і Forte.

Таким чином, часи змінилися. Повним ходом йде процес переведення на масову технологію систем, раніше базувалися на мейнфреймах. Програмне забезпечення масового споживання встановило і нові точки відліку в області ціноутворення.

2. Основи конфігурування серверів баз даних

Системи управління базами даних (СКБД) є одним з найбільш поширених класів прикладних систем для серверів, що випускаються більшістю компаній-виробників комп’ютерної техніки. Слід зазначити, що додатки, орієнтовані на використання баз даних, і самі СУБД сильно різняться за своєю організацією. Якщо системи на базі файлових серверів порівняно просто розділити по типу робочого навантаження на два принципово різних класу (з інтенсивною обробкою атрибутів файлів і з інтенсивною обробкою самих даних), то провести подібну класифікацію серед додатків баз даних і СУБД просто неможливо. Стандартна мова реляційних СУБД (SQL) набагато багатше, ніж набір операцій мережевої файлової системи.

На сьогодні абсолютна більшість інстальованих у світі систем реляційні, і ця архітектура обрана такими виробниками, як Oracle, Sybase, Ingres, Informix, Progress, Empress і dBase. ADABAS компанії Software AG – ієрархічна система, хоча може обробляти стандартний SQL. Але навіть з урахуванням того, що переважна більшість систем працює по одній і тій же концептуально загальної схемі, між різними продуктами є великі архітектурні відмінності. Можливо, найбільш істотним з них є реалізація самої СУБД.

Докладний аналіз різних моделей СУБД вже проводився на сторінках журналу СУБД (див., наприклад, [4] стор 125-142). Тут відзначимо лише, що можна виділити два основні класи систем: системи, побудовані за принципом “2N” (або “один-до-одного”), і багатопотокових системи. У більш старих 2N-реалізаціях для кожного клієнта на сервері використовується окремий процес, навіть якщо програма-клієнт фізично виконується на окремій системі. Таким чином, для роботи кожного клієнтського додатка використовуються два процеси – один на сервері і один на клієнтської системі. Багатопотокових програми якраз і розроблені для того, щоб істотно знизити додаткові витрати на організацію управління такою великою кількістю процесів. Зазвичай вони припускають наявність кількох процесів (від одного до п’яти), що працюють на серверної системи. Ці процеси мають внутрішню многопотоковую організацію, що забезпечує обслуговування запитів безлічі клієнтів. Більшість основних постачальників СУБД в даний час використовують многопотоковую реалізацію або рухаються в цьому напрямку.

2.1. Характеристики робочого навантаження (тести TPC)

У комп’ютерній індустрії термін “транзакція” (transaction) може означати майже будь-який вид взаємодії або обміну інформацією. Однак у світі бізнесу “транзакція” має цілком певний сенс: комерційний обмін товарами, послугами чи грошима. В даний час практично всі бізнес-транзакції виконуються за допомогою комп’ютерів. Найбільш характерними прикладами систем обробки транзакцій є системи управління обліком, системи резервування авіаквитків та банківські системи. Таким чином, необхідність стандартів і тестових пакетів для оцінки таких систем все більше посилюється. Щоб вирішити ці проблеми, в 1988 році була створена організація TPC (Transaction Processing Performance Council), основним завданням якої є точне визначення тестових пакетів для оцінки систем обробки транзакцій і баз даних, а також для поширення об’єктивних, перевірених даних у промисловості.

TPC публікує специфікації тестових пакетів, які регулюють питання, пов’язані з роботою тестів. Ці специфікації гарантують, що покупці мають об’єктивні значення даних для порівняння продуктивності різних обчислювальних систем. Хоча реалізація специфікацій оціночних тестів залишена на розсуд індивідуальних спонсорів тестів, самі спонсори, оголошуючи результати TPC, повинні представити TPC детальні звіти, документують відповідність усім специфікаціям. Ці звіти, зокрема, включають конфігурацію системи, методику калькуляції ціни, діаграми значень продуктивності і документацію, що показує, що тест відповідає вимогам атомарности, узгодженості, ізольованості та довговічності (ACID atomicity, consistency, isolation, and durability), які гарантують, що всі транзакції з оціночного тесту обробляються належним чином.

TPC визначає і управляє форматом кількох тестів для оцінки продуктивності OLTP (On-Line Transaction Processing), включаючи тести TPC-A, TPC-B, TPC-C, TPC-D і TPC-E. Хоча згадані тести TPC НЕ є безпосередньо тестами для оцінки продуктивності баз даних, системи реляційних баз даних – ключові компоненти будь-якої системи обробки транзакцій.

Слід зазначити, що, як і будь-який інший тест, жоден тест TPC не може виміряти продуктивність системи, яка застосовується для будь-якої можливої ​​середовища обробки транзакцій, але ці тести дійсно можуть допомогти користувачеві справедливо порівнювати схожі системи. Однак, коли користувач робить покупку або планує рішення про покупку, він повинен розуміти, що ніякої тест не може замінити його конкретну прикладну задачу.

Охарактеризувати навантаження, що генерується додатком бази даних, неможливо без детальної інформації про те, що ж насправді додаток робить. Навіть маючи подібні відомості, доводиться робити безліч припущень про те, як сама СУБД буде звертатися до даних, наскільки ефективним може виявитися дисковий кеш СУБД при виконанні певних транзакцій, або навіть про те, яка може бути суміш транзакцій.

На сьогодні в промисловості прийняті наступні типи характеристик навантаження, що генерується додатком бази даних: “легка”, “середня”, “важка” і “дуже важка”. Категорія “легка” прирівнюється до робочих навантажень, які домінують в операціях, подібним транзакціях дебет / кредит, визначеними в оціночних тестах TPC-A. Навантаженнями “середньої” тяжкості вважаються транзакції, визначені стандартом тесту TPC-C. Важкими робочими навантаженнями вважаються навантаження, які асоціюються з дуже великими додатками, такими як Oracle * Financials. Такі навантаження по крайней мере в 5-10 разів важче, ніж прийняті в тесті TCP-A.

Основним класом додатків, які потрапляють в категорію “дуже важкою” навантаження, є системи підтримки прийняття рішень. Через дуже великих відмінностей у характері самих запитів до системи підтримки прийняття рішень, адміністратори баз даних або самої СУБД стикаються з серйозними проблемами щодо забезпечення широкомасштабної оптимізації. Запити до системи підтримки прийняття рішень часто призводять до формування суттєво більшого числа запитів до нижележащей системі через необхідність виконання багатонаправлені сполук, агрегування, сортування і т. п. Тест TPC-D був спеціально розроблений для оцінки роботи додатків підтримки прийняття рішень.

Детально про структуру тестів TPC див. [4].

2.2. Вибір конфігурації сервера СУБД

Хоча багатьох користувачів часто цікавлять деякі рекомендації по вибору конфігурації тієї чи іншої системи, корисність цих рекомендацій в значній мірі залежить від аналізу самого додатка. Ефективність роботи самого програми та СУБД набагато важливіше, ніж конфігурація хост-машини. Є буквально сотні прикладів невеликих змін, проведених у додатку або в схемі бази даних, які забезпечували 100 – або 1000-кратне збільшення продуктивності системи. На загальну продуктивність системи вельми істотний вплив може чинити добре продумана індексація. Після початкової інсталяції системи обов’язково потрібно провести збір статистики про її роботі, щоб з’ясувати необхідність внесення змін в базу даних. Часто виявляється можливим поліпшити продуктивність програми шляхом реорганізації бази даних навіть без звернення до вихідного коду програми.

Іншим міркуванням, якому приділяється недостатньо уваги, але яка часто має великий вплив на результуючу продуктивність системи, є конфлікти з внутрішніх блокувань. Якщо обрана неоптимальна стратегія блокувань, то система може виявитися дуже погано працює. Слід також зазначити, що кожна СУБД має величезне число параметрів, що настроюються, і деякі з них можуть серйозно впливати на загальну продуктивність системи.

Нижче перераховані питання, відповіді на які дозволяють узагальнити процес вибору конфігурації сервера СУБД.

2.3. Вибір обчислювальної моделі

У більшості прикладних систем СУБД можна виділити три логічних частини: користувальницький інтерфейс (засоби подання), що забезпечує функції введення і відображення даних; деяку прикладну обробку, характерну для даної предметної області; і власне сервіси СУБД. Інтерфейс користувача та прикладна обробка зазвичай об’єднані в одному двійковому коді, хоча деякі з найбільш просунутих додатків тепер забезпечують многопотоковую фронтальну обробку, відокремлену від засобів подання.

Якщо в системі можна реалізувати модель обчислень клієнт-сервер, що відокремлює фронтальну (прикладну) обробку та засоби подання від постачальника послуг СУБД, її використання зазвичай забезпечує суттєве поліпшення загальної продуктивності системи. Така організація системи дозволяє найбільш важливого ресурсу (серверу СУБД) працювати без перешкод на своїй власній хост-машині. Це в першу чергу справедливо для систем, в яких робота засобів подання пов’язана з управлінням сотнями або тисячами терміналів.

2.4. Монітори обробки транзакцій

Використання моніторів обробки транзакцій є одним з методів досягнення більш високої продуктивності для наявної конфігурації, особливо в режимі клієнт-сервер (див. [5]). TP-монітори являють собою проміжний шар програмного забезпечення, який розташовується між додатком і системою або системами СУБД. При цьому додаток повинен бути модифіковано так, щоб воно могло видавати транзакції, написані на мові монітора транзакцій, а не звертатися прямо до бази даних за допомогою звичайних механізмів (подібних різним формам вбудованого SQL). Програмісти прикладних систем є також відповідальними за складання файлу опису, який відображає транзакції в певні звернення до бази даних на рідній мові звернень нижележащей СУБД (майже для всіх СУБД під Unix це SQL).

Використання моніторів транзакцій практично не накладає жодних обмежень на різноманіття або складність запитів доступу до нижележащей СУБД. Крім досягнення певної гнучкості за рахунок використання TP-моніторів така організація виявляється вигідною і з точки зору збільшення продуктивності системи. TP-монітор завжди являє собою многопотоковую програму. Оскільки TP-монітор відкриває своє власне з’єднання з СУБД, одночасно усуваючи необхідність виконання кожним прикладним процесом прямих запитів до СУБД, число одночасно працюючих користувачів СУБД істотно скорочується. У переважній більшості випадків СУБД обслуговує тільки одного “користувача” – TP-монітор.

TP-монітори дозволяють також поліпшити продуктивність за рахунок скорочення обсягу інформації, що пересилається між СУБД та прикладним процесом. Оскільки певну частину кожної транзакції становлять тільки мінімально необхідні дані, загальний обсяг пересилання даних звичайно може бути скорочений. Це особливо важливо, коли клієнт і сервер з’єднані між собою за допомогою досить зайнятої мережі та / або мережі з відносно вузькою смугою пропускання, наприклад глобальної мережі на супутникових каналах зв’язку.

3. Характеристики основних підсистем серверів баз даних

3.1. Процесори

Відомо, що продуктивність будь-якого процесора залежить від трьох параметрів: такту (або частоти) синхронізації, середньої кількості тактів на команду і кількості виконуваних команд. Таким чином, крім тактової частоти на продуктивність істотно впливають система команд і внутрішня організація процесора. Практично всі постачальники комп’ютерної техніки проводять випробування своїх виробів для визначення правильності обраних архітектурних рішень. Наприклад, у таблиці 2 представлені деякі результати вимірювань, отримані при прогоні тесту TPC-C, побудованого на базі комерційної СУБД, на системі RISC System/6000 Model 590 (процесор POWER2) компанії IBM. У таблиці прийняті наступні позначення: FXU-блок обробки команд з фіксованою точкою, ICU блок обробки команд управління, FPU блок обробки команд з плаваючою крапкою.

Відсоток команд FXU
77.3%
Відсоток команд ICU
22.5%
Відсоток команд FPU
0.2%
Відсоток команд FXU, які виконуються в FXU0
67%
Відсоток команд FXU, які виконуються в FXU1
33%
Середня кількість тактів на команду (CPI)
1.53
Відсоток команд переходу, виконуваних в ICU
93%
Відсоток команд умовного переходу
35%
Відсоток команд умовного переходу, коли умова переходу виконується
57%
Відсоток команд переходу за лічильником
2%
Середній розмір базового блоку в командах
4.8
Коефіцієнт промахів в I-кеші (на команду)
2.1%
Коефіцієнт промахів в D-кеші (на команду)
0.8%

Таблиця 2.

Аналіз цих результатів може привести до кращого розуміння характеристик ЦП на тестах TCP-C, які, в свою чергу, з обережністю можна було б узагальнити на більш широку область додатків баз даних, яку представляє даний тест.

Ці результати показують, що в тесті TPC-C домінують команди FXU (операції маніпуляції з цілими числами і операції обчислення адрес), досить інтенсивно використовуються команди переходу (ICU), а команди плаваючою точки (FPU) практично не використовуються. Такі результати слід було очікувати, оскільки загальновідомо, що в програмному коді СУБД для перетворення адрес, необхідного при обробці покажчиків, інтенсивно використовується целочисленная арифметика. Зауважимо, що в архітектурі POWER2 передбачено два цілочисельних пристрою. Другий FXU обробляє приблизно третину цілочисельних операцій (при цьому приблизно половину часу, коли зайнятий перший FXU, другий FPU також зайнятий). Така організація процесора дає майже 50% збільшення пропускної здатності цілочисельного коду в порівнянні з процесором POWER (попередня версія архітектури), в якому було всього один FPU, хоча виконуваний код СУБД не перекомпілювати. Таким чином, наявність в POWER2 двох цілочисельних пристроїв істотно скорочує середню кількість тактів на виконання однієї команди (CPI) на робочому навантаженні.

Майже всі операції ICU являють собою операції переходу, причому приблизно третина з них складають операції умовного переходу. Майже рівне співвідношення виконуваних і невиконуваного умовних переходів, а також невелике число команд переходу за значенням лічильника правильно відображають реалізацію операторів переходу if-then-else, які, як і слід було очікувати, домінують в цій робочого навантаження. Середній розмір базового блоку (послідовності команд, які виконуються між двома виконуваними переходами) дуже невеликий. Таким чином, дана робоча навантаження істотно відрізняється від навантаження, що реалізує алгоритми з області науково-технічних програм з інтенсивними обчисленнями, яка пов’язана з багаторазовим повторенням ітерацій циклів, що включають досить довгі послідовності програмного коду, і дає значно більшу кількість виконуваних переходів, більший відсоток команд переходу за значенням лічильника і більший розмір базового блоку.

Коефіцієнт промахів кешу команд (I-кеша) розміром 32 Кбайт досить низький, хоча і вище, ніж коефіцієнт промахів для багатьох інших робочих навантажень. Коефіцієнт промахів істотно скорочується завдяки великому розміру рядка I-кеша (128 байт) і локальності коду. Наявність досить великого кеша даних (D-кеша) ємністю 256 Кбайт пояснює спостерігається низький коефіцієнт промахів за даними.

Таким чином, результати подібних випробувань дозволяють розробникам процесорів оцінити ефективність функціональної організації ЦП. В сучасних суперскалярних процесорах Intel і RISC-процесорах (Ultra SPARC, PA-8000, MIPS R10000, PowerPC 604/620 і DEC Alpha) практично повсюдно використовуються паралельно працюють блоки целочисленной арифметики, передбачені розвинені засоби прогнозування напряму переходів і великі за обсягом кеші команд і даних. Сьогодні продуктивність цих процесорів знаходиться на одному рівні з продуктивністю найшвидших мейнфреймів. Тактова частота RISC-процесорів досягла 500 МГц, а загальна продуктивність на стандартних оціночних тестах порівнянна (рис. 1).

В даний час стандартним засобом збільшення продуктивності системи є симетрична мультипроцесорна обробка (SMP), що припускає використання багатьма процесорами однієї спільної пам’яті і однієї операційної системи, яка управляє всіма процесорами і апаратними засобами. У сучасних системах SMP найбільш актуальним питанням є створення високопродуктивної підсистеми пам’яті для забезпечення високошвидкісних процесорів даними і командами. Загальне рішення цієї проблеми полягає у використанні великої високошвидкісної кеш-пам’яті, тобто створення ієрархії пам’яті між процесорами і розділяється загальною пам’яттю, а також загальносистемної шини з високою пропускною здатністю.

У загальному випадку споживання процесорних ресурсів дуже сильно варіюється в залежності від програми, СУБД, особливостей окремих користувачів і навіть від часу дня. Наприклад, результати тесту TPC-A 1994 показували, що восьмипроцессорний SPARCserver 1000 компанії Sun здатний обробляти запити від 4000 користувачів, або від 500 користувачів на процесор. (Ці результати були отримані на багатопотоковому сервері Oracle Version 7, які працюють в режимі клієнт-сервер, причому в якості фронтальної системи використовувався монітор обробки транзакцій Tuxedo / T.) Слід зазначити, що такі високі показники були досягнуті фахівцями компаній Sun і Oracle шляхом дуже ретельної настройки ОС Solaris, СУБД Oracle і самого оцінного тесту. Можливості цих фахівців з налаштування системи, очевидно, значно перевершують можливості більшості користувачів. Більш реалістична верхня межа числа користувачів на процесор, можливо, становить близько 100-200 користувачів на один процесор SuperSPARC 50 МГц, навіть для легких транзакцій типу TPC-A. Більші програми, природно, призводять до меншого числа користувачів на процесор (відповідні результати представлені в таблиці 3).

Тип програми
Кількість процесорів 50 МГц SuperSPARC
1
2
4
8
16
TP-монітор
Клієнт / сервер
200-300
350-500
550-850
800+
1000+
Легковаге
Клієнт / сервер
150-200
250-350
450-550
725+
800+
многопотоковой
Поділ часу
50-80
85-135
150-225
200-300
250-300
Великовагове
Клієнт / сервер
50-100
85-170
150-250
200-350
350-600
многопотоковой
Поділ часу
20-60
35-100
60-175
100-300
150-250
Великовагове 2N
Клієнт / сервер
40-75
70-125
120-220
200-600
300-750
Поділ часу
15-40
25-70
45-120
75-200
110-230

Таблиця 3.
Зразкове число підтримуваних користувачів на ЦП.

Слід зазначити, що процесор Super-SPARC 50 МГц вже знятий з виробництва, і нинішнє покоління процесорів Sun, зокрема, UltraSPARC II 250 МГц, має майже на порядок більшу продуктивність. Тим Проте результати таблиці 3 вельми повчальні. Наприклад, вони показують, що ні операційна система Solaris 2, ні СУБД не масштабуються лінійно (те ж саме відбувається і з конкуруючими операційними системами), хоча з часом у міру подальшої настройки ОС і СУБД є певний прогрес у цьому напрямку.

3.2. Підсистема основної пам’яті

Серед різних компонентів апаратури сервера СУБД конфігурація пам’яті системи зазвичай має найбільше вплив на її продуктивності. Хоча для багатьох людей пам’ять представляється тільки сховищем виконуваних програм, більша частина основної пам’яті в системах СУБД використовується як буфер (кеш) даних, що дозволяє в багатьох випадках усунути необхідність виконання фізичного введення-виведення з диска. Оскільки звернення до основної пам’яті виконується приблизно в 30000 разів швидше, ніж звернення до швидкого диску, мінімізація дискового вводу-виводу є першочергово важливим завданням. Не буде перебільшенням сказати, що “метушня” з іншими конфігураційними параметрами марна, якщо в системі не вистачає основної пам’яті. На щастя, зазвичай помилки по конфігурації пам’яті порівняно легко виправляються.

Постачальники СУБД називають буфери даних по-різному, але всі вони виконують одну й ту ж функцію. Компанія Oracle, наприклад, називає цю пам’ять Глобальної Областю Системи (SGA System Global Area), в той час як Sybase називає її Кешем поділюваних Даних (Shared Data Cashe). Зазвичай буфер реалізується як великий масив розділяється пам’яті, і його розмір визначається спеціальним параметром в керуючому файлі або таблицях СУБД. Розмір пам’яті, необхідний для організації дискового кеша СУБД, змінюється в широких межах від програми до програми.

Можливо, найпростішим і найбільш корисним є емпіричне правило, яке називається “правилом п’яти хвилин”. Існуюче в даний час співвідношення між цінами підсистеми пам’яті і дискової підсистеми показує, що економічно доцільно кешувати дані, до яких здійснюються звернення більше одного разу кожні п’ять хвилин. Це означає, що дані, до яких звернення відбуваються більш часто, ніж один раз на п’ять хвилин, повинні кешуватися в основній пам’яті. Відповідно, щоб оцінити розмір кеша даних необхідно підсумувати об’єми всіх даних, які додаток припускає використовувати більш часто, ніж один раз на п’ять хвилин на рівні всієї системи. Тому при визначенні необхідного обсягу основної пам’яті розраховують, по крайней мере, на такий розмір кеша даних. Додатково зазвичай резервують ще 5-10% для розміщення верхніх рівнів індексів B-дерев, збережених процедур та іншої керуючої інформації СУБД.

Кожна комерційна СУБД забезпечує механізм для визначення вартості чи переваг зміни розміру різних кешів СУБД. Коли система інстальована і починає працювати, необхідно використовувати ці механізми для визначення ефекту від зміни розмірів кешу вводу-виводу СУБД.

Хоча основною метою СУБД на макрорівні є управління томами даних, які за визначенням мають дуже великий обсяг і неминуче у багато разів перевищують обсяг основної пам’яті, проведені дослідження показали, що доступ до даних в загальному випадку підкоряється правилу “90/10”: 90% всіх звернень виконуються до 10% даних. Більше того, виявилося, що до “гарячим” даними, звернення до яких становлять 90% усіх звернень, знову застосовано правило “90/10”. Таким чином, приблизно 80% усіх звернень до даних пов’язані з доступом до приблизно 1% агрегованих даних. Слід зазначити, що це відношення включає звернення до внутрішніх метаданих СУБД (що включають індекси B-дерев і т. п.), звернення до яких зазвичай приховані від прикладного програміста. Хоча бажано мати коефіцієнт попадань в кеш приблизно на рівні 95%, з економічних міркувань неможливо сліпо забезпечити обсяг кеша в пам’яті, що дозволяє розмістити 10% всіх даних: навіть для скромних баз даних об’ємом 5 Гбайт це зажадало б збільшення розміру основної пам’яті до 500 Мбайт. Проте зазвичай завжди можливо забезпечити кеш обсягом в 1% всіх даних навіть для дуже великих баз даних. Максимальний обсяг основної пам’яті сучасних серверів може бути дуже великим. Наприклад, в серверах DEC AlphaServer 8400 він досягає 28 Гбайт, в серверах Challenge XL компанії Silicon Graphics – 16 Гбайт, а в серверах Enterprise 6000 компанії Sun Microsystems – 30 Гбайт. Таким чином, ці сервери можуть працювати з базами даних об’ємом більше одного терабайта (при наявності баз даних такого розміру для підтримки неминуче великого числа користувачів додатків і т. д. очевидно також потрібно істотна частина цієї пам’яті).

Природно, конфігурація системи повинна забезпечувати також простір для традиційного використання пам’яті. В СУБД на базі Unix і NT завжди необхідно забезпечити принаймні 16 Мбайт для базової операційної системи. Далі необхідно передбачити простір об’ємом 2-4 Мбайт для ряду програм СУБД (програм ведення журналу, перевірки узгодженого стану, архіваторів і т. п.) і досить простору для розміщення в пам’яті двійкових кодів програми. Обсяг двійкових кодів додатка становить зазвичай 1-2 Мбайт, але іноді вони можуть досягати 16-20 Мбайт. Операційна система забезпечує режим поділу двійкових кодів між безліччю користуються ними процесів, тому необхідно резервувати простір тільки для однієї копії. Простір для розміщення самого коду сервера СУБД залежить від його архітектури.

Для багатопроцесорних систем існує також емпіричне правило, яке свідчить, що нерозумно конфігурувати менше, ніж приблизно 64 Мбайт пам’яті на процесор. Оброблювана кожним ЦП додаткова інформація вимагає виділення деякого простору для того, щоб обійти інтенсивну фрагментацію пам’яті.

3.3. Дискові підсистеми вводу-виводу

Система Teradata DBC/1024 перші розсіяні уявлення про те, що мікропроцесори не можуть управляти дуже великим числом дискових накопичувачів (так званими “великими фермами дисків”). В ряді організацій навіть найбільші мейнфрейми служать тільки як фронтальних систем до кластеру Teradata. Цей кластер включає кілька сотень процесорів Intel 486, які управляють доступом до кількох тисячам дисків SCSI. Багато великі організації роздрібної торгівлі використовують такі многотерабайтние дискові ферми для аналізу своєї діяльності з продажу та оптимізації обліку товарів. Ці системи забезпечують дуже високу продуктивність навіть при дуже інтенсивної обробки даних в системах прийняття рішень.

Ще порівняно недавно системи на базі персональних комп’ютерів були обмежені необхідністю сумісності з шиною PC-AT, яка забезпечувала швидкість введення-виведення всього декількома мегабайтами в секунду; це менше, ніж швидкість передачі даних одного сучасного диска. Сучасні сервери, побудовані на базі процесорів Intel і RISC-процесорів, оснащуються шинами SBus, PCI і MicroChannel зі швидкістю передачі даних 100, 132 і 160 Мбайт / с, відповідно, а загальна пропускна здатність їх підсистем вводу-виводу обмежується лише можливостями застосовуваної системної шини і знаходиться в діапазоні 0,6-2,5 Гбайт / с.

Таким чином, дискові архітектури сучасних серверів мають дуже високу продуктивність. Сучасні “малі” Fast / Wide / Differential SCSI-диски забезпечують швидкість передачі даних до 12,5 Мбайт / с, а вимірювання швидкості масивів таких дисків перевищили рівень 60 Мбайт / с. Сучасні диски SCSI є настільки ж надійними, як і їх побратими з мейнфреймів, але приблизно в два рази швидше і приблизно в 10 разів дешевше.

Якщо все йде так добре, то які ж проблеми пов’язані з реалізацією дискового вводу-виводу в СУБД і вибором конфігурації дискової підсистеми? Розглянемо їх по порядку.

3.3.1. Співвідношення запит / індекс / диск

Без розуміння програми, стратегії індексації, прийнятої адміністратором бази даних, а також механізмів пошуку і зберігання СУБД складно зробити точний твердження про те, якого типу доступу до диска дана транзакція буде нав’язувати системі. Однак можна припустити, що будь-яка транзакція, яка знаходить невелике число спеціально пойменованих записів з індексованої таблиці “по індексному ключу”, буде представляти собою операцію довільного доступу до диска. Обробка запитів, які містять цілий ряд значень ключів, може приводити до деякої комбінації довільного і послідовного доступу, в залежності від має місце індексації.

Нагадаємо, що будь-яке оновлення бази даних пов’язано і з оновленням всіх порушених індексів, а також з виконанням записи в журнал. На жаль, вся ця техніка йде далеко за рамки цієї статті, вимагаючи грунтовного розуміння роботи конкретної використовуваної СУБД, складної природи запитів і методів оптимізації запитів. Оцінка вимог до виконання дискових операцій виявляється неточною без детальної інформації про те, як СУБД зберігає дані.

3.3.2. Ємність і пропускна здатність дискової пам’яті

Однією з найбільш загальних проблем в СУБД є забезпечення великої ємності дискової пам’яті для зберігання даних при достатньої пропускної здатності дискової підсистеми. На більшості серверів при виконанні звернень до диска домінують операції довільного доступу. Сьогодні на ринку є безліч дисків, але їх продуктивність при виконанні операцій довільного доступу майже одна й та ж: 65-70 операцій в секунду!

З цих причин найкращі можливості при організації вводу-виводу майже завжди досягаються при використанні найменшого по ємності диска, навіть коли більший диск має чудові специфікації по всіх параметрам. Наприклад, у 1994 році сервер SPARCserver 1000 міг оснащуватися дисками ємністю 535 Мбайт, 1,05 Гбайт і 2,1 Гбайт. Як видно з таблиці 4 для заданого обсягу дискової пам’яті (16 Гбайт), загальна пропускна здатність дискової підсистеми істотно вище при використанні дисків 535 Мбайт (більше ніж у три рази).

НМД
Необхідна кількість
Загальна швидкість оп / с
Строк SCSI
Вартість (1994 р.)
Ціна за операцію
535 Мбайт
32
1824
8
$50360
$27
1.05 Гбайт
16
1072
4
$39580
$37
2.1 Гбайт
8
496
2
$37390
$75

Таблиця 4.
Ємність вводу-виводу для пам’яті 16 Гбайт.

Застосування дисків такої малої ємності не завжди практично, оскільки загальні вимоги до місткості дискової підсистеми можуть призвести до використання дисків більшої ємності, або, можливо, в системі виявиться недостатньо доступних слотів периферійної шини для конфігурування необхідного числа головних адаптерів SCSI. Тим не менше було б серйозною помилкою підбирати для системи дискові накопичувачі виключно виходячи з необхідної загальної ємності дискової пам’яті. Хоча ця проблема не нова, з часом вона стає все більш серйозною, оскільки ємність дискових накопичувачів і вимоги до загальної ємності дискової пам’яті починають збільшуватися значно швидшими темпами, ніж швидкість доступу до дисків.

3.3.3. Файлові системи в порівнянні з “чистими” (неструктурованими) дисками

Спочатку при розробці файлових систем Unix і DOS не ставилося завдання забезпечення високопродуктивного дискового вводу-виводу. У традиційній файлової системи Unix, на відміну від екстентних систем типу OS/360 і VMS, дані відображаються на диск у вигляді дерева невеликих блоків, вони копіюються принаймні двічі (оскільки переміщуються через буферний пул), і всі операції введення-виведення виконуються як синхронні запити. У сучасних версіях Unix ці недоліки давно вже враховані, і в них реалізовані можливості організації асинхронного і небуферізованних вводу-виводу.

Крім того, для задоволення потреб інтенсивних по вводу-виводу програм майже всі системи Unix забезпечують інтерфейс “чистих” дисків. Системний адміністратор може визначати зони диска, які виділяються з додатком (ці зони виглядають як файли). Потім програма може виконувати прямі операції Get_Block () і Put_Block для читання і записи в такі файли. Цей інтерфейс має малі накладні витрати.

Більшість СУБД дозволяють адміністратору системи обрати спосіб розміщення файлів СУБД (на “чистих” дисках або в стандартній файлової системи Unix). Деякі системи, найбільш відомими з яких є Ingres і Interbase, нав’язують використання файлової системи Unix. Для систем, які допускають вибір зазначених можливостей, доводиться оцінювати цілий ряд різних критеріїв.

Зберігання даних у файловій системі виявляється менш ефективним (відмінність складає, по крайней мере, 10%), оскільки при виконанні кожного звернення до диска з боку СУБД в роботу включається додатковий шар системного ПЗ. Оскільки у великих СУБД часто одним з обмежують ресурсів є потужність процесора, використання “чистих” розділів (raw partition) покращує продуктивність системи при піковому навантаженні. Тільки з цієї причини більшість адміністраторів баз даних звичайно воліють зберігання даних на “чистих” розділах дисків.

Зберігання даних у файловій системі призводить також до певної втрати ємності пам’яті. Файлова система Unix споживає приблизно 10% від форматованої ємності дисків для метаданих про файлах і файлової системі. Більш того, файлова система резервує 10% решти простору, щоб забезпечити швидкий пошук вільного простору в разі розширення файлів. Якщо СУБД працює з даними через файлову систему, то в порівнянні з “чистим” диском ємність дискової пам’яті в цілому зменшується на 19%.

Є декілька важливих причин, по яких в СУБД використовується зберігання даних у файловій системі. Більшість з них пов’язана із забезпеченням гнучкості або відноситься до розряду більше знайомій для користувача технології.

По-перше, і, що, можливо, найбільш важливо, використання файлової системи дозволяє працювати з пам’яттю за допомогою стандартних утиліт Unix. Наприклад, стандартні утиліти Unix ufsdump і ufsrestore можуть використовуватися для того, щоб виробляти надійне резервне копіювання і відновлення пам’яті СУБД. До того ж набагато простіше здійснювати маніпулювання окремими частинами бази даних. Наприклад, можна здійснювати пряме переміщення таблиці з одного диска на інший, навіть якщо використовуються диски різного розміру та типу. Хоча кожен з постачальників СУБД пропонує свої власні внутрішні утиліти резервного копіювання і відновлення, всі вони різні. Більш того, деякі з них виконуються настільки повільно, що замовники часто застосовують копіювання фізичних томів (тобто використовують команду dd (1)) з усіма притаманними такому копіюванню складнощами. Зберігання даних у файловій системі дозволяє виконувати однакові, надійні процедури для того, щоб працювати через систему і мережу. При цьому, якщо необхідно, можуть також використовуватися інструментальні засоби постачальників СУБД.

3.3.4. Метадані СУБД

Зазвичай користувачі розглядають СУБД як засіб збереження і подальшого пошуку своїх даних і зовсім не замислюються про те, що ж насправді зберігається на диску. На практиці програмне забезпечення СУБД підтримує значну кількість додаткової інформації. Було б серйозною помилкою припускати, що для розміщення заданої кількості даних користувача буде потрібно той же самий обсяг дискового простору. Схема бази даних, табличні індекси, B-дерева вузлів каталогів, тимчасові таблиці, заздалегідь виділений простір для хеш-таблиць і індексів, простір для сортування, файли журналу, архіви і безліч інших даних все це включається в дисковий простір системи.

Якщо відсутня більш точна інформація (звичайний випадок при покупці нової системи), то розумно було б передбачити приблизно подвоєний обсяг дискового простору в порівнянні з обсягом “чистих” даних. Це забезпечує певну гнучкість для створення індексів і т. п., і в підсумку дозволяє поліпшити продуктивність програми. Хоча коефіцієнт 2, на перший погляд, здається надмірним, випливає, наприклад, мати на увазі, що індексація, нав’язувана запропонованим тестом TPC-D, споживає більше 400 Мбайт. При цьому обсяг “чистих” даних складає приблизно 650 Мбайт. При використанні встановлюваних за замовчуванням параметрів пам’яті СУБД Oracle обсяг “чистих” даних, необхідних для реалізації тесту TPC-C, збільшується на 30% при зберіганні їх в базі даних Oracle навіть без індексації. Тому можна легко вимагати для системи навіть набагато більше, ніж 100% додаткового простору.

3.3.5. Розподіл даних

Іншим фактором, що впливає на конфігурацію підсистеми вводу-виводу, є передбачуваний розподіл даних по дисках. Навіть мінімальна за обсягом система повинна мати принаймні чотири диски: один для операційної системи і області підкачки (swap), один для даних, один для журналу і один для індексів. У більш великих системах доводиться враховувати і ряд додаткових можливостей, наприклад використання дзеркальних дисків, механізмів розщеплення і перекриття ресурсів. Взагалі кажучи, найбільш продуктивним і досить ефективним за вартістю способом розподілу даних є забезпечення всіх основних логічних сутностей окремим набором дисків.

Хоча технічно можливо об’єднати по кілька логічних функцій на одних і тих же (фізичних або логічних) дисках, для підсистеми вводу-виводу це виявляється дуже руйнівним і майже завжди призводить до незадовільної продуктивності. Зокрема, може виявитися, що процес формування журналу, який повинен писатися синхронно, в дійсності буде виконуватися в режимі довільного, а не послідовного доступу до диска. Уже тільки це одне буде істотно затримувати кожну транзакцію оновлення бази даних.

Крім того, виконання запитів, що вибирають записи з таблиці даних шляхом послідовного сканування індексу, буде пов’язано з сильно збільшеним часом очікування вводу-виводу. Зазвичай сканування індексу виконується послідовно, але в даному випадку каретка диска повинна переміщатися для пошуку кожного запису даних між вибірками індексів. В результаті відбувається довільний доступ до індексу, який передбачався послідовним. Якщо таблиця даних, індекс і журнал знаходяться на окремих дисках, то довільний доступ до диска здійснюється тільки при вибірці даних з таблиці, і результуюча продуктивність збільшується удвічі.

Нарешті, слід зазначити, що об’єднання різних функцій на одних і тих же фізичних ресурсах призводить до різкого збільшення часу підведення головок на диску. Хоча час позиціонування в специфікаціях дискових накопичувачів зазвичай наводиться як одне число, насправді тривалість позиціонування сильно залежить від конкретного переміщення головок. Приводиться в специфікаціях час позиціонування являє собою суму часів всіх можливих позиціонувань головок, поділена на кількість можливих позиціонувань. Це не той час, який витрачається при виконанні “типового” позиціонування. Сама фізика процесу переміщення дискової каретки визначає, що позиціювання на коротку відстань займає набагато менше часу, ніж на довге. Позиціонування на суміжний циліндр займає всього кілька мілісекунд, в той час як позиціонування на повний хід каретки триває значно більше часу, ніж приводиться в специфікаціях середній час позиціонування. Наприклад, для диска 2,1 Гбайт позиціонування головки на сусідній циліндр зазвичай займає 1,7 мс, але триває 23 мс для повного ходу каретки (в 13 разів довше). Тому тривале позиціонування головок, що виникає при послідовності звернень до двох різних частин диска, необхідно по можливості виключати.

3.3.6. Рівень завантаження ресурсів вводу-виводу

При виборі конфігурації підсистеми введення-виведення має бути приділено увагу не тільки максимальної місткості її компонентів, але також рівнем використання (завантаженості) кожного ресурсу. Більшість параметрів, використовуваних для опису ємності ресурсів, так чи інакше пов’язані з пропускною здатністю. Наприклад, шина SCSI характеризується пропускною здатністю в 10 Мбайт / с. Це швидкість пересилання бітів по шині. Такий параметр не дає інформації про те, наскільки зайнята сама шина, і, отже, про те, скільки часу буде витрачено на обслуговування даного запиту. Приводити в якості параметра ресурсу рейтинг максимальної пропускної здатності все одно, що говорити, – межа швидкості автомагістралі дорівнює 130 км на годину: якщо в’їзди і з’їзди з неї так перевантажені, що це займає тривалий час, то загальна швидкість, ймовірно, буде набагато нижче встановленої межі.

Точно такі ж принципи застосовні до різних периферійних пристроїв і периферійним шинам. Зокрема, це справедливо і для шин SCSI. Експериментальні результати показують, що якщо повинна підтримуватися пікова продуктивність, то ступінь завантаженості шини SCSI повинна підтримуватися на рівні 40%. Аналогічним чином, ступінь завантаження дисків повинна підтримуватися на рівні 60%. Диски можуть витримувати значно більший ступінь завантаження, ніж шина SCSI, оскільки у вбудованих дискових контролерах є інтелект і кошти буферизації. Це дозволяє координувати роботу буферів доріжок, каретки диска і черги запитів такими способами, які неможливі на досить примітивних головних адаптерах шини SCSI.

Зазвичай не можна оцінити середню ступінь завантаження дисків або шини SCSI до тих пір, поки система не почне працювати. В результаті досить прийнятною виявляється така конфігурація, яка дозволяє розподілити часто використовувані дані і індекси за стільком дискам і шинам SCSI, наскільки дозволяють бюджет і технічні обмеження. Для даних, доступ до яких відбувається не дуже часто, наприклад тільки під час нічний пакетної обробки (або інших полуархівних даних, подібних транзакцій річної давності), можна рекомендувати як можна більш щільну упаковку на накопичувачах.

Як тільки система почне працювати, можна виміряти дійсну ступінь завантаження дисків і відповідним чином перерозподілити дані. Як вказувалося вище, перерозподіл даних повинне виконуватися з урахуванням інших параметрів доступу до диска: скрізь треба підтримувати баланс.

В контексті СУБД є принаймні два механізми для розподілу даних по дискових накопичувачів. Для ефективного розподілу доступу до даних всі відомі СУБД мають можливість здійснювати конкатенацію декількох дискових накопичувачів або файлів Unix. (В СУБД Ingres, наприклад, реалізовано і справжнє розщеплення дисків, обмежене стандартним розміром чергування 16 Кбайт.) Схожі можливості (Крім гарячого резервування і розщеплення дисків) пропонують і багато спеціальні пакети, які можна розглядати як інтегральну частину файлових систем Unix (наприклад, Online: DiskSuite компанії Sun). Файлова система NT моделює файлову систему VMS. Вона включає екстентние файли, можливості прямого і асинхронного введення-виведення, зеркалирования і розщеплення дисків.

Якщо робота з таблицею обмежується можливостями підсистеми введення-виведення, необхідно досліджувати запити, які викликають введення-виведення. Якщо ці запити реалізують довільний доступ до дисків, наприклад якщо багато користувачів незалежно запитують індивідуальні записи, то наявні можливості конкатенації дисків в СУБД повністю адекватні розподілу навантаження доступу по безлічі дисків (при досить повному заповненні простору таблиці). Якщо звернення за своєю природою послідовні, зокрема якщо один або декілька користувачів повинні переглядати кожен рядок таблиці, то більше підходить механізм розщеплення дисків.

Зазвичай СУБД ділять таблицю на кілька відносно великих сегментів і розміщують дані рівномірно по цих сегментах. Головна відмінність між конкатенації СУБД і функцією розщеплення полягає в розміщенні суміжних даних. Коли диски конкатеніруются один з одним, послідовне сканування являє собою важку навантаження для кожного з дисків, але це навантаження носить послідовний характер (тільки один диск бере участь в обслуговуванні запиту). Істинне розщеплення дисків здійснює розподіл даних по набагато більш дрібним кордонів, дозволяючи тим самим всіх дисках брати участь в обслуговуванні навіть порівняно невеликого запиту. Як результат при використанні розщеплення завантаження дисків при виконанні послідовного доступу істотно зменшується. До архівних і журнальним файлів завжди здійснюється послідовний доступ, і вони є хорошими кандидатами для розщеплення, якщо реалізація звернень до таких файлів обмежує загальну продуктивність системи.

У міру зростання розмірів і важливості баз даних процедури резервного копіювання, які виконуються з блокуванням доступу до СУБД, стають практично неприйнятними. При реалізації резервного копіювання в оперативному режимі (режимі on-line) можуть виникнути досить складні питання по конфігурації відповідних коштів, оскільки резервне копіювання великих томів даних, що знаходяться в базах даних, призводить до дуже інтенсивної роботи підсистеми вводу-виводу. Резервне копіювання в оперативному режимі часто викликає дуже високий рівень завантаження дисків і шини SCSI, що призводить до низької продуктивності додатків. Тому особливу увагу зазвичай приділяється конфігурацій всіх пристроїв, залучених в процеси резервного копіювання.

3.4. Мережева підсистема вводу-виводу

Якщо СУБД працює в режимі клієнт-сервер, то мережу або мережі, що з’єднують клієнтів із сервером, повинні бути адекватно обладнані. На щастя, більшість клієнтів працюють з цілком певними фрагментами даних: індивідуальними рахунками, одиницями зберігаються на складі виробів, історією індивідуальних рахунків і т. п. В цих умовах швидкість мережі, що з’єднує клієнтів і сервери, рідко виявляється обмежує фактором. Окремою мережі Ethernet або Token Ring зазвичай достатньо для обслуговування 100-200 клієнтів. Проте з очевидних причин варто більш уважно спостерігати за завантаженням мережі, особливо коли число клієнтів перевищує приблизно 20 на один сегмент Ethernet. Мережі Token Ring можуть підтримувати кілька велике навантаження, ніж мережі Ethernet, завдяки своїй стійкості до деградації під навантаженням. Але навіть якщо з пропускною здатністю мережі не виникає жодних питань, проблеми затримки часто призводять до того, що більш зручною і корисною виявляється установка окремої, виділеної мережі між фронтальним системою і сервером СУБД.

Однак у ряді випадків можливостей мереж Ethernet або Token Ring може виявитися недостатньо. Найчастіше це трапляється, коли дані зберігаються в базі у вигляді дуже великих масивів. Наприклад, у медичних базах даних часто зберігаються образи рентгенівських знімків, оскільки вони можуть бути легко об’єднані з іншими даними історії хвороби пацієнта; ці образи рентгенівських знімків часто бувають розміром в 3-5 Мбайт. Іншими прикладами додатків з інтенсивним використанням даних є системи зберігання / вибірки документів, САПР в галузі механіки та системи мультимедіа. У цих випадках найбільш підходящою мережевий середовищем є FDDI, хоча в порівняно недалекому майбутньому вона, можливо, буде замінена на ATM або Ethernet 100 Мбіт.

Для систем, що вимагають більшої пропускної здатності мережі, чим забезпечують Ethernet або Token Ring, по суті до кінця 1994 року FDDI була єдиним вибором. Хоча концентратори FDDI мають значно велику вартість у порівнянні з хабами Ethernet, установка виділеної мережі між фронтальним системою і сервером СУБД виявляється досить простий і недорогий. Як визначено в стандарті FDDI, мінімальна мережа FDDI складається тільки з двох систем, з’єднаних між собою за допомогою єдиного кабелю. Ніяких концентраторів не потрібно.

Останнім часом різко збільшилася кількість додатків, в яких фронтальні системи і сервери СУБД можуть або повинні розміщуватися в географічно рознесених місцях. Такі системи повинні з’єднуватися між собою за допомогою глобальних мереж. Зазвичай середовищем передачі даних для таких мереж є орендовані лінії з синхронними послідовними інтерфейсами. Ці лінії зазвичай працюють зі швидкостями 56-64 Кбіт / с, 1,5-2,0 Мбіт / с і 45 Мбіт / с. Хоча швидкість передачі даних в такому середовищі значно нижче, ніж звичайні швидкості локальних мереж, подібних Ethernet, природа послідовних ліній така, що вони можуть підтримувати дуже високий рівень завантаження. Лінія T1 пропонує пропускну здатність 1,544 Мбайт / с (2.048 Мбіт / с за межами США). У порівнянні з 3,5 Мбіт / с, забезпечуваних Ethernet в звичайному оточенні, лінія T1 пропонує пропускну здатність, яка кількісно практично не відрізняється від Ethernet. Дробові лінії T3 часто доступні зі швидкостями 10-20 Мбіт / с, очевидно змагаючись з мережами Ethernet і Token Ring. У ряді випадків можна знайти програми, які можуть працювати успішно в конфігурації клієнт-сервер навіть через мережу зі швидкістю 56 Кбіт / с.

Для традиційних бізнес-додатків трафік конфігурації клієнт-сервер зазвичай містить порівняно низький обсяг даних, що пересилаються між фронтальним системою і сервером СУБД, і для них більш низька пропускна здатність мережі може виявитися достатньою. У більшості випадків затримка мережі не є великою проблемою, однак якщо глобальна мережа має особливо велику протяжність або якщо сама середу передачі даних має дуже велику затримку (наприклад супутникові канали зв’язку), додаток повинен бути протестовано для визначення його чутливості до затримок пакетів.

Для скорочення трафіку клієнт-сервер до абсолютного мінімуму можуть використовуватися монітори обробки транзакцій.

Загальною помилкою користувачів є уявлення про те, що мережевий трафік, пов’язаний з термінальними серверами, може перевантажити Ethernet. Це неправильно. Розглянемо, наприклад, 64-портовий мережний термінальний сервер, який може керувати кожним портом, що працюють зі швидкістю 38400 бод, або 38400 символів в секунду. (В кожному байті даних міститься 8 біт інформації, але рейтинг бод включає біти старту і стопа.) Якщо кожен порт працює на повній швидкості 38 400 бод, то всього за одну секунду по мережі буде пересилатися 2457600 байт даних (або приблизно 1,9 Мбіт, тобто близько 20% максимальної завантаження Ethernet) з головної системи в термінальний сервер для подальшого розподілу. Звичайно, є деякі накладні витрати (додаткові байти TCP / IP), пов’язані з цим рівнем трафіку, але вони складають приблизно 50 байт на пакет, тобто приблизно 4% для цього рівня трафіку. Це сценарій найгіршого випадку, наприклад, коли на повній швидкості працюють 64 принтера. Типовий же рівень трафіку набагато нижче: один 2000-символьний екран може відображатися один раз на хвилину. При цих умовах 64-портовий термінальний сервер обробляє приблизно 35 байт в секунду на один порт або всього приблизно 2 Кбайт / с.

Операції щодо введення символів з клавіатури терміналу можна взагалі не розглядати, оскільки навіть найшвидша друкарка друкує тільки 20 символів в секунду (більш типовий випадок 1,0-1,5 символів у секунду). Навіть якщо операції введення обробляються в режимі cbreak, найбільша навантаження, яке буде генеруватися всіма користувачами, може становити 1300 символів в секунду (по 20 символів в секунду на кожен порт при 64 портах). Після врахування максимальних накладних витрат TCP / IP це дає загальний потік в 80 Кбайт / с. Типові навантаження (64 порту по 1,5 символу в секунду) становитимуть близько 15 Кбайт / с з урахуванням накладних витрат.

3.5. PrestoServe/NVSIMM

За визначенням семантики оператора SQL COMMIT_WORK будь СУБД повинна гарантувати, що всі оновлення бази даних повинні направлятися і фіксуватися в стабільній пам’яті (тобто будь-пам’яті, яка забезпечує стійке зберігання даних навіть в умовах збоїв системи або відмов харчування). Щоб СУБД могла дати таку гарантію, вона повинна видавати для виконання, принаймні, деякі зі своїх операцій записи синхронно. Під час виконання таких записів операційна система блокується і не повертає керування викликала програмі до тих пір, поки дані не будуть зафіксовані в стабільній пам’яті. Хоча ця стратегія дуже надійна, разом з тим вона призводить до істотного уповільнення операцій, оскільки при виконанні синхронних записів обов’язково потрібно, щоб дані були записані безпосередньо на доріжку диска. Синхронний запис на “чистий” диск займає приблизно 20 мс, а синхронна запис у файлову систему може зайняти в кілька разів більше часу (якщо потрібно виконати поновлення в непрямі блоки або блоки з подвійним опосередковано).

Зазвичай СУБД здійснюють синхронну запис тільки в свої журнали; у разі відмови системи сама база даних може бути реконструйована з синхронно записаного журналу. Іноді система в цілому стає вузьким горлом в процесі заповнення журналу. Зазвичай це трапляється в середовищі важкої обробки транзакцій, яка виконує численні оновлення бази даних (додатки, що виконують тільки читання бази даних, подібні системам підтримки прийняття рішень, здійснюють трохи записів в журнал). Цей ефект ще більше посилюється при використанні для журнальних дисків дзеркальних пар. У цих випадках для прискорення процесу журналізації часто корисно використовувати PrestoServe або NVSIMM. Фіксація записів в немеханічних NVRAM, що встановлюються на PrestoServe або в NVSIMM, може істотно розширити вузьке горло в деяких системах.

3.6. Забезпечення резервного копіювання

Оскільки зазвичай бази даних бувають дуже великими, і в них зберігається виключно важлива інформація, правильна організація резервного копіювання даних є дуже важливим питанням. Обсяг залучених в цей процес даних зазвичай величезний, особливо по відношенню до розміру і звичайної швидкості пристроїв резервного копіювання. Просто непрактично здійснювати дамп бази даних об’ємом 20 Гбайт на магнітну стрічку 4 мм, що працює зі швидкістю 500 Кбайт / с: це займе приблизно 12:00. У цій цифрі не враховані навіть такі важливі для роботи системи міркування, як забезпечення узгодженого стану бази даних і готовність системи.

Скласти розклад для резервного копіювання системи, яка використовується, головним чином, протягом нормального робочого часу, звичайно порівняно просто. Для виконання процедур резервного копіювання після завершення робочого дня часто використовуються скрипти. В деяких організаціях ці процедури виконуються автоматично навіть без залучення обслуговуючого персоналу, в інших у позаурочний час використовують операторів. Для виконання автоматичного резервного копіювання без залучення обслуговуючого персоналу потрібна можливість його проведення в робочому режимі (режимі on-line).

Якщо система повинна знаходитися в робочому режимі 24 години на добу або якщо час, необхідний для виконання резервного копіювання перевищує розмір доступного вікна (тимчасового інтервалу), то планування операцій резервного копіювання та конфігурування відповідних коштів значно ускладнюються.

У деяких випадках необхідно виконувати резервне копіювання “в режимі on-line”, тобто в той час, коли база даних знаходиться в активному стані з підключеними і працюючими користувачами.

При виконанні резервного копіювання бази даних передбачається, що вона знаходиться в узгодженому стані, тобто усі зафіксовані поновлення бази даних не тільки занесені в журнал, а й записані також в таблиці бази даних. При реалізації резервного копіювання в режимі on-line виникає проблема: щоб резервні копії виявилися узгодженими, після того як досягнута точка узгодженого стану бази даних і починається резервне копіювання, всі оновлення бази даних повинні виконуватися без оновлення таблиць самої бази до тих пір, поки не завершиться її повне копіювання. Більшість основних СУБД забезпечують можливість резервного копіювання в режимі on-line.

Тривалість процедур резервного копіювання, можливо, є найбільш важливим питанням для організацій з великими базами даних (обсягом більше 10 Гбайт), і вибір методики резервного копіювання може визначатися саме цим. Резервне копіювання невеликих баз даних легко здійснюється при наявності всього одного накопичувача на магнітній стрічці Exabyte або DAT. Хоча багато що випускаються в даний час накопичувачі на МЛ дозволяють копіювати дані зі швидкістю приблизно 1,25 Гбайт в годину, для великих баз даних це, очевидно, неприйнятно. Для збільшення пропускної здатності декілька пристроїв можуть працювати паралельно, хоча конфлікти з ресурсів роблять цей спосіб недостатньо ефективним при використанні одночасно більше трьох-чотирьох НМЛ.

Деякі НМЛ на стрічці 8 мм з апаратної компресією здатні забезпечувати швидкість до 6 Гбайт / с, тобто більше ніж удвічі перевищують швидкість стандартних пристроїв. Частина з цих пристроїв мають ємність до 40 Гбайт, але більш типовою є ємність 10-14 Гбайт. Для дуже великих баз даних в якості пристроїв резервного копіювання застосовуються бібліотеки, побудовані на базі стандартних накопичувачів. В І тут важливими є такі параметри, як кількість пристроїв читання / запису в бібліотеці, кількість використовуваних стрічок, наявність пристрою читання BarCode для швидкого пошуку потрібної стрічки. Сучасні стрічкові бібліотеки мають ємність більше одного терабайта (двох терабайт з апаратної компресією) і забезпечують швидкість копіювання до 40 Гбайт в годину.

Якщо недоступне пристрій, який підтримує апаратну компресію, то варто розглянути можливість використання програмної компресії. Швидкість резервного копіювання зазвичай визначається швидкістю фізичної стрічки, тому будь-який метод, який скорочує кількість даних, які необхідно записати на стрічку, повинен досліджуватися, особливо при використанні швидких ЦП. Бази даних є хорошими кандидатами для компресії, оскільки більшість таблиць і рядків включають значну частину вільного простору (зазвичай використовуються навіть коефіцієнти заповнення, що забезпечують певний відсоток вільного простору з метою збільшення продуктивності). Деякі таблиці можуть містити також текст або розкидані поля двійкових даних і готові для компресії.

Перспективним засобом резервного копіювання та архівування інформації вважаються також магнітооптичні пристрої. Правда, поки вони мають порівняно невелику місткість (до 2,6 Гбайт) і порівняно високу вартість носіїв.

Простим, але ефективним способом скорочення часу резервного копіювання є виконання копіювання на окремий дзеркальний диск. Якщо дзеркальна копія зроблена безпосередньо після контрольної точки, або після того, як база даних виключена, вона дейстительно стає дискової резервною копією on-line, яка сама може бути скопійована в будь-який зручний час. Можна навіть виконати рестарт бази даних, щоб продовжити нормальну обробку, хоча з меншою надмірністю. Якщо доступно достатню кількість дискових накопичувачів, то може бути використаний і другий набір дзеркальних дисків, що дозволяє зберегти повне віддзеркалення, навіть коли один набір дзеркальних дисків відключається (під час нормальних операцій диски будуть віддзеркалюватись у трьох напрямках). В цьому випадку резервне копіювання в режимі on-line може продовжуватися після копіювання на стрічку, що забезпечує в разі потреби дуже швидке відновлення. Цей додатковий набір дзеркальних дисків міг би бути заново підключений перед наступною контрольною точкою, забезпечивши достатньо часу (приблизно 30 хвилин), яке дозволить цього набору дзеркальних дисків синхронізувати з дзеркальними дисками, які працювали в режимі on-line.

Більшість користувачів виконують повне резервне копіювання щодня. Вважаючи, що резервне копіювання виконується на той випадок, коли знадобиться відновлення, важливо розглянути складові часу відновлення. Воно включає час перезапису (зазвичай зі стрічки) і час, що потрібно для того, щоб виконати зміни, внесені в базу даних з моменту резервного копіювання. Враховуючи необхідність засобів такої “прокрутки” вперед, дуже важливо віддзеркалювати журнали та журнали архівів, які і роблять цей процес можливим.

У робочому середовищі, де велика кількість транзакцій виконують записи в базу даних, час, необхідний для виконання “прокрутки” вперед від останньої контрольної точки може істотно збільшити загальний час відновлення. Це міркування само по собі суттєво для визначення частоти резервного копіювання.

Виконання процедур резервного копіювання повинно відповідним чином відслідковуватися, щоб гарантувати, що вони завершилися успішно. Також важливо документувати і тестувати процедури відновлення. Момент аварії – не надто вдалий час для виявлення того, що в стратегії резервного копіювання пропущені деякі ключові елементи.

Висновок

Результати випробувань багатьох систем на тестах TPC-A, TPC-B, TPC-C і TPC-D продемонстрували, що на сьогоднішній день є всі передумови (необхідна продуктивність і відповідне ПО) для повного переносу додатків оперативної обробки транзакцій і систем підтримки прийняття рішень з мейнфреймів на системи, побудовані на базі мікропроцесорів. При цьому однією з актуальних завдань є вибір апаратно-програмної платформи та конфігурації системи.

Оцінка конфігурації все ще залишається деяким видом мистецтва, але до неї можна підійти з наукових позицій. Для виконання аналізу конфігурації система (під якою розуміється весь комплекс комп’ютерів, периферійних пристроїв, мереж та програмного забезпечення) повинна розглядатися як ряд з’єднаних один з одним компонентів. Обмеження продуктивності деякої конфігурації з будь-якого напрямку (наприклад, в частині організації дискового вводу-виводу) зазвичай можуть бути передбачити виходячи з аналізу найбільш слабких компонентів.

Оскільки сучасні комплекси майже завжди включають кілька працюючих спільно систем, точна оцінка повної конфігурації вимагає її розгляду як на макроскопічному рівні (рівні мережі), так і на мікроскопічному (рівні компонентів або підсистем).

Література

1. M.T. Franklin, E.H. Welbon. POWER2: Performance Measurement and Analysis of TPC-C, COMPCON 94, IEEE 1994.

2. J. Gray, C. Nyberg. Desktop Batch Processing, IEEE 1994.

3. Digital”s 21164 Reaches 500 MHz, Microprocessor Report, V. 10, # 9, July, 1996.

4. А.А. Волков. Тести TPC. – СУБД, # 2, 1995.

5. Г.М. Ладиженський. Tuxedo System: розробка систем клієнт-сервер. – СУБД, # 1-2, 1996.

В.З. Шнітман,
Інститут системного програмування РАН,
тел.: 912-56-59

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*