Цей контент є частиною серії:
Слідкуйте за виходом нових статей цієї серії.
Характеристика «великий» або «швидкий» негайно викликає у нас цілком закономірне питання: «У порівнянні з чим?» Справді, база даних, яку невелика компанія вважає просто величезною, здасться крихітної в порівнянні з національним репозиторієм, збільшується щороку на 28 петабайт. «Швидка» база даних, яка обслуговує транзакції сайту електронної комерції виявиться занадто повільної в порівнянні з базами даних, які використовуються для автоматизації біржових операцій і забезпечують час доступу, що вимірюється в мілісекундах.
Але навіть якщо ваша компанія не претендує на володіння найбільшою або найшвидшою базою даних на планеті, кілька уроків по частині адміністрування таких баз даних можуть виявитися цілком корисними і для вас. Очевидно, що тенденції розвитку «екстремальних» баз даних рано чи пізно зроблять свій вплив на архітектуру і роботу бази даних будь-якого розміру.
Що значить «надвелика»
Неухильне зростання інформаційних потоків вимагає відповідного збільшення загальнодоступних і комерційних баз даних. Всього чотири роки тому за даними WinterCorp найбільшими в світі вважалися бази даних з об'ємом сховища близько 100 ТБ. База Yahoo! стала першою базою даних за десятирічну історію досліджень, яка подолала рубіж в 100 ТБ.
Яка ж база даних в наш час, коли обсяги збереженої цифрової інформації постійно зростають, може претендувати на визначення «надвелика»? Загального стандарту розподілу баз даних за розмірами не існує. До того ж, необхідно мати на увазі, що розмір сховища даних не є сьогодні основною характеристикою бази даних, не менш важливим фактором є її керованість. Одне з можливих визначень «надвеликої» бази належить доктору Роберту Холлебеку (Robert Hollebeek), професору фізики університету Пенсільванії, одному із засновників проекту National Scalable Cluster Project і власникові кількох національних премій за розробки в області розподілених кластерних систем і дослідження даних. Холлебек стверджує, що п'ять років тому база даних об'ємом в кілька терабайт могла претендувати на звання «надвеликої». Сьогодні для цього потрібна наявність сховища об'ємом в кілька петабайт. «Можливо і інше визначення надвеликої бази даних - це база, чий індекс не поміщається у фізичній пам'яті, навіть в терабайтной пам'яті суперкомп'ютера або комп'ютерного кластера», - продовжує Холлебек. База даних з індексами такого порядку є «надвеликої». Використання «надвеликих» баз даних породжує ряд проблем з точки зору продуктивності і адміністрування.
Холлебек також стверджує, що «надвеликої» може вважатися така база даних, для якої важко підібрати потрібний обсяг апаратних ресурсів. «Якщо у вас тисячі дисків або серверна, повна стійок з паралельними машинами, то такою системою стає важко управляти».
Мануель Гомес Бюрріель (Manuel Gomez Burriel), лауреат програми IBM Information Champion і співробітник Іспанської конфедерації ощадних банків Confederacion Espanola de Cajas de Ahorros (CECA), згоден з тим, що керованість може використовуватися в якості критерію, що дозволяє визначити, які бази даних є « надвеликими », а які - цілком звичайними великими базами даних. «Стандартні завдання адміністрування перестають вкладатися в певні часові вікна», - каже Гомес. Відновлення бази даних в разі збою може зайняти кілька годин, в той час, як необхідно вкластися в кілька хвилин. Продуктивність також виявляється під питанням, так як база даних занадто велика і ніяка її більш-менш значна частина не може бути завантажена в оперативний кеш. Обробка цілком стандартних запитів додатків на отримання даних може вимагати абсолютно неприйнятне кількість циклів ЦПУ.
Портрети бази даних
Досвід в сфері управління даними, отриманий при детальному вивченні архітектури та принципів роботи однієї «надвеликої» бази, може з успіхом використовуватися при роботі з іншими базами даних, великими і не дуже. Холлебек був провідним технічним фахівцем Національного цифрового архіву мамографії (NDMA, National Digital Mammography Archive), системи, розрахованої на базу даних, що збільшується на 28 петабайт в рік. Завдяки фондам, виділеним Національним інститутом охорони здоров'я США (U.S. National Institutes of Health), NDMA розробив розподілену мережу систем для зберігання медичних даних, знімків і результатів досліджень. Система використовувалася в якості сховища результатів мамографії, знімків, отриманих в результаті магнітно-резонансного дослідження та інших даних, які відповідали кожному випадку захворювання і могли становити до гігабайта даних. В архіві зберігалися дані мільйонів пацієнтів. Крім питань зберігання та організації доступу до великих обсягів інформації, NDMA довелося зіткнутися з проблемою незв'язаних даних, що зберігаються в географічно розподілених системах - завданням, яку доводиться вирішувати практично всім глобальним підприємствам. Для того щоб зв'язати чотири науково-дослідних медичних центру, що беруть участь в проекті, NDMA створив захищені лінії для передачі зашифрованих даних. Кожен медичний центр мав свою точку входу з апаратним забезпеченням для шифрування даних. Дані по мережі передавалися зі спеціального протоколу, призначеному для роботи з великими блоками інформації.
«Наш проект був досить масштабним, і ми не могли дозволити собі втратити будь-яку медичну інформацію. Нам була потрібна наднадійних технологія, що гарантує високу продуктивність і паралелізм, так як наша структура грунтувалася на використанні кластерів паралельних машин », - розповідає Холлебек. «Система повинна була мати високу отказоустойчивостью, оскільки ми не могли допустити, втрати або збою індексних таблиць». Для індексних таблиць NDMA використовував програмне забезпечення IBM DB2 Parallel Edition. Графічні дані зберігалися в однорівневих базах даних на паралельних дискових масивах під управлінням «рідних» файлових засобів операційної системи, в якості якої був обраний Linux.
уроки NDMA
Грунтуючись на своєму досвіді роботи в NDMA, Холлебек виробив кілька загальних рекомендацій для роботи з «надвеликими» базами даних, з'єднаними за допомогою глобальних мереж (WAN):
- Зверніть особливу увагу на проблеми передачі великих обсягів інформації по мережі, будь то Інтернет або корпоративну мережу. Знайдіть найбільш ефективний спосіб передачі, наприклад, за рахунок створення точок входу в місцях отримання і відправки даних або за рахунок використання протоколу, що забезпечує ефективну передачу великих (кілька мегабайт) блоків даних.
- Не міняйте формат отриманих даних. Стиснення даних без втрат інформації - річ, безумовно, корисна, однак в разі використання великих баз даних невеликий виграш в обсязі ніяк не окуповує проблеми, пов'язані зі зворотним перетворенням даних і організацією їх зберігання при отриманні.
- Як тільки індексні таблиці перестають поміщатися в пам'яті, продуктивність бази даних різко падає, тому нарощуйте пам'ять до максимуму. Якщо можливості збільшення обсягів пам'яті вичерпані, використовуйте паралельні структури для організації даних з тим, щоб ефективно використовувати кластерні системи. Якщо і це неможливо, використовуйте індекси для індексних таблиць.
Що значить «надшвидка»
Такої ж думки дотримується і Гомес, визначаючи «надшвидку» базу даних як «досить швидку для того, щоб надавати необхідну інформацію відповідно до узгоджених з клієнтами SLA». «Найшвидші бази даних звертаються безпосередньо до даних в пам'яті, якщо це можливо. Одне з наших програм, що функціонує як частина платіжної системи, використовує IMS і Fast Path Solution, а також корпоративну підсистему зберігання даних і забезпечує час відгуку менше ніж 20 мілісекунд на одну транзакцію, і це за умови, що додаток використовує до 14 баз даних для отримання клієнтської інформації », - продовжує Гомес.
Секундна затримка - це занадто довго
Незважаючи на те, що раніше фінансові системи, що використовуються для обслуговування банкоматів (ATM) вважалися дуже швидкими, зараз вони перейшли в ранг аутсайдерів за швидкодією. «Якщо раніше ви чекали секунду, щоб отримати інформацію про вашому балансі, і вважали, що це дуже швидко, то зараз це всього лише середній результат», - говорить Олофсон. Сьогодні, обговорюючи високошвидкісні операції з базами даних, експерти мають на увазі телекомунікаційні комплекси, в яких в процесі виконання з'єднання система перевіряє всі дані про рахунок клієнта, включаючи можливі види обслуговування. Таким чином, система отримує інформацію про маршрутизації з'єднання і про те, які функції при цьому повинні бути враховані, - і все це в глобальній бездротової середовищі, де будь-який рахунок може змінитися в будь-який час.
Ще одним прикладом додатків, що вимагають високошвидкісної обробки даних, є алгоритми біржової торгівлі, які визначаються портфелем фінансових послуг. «Компанія може обслуговувати сотні рахунків, кожен з яких відрізняється своїм портфоліо і, отже, вимагає індивідуальних правил управління можливими біржовими угодами», - продовжує Олофсон. «Ці правила повинні визначатися і застосовуватися протягом тих мілісекунд, які займає передача ціни пакета по мережі. Здатність фінансової системи забезпечити таку швидкість операцій визначає різницю між успіхом і провалом в управлінні рахунками клієнтів ».
Подібна швидкість операцій пред'являє високі вимоги до швидкодії внутрішніх баз даних, які, як правило, утворюють багаторівневу систему зберігання і доступу до даних. У багатьох випадках в якості внутрішньої бази даних використовується бази даних на мейнфреймах, наприклад IMS, ієрархічна система управління базами даних IBM на мейнфреймах. В якості первісної високошвидкісний середовища обробки даних використовується оперативний кеш, а в якості основної бази для зберігання даних - багаторівнева структура на мейнфреймах. Клієнти, які потребують надшвидкісних фінансових системах, є основними інвесторами подібних багаторівневих рішень.
Новітні розробки для вибухового зростання продуктивності баз даних
Очевидно, що міру появи і розвитку нових технологій, вимоги до швидкодії систем будуть тільки зростати, так що виробники продовжують шукати нові способи підвищення швидкодії баз даних. Одне з найбільш популярних сьогодні напрямів досліджень зосереджено на вирішенні проблеми традиційно слабкої ланки в ланцюгу передачі даних - жорсткого диска. Рішення, що використовують кешування даних в оперативній пам'яті, такі як IBM solidDB, переносять операції по роботі з даними з порівняно повільної пам'яті на жорсткому диску в порівняно швидку RAM, значно скорочуючи тим самим час відгуку. Більш детальний огляд баз даних solidDB ви можете знайти в статті «solidDB and the Secrets of Speed» в цьому ж випуску.
Таким чином, центр ваги апаратних засобів підтримки баз даних неухильно зміщується від дискової пам'яті до RAM, а технології управління даними все частіше ставлять в основу ефективне використання ресурсів ЦПУ. Паралельно з цими напрямками з'являються і нові гнучкі рішення, націлені на утилізацію різного рівня навантажень баз даних. Замість загальноприйнятого способу зберігання даних у вигляді рядків таблиць, архітектори баз даних переходять до баз даних, заснованих на шпальтах або пулах даних з матрицями індексів. Нові структури забезпечують новий рівень гнучкості в організації зберігання даних. З точки зору програми, що працює з подібними базами даних, такі сховища можуть розглядатися в якості звичайної реляційної бази даних, але можуть бути розширені для роботи в якості об'єктно-орієнтованих баз даних, баз даних XML, багатозначних або багатовимірних баз даних.
Цілком очевидно, що при розгляді «надвеликих» і «надшвидких» баз даних покупець буде орієнтуватися на останні технологічні рішення. Як би не були великі ваші вимоги до обсягу збережених даних або до швидкості їх обробки, компанії-виробники постійно вдосконалюють свої технології і розробляють нові рішення, щоб мати можливість запропонувати вам продукт, який повністю відповідає вашим побажанням. І точно так само, як в лінгвістиці, моді та мистецтві, то, що вважалося вчора видатним досягненням, завтра стане звичайною практикою.