«Спеціалізовані бази даних, хмарні технології і DevOps НЕ скасовують роль адміністраторів, а навпаки - розширюють їх функції. Можливо, справа вже не тільки в таблицях. Але роль адміністратора БД досі важлива, навіть якщо у цій професії немає назви ». Син Ґалагер
В уяві тих з нас, хто занадто довго працює в сфері інформаційних технологій, посаду «адміністратор БД» ( «АБД») породжує досить-таки специфічні образи. Ми представляємо кого-то, що рве на собі волосся через проблеми з резервних копій (резервними копіями), глюків зі знімками файлової системи (снапшотов), що вийшли з-під контролю схем, зірваних планів нарощування потужностей у зв'язку з новими вимогами додатків, уповільнених запитів і вічних налаштувань продуктивності.
Всі ці функції адміністраторів старого гарту ще подекуди зустрічаються, особливо на великих підприємствах, де гігантські кластери баз даних як і раніше правлять дата-центрами. Але віртуалізація, хмарні сховища даних, мікросервіси, DevOps-підхід до розробки і запуску додатків і ряд інших факторів істотно змінили те, як організації зберігають свої дані і керують ними. Багато традиційних ролі адміністратора БД представляються спірними в тому щасливому новому світі, який обіцяє нам нове покоління баз даних.
NoSQL бази даних не вимагають визначеної схеми даних, а багато реплікації вбудовані за замовчуванням. Підготовку нових серверів до роботи можна звести до натиснення декількох перемикачів (радіо-Баттон) і виставлення галочок на веб-сторінці. Команди розробників просто вибирають точку в хмарному сховищі, такому як Amazon Web Services Simple Storage Service (S3), і йдуть відпочивати (roll). І навіть розробники реляційних БД, таких як Oracle, Microsoft і IBM, підштовхують клієнтів до data-as-a-service (DaaS) моделям, кардинально спрощує доступність і управління обладнанням.
Ви могли подумати, що від цього робота адмінів БД стає легше. Ні в якому разі.
«Я думаю, що їх завдання [адмінів БД] стали значно складнішими, - сказав Кріс Лалонд, віце-президент і генеральний менеджер по роботі з даними компанії Rackspace. - Поки у нас не буде виразно більшою автоматизації і технологічного оснащення (інструментарію), багато нові технології будуть менш зрілими і їх потрібно буде пестити і леліяти (вони вимагають більше догляду та годування). Я хочу сказати, що багато з традиційних завдань адмінів БД все ще існують або повинні існувати ».
Насправді всі ці чудові нові технології підкреслюють професіонала в області даних, будь то адміністратор БД, архітектор даних, data engineer або навіть, в деяких випадках, data scientist. «Сьогодні дані ще більш важливі, - сказав Кенні Горман, ветеран БД і співзасновник Eventador (сервіс для передачі даних в режимі реального часу). - Компанії звикли покладатися на бази даних, щоб бути «на підйомі» (to be sound), працювати гладко і давати хорошу звітність. Але сьогодні дані і справді роблять вас більш конкурентоспроможними, і існує більше різних професій, пов'язаних з даними, і більше технологій, їх використовують. І професіонал по БД - в самому центрі ».
На крок вперед.
Нереляційні платформи пообіцяли знизити навантаження на адміністраторів БД. У деякому роді вони, дійсно, зробили це. Рави Меюрем, старший віце-президент Couchbase Inc. по продуктам і розробкам, порівняв зрушення в обов'язки АБД зі зміною водіння автомобіля (протягом багатьох років): давним-давно «для того, щоб водити машину, ви повинні були по суті бути інженером; і коли щось йшло не так, вам потрібно було звертати з дороги і лізти під капот. Тепер речі самі дбають про себе, але я безсилий їх виправити ».
Такі бази даних як MongoDB і CouchBase, хоч вони і не реляційні, підтримують SQL запити. У них є й інші аспекти, що викликають прихильність досвідчених адміністраторів БД. Але вони також надають «можливості динамічного розгортання, яких немає у реляційних систем, - стверджує Меюрем. - А додавання нових структур даних зазвичай вимагає зміни схеми і тягне до простою ».
Дані як якась Послуга були віддані «на відкуп компаній, - вважає Меюрем. - Більшість компаній не тримають в хмарі критично важливу інформацію ».
У той час як більша реляційна система управління базами даних вимагає розуміння всього апаратного та програмного забезпечення, «наступне покоління АБД буде замішаний в цьому набагато менше, - пояснює Меюрем. - До адміну БД буде пред'являтися, наприклад, таку вимогу: всеохоплююче розбиратися в базах даних, але не тільки », щоб зосередитися на таких завданнях як планування потужностей. АБД майбутнього повинен буде знати, коли слід забезпечити великою кількістю серверів, а коли вилучати їх з обігу.
Такого роду динамічна масштабованість і привела до вибору хмарних сервісів даних на основі спеціалізованих БД і «Data-as-a-Service схем» (розміщеним або у себе, або на сторонньому хостингу). У будь-якому випадку - сервіси постачання можуть подбати про налаштування апаратних засобів, мережі та системи зберігання даних. Теоретично АБД повинні сконцентруватися на з'ясуванні того, коли з додатком буде потрібно більше можливостей (великі обсяги) баз даних. «Це приклад функції DevOps, а мати справу з динамічним постачанням - це трохи інший профіль, - каже Меюрем. - Для більшої ефективності їм не потрібно так багато навичок АБД, вони швидше повинні вміти планувати потужності і краще розбиратися в розробці ».
Для тих, хто не знає, DevOps - це практика, яка сьогодні широко використовується в WEB'е і розробці сервісів. Вона описує, як команди розробників додатків працюють спільно з айтішників, щоб постійно підвищувати продуктивність, автоматизацію і масштабованість програмного забезпечення і систем. DevOps підхід став основним двигуном переходу на NoSQL бази даних та інші нетрадиційні технології зберігання даних і запитів. DevOps привів до розвитку Data-as-a-Service - в основному через необхідність автоматизувати масштабування ємностей баз даних. Але навіть в суто реляционном світі зрушення в бік перетворення баз даних в хмарні сервіси зводить до мінімуму необхідність (і навіть саму можливість) дрібномодульних контролю апаратної конфігурації з боку АБД.
До теперішнього часу дані як якась Послуга були віддані «на відкуп компаній, - вважає Меюрем. - Більшість компаній не тримають в хмарі критично важливу інформацію ». Першопрохідці, зазначив він, застосовують гібридний підхід зі створенням внутрішніх DaaS платформ на основі хмарних обчислювальних платформ в своїх власних дата-центрах. Але інші компанії в більшості своїй залишають свої критично важливі реляційні системи як є, а хмарні технології використовують для нових проектів. «Вони до сих пір містять адмінів БД, що піклуються про існуючі програми, але мають і DevOps команди для розгортання баз даних в середовищі мікросервісов - сервісів, які не повинні бути реляційними системами», - пояснив Меюрем.
А ось з компаніями, що вони бережуть свої реляційні бази даних і відчувається все більшу потребу в подоланні розриву між старим і новим, справа йде швидше складно, ніж просто. І навіть коли організації повністю віддають на аутсорсинг додатки, які мають, як правило, найбільші вимоги до адмінам БД, вони все ще потребують професіонала по роботі з даними, щоб зрозуміти, у що вони вплуталися.
Нижче наведена схема бази даних для MediaWiki - платформи, що використовується Wikipedia. Деякі спеціалізовані бази даних не вимагають схем в явному вигляді, але схема живе по-іншому, і розуміння структур даних залишається важливим.
Чутки про смерть сильно перебільшені
«Сенс цього висловлювання в тому, що АБД як і раніше важливий», - нещодавно повідомив Горман компанії Ars. Як давній адміністратор баз даних Oracle і архітектор даних в компаніях, що працюють з PayPal і eBay, Горман виявився зануреним в MongoDB на Shutterfly, та ще й адептом NoSQL. У статті, яку він написав, будучи головним архітектором data-as-a-service провайдера ObjectRocket, Горман зазначив: «Більшість наших клієнтів не мають в штаті адміністраторів БД». Але це не означає, що роботи для них не залишилося.
«У міру просування до хмари, - пояснює Горман, - з дата-сервісами, мікросервісамі і всім« бессерверной »рухом (сервіси типу Amazon Web Services 'Lambda і Google Cloud Functions), світ обробки даних продовжує еволюціонувати. Він змінив і роль адміна БД - це вже не той хлопець, який управляє сервером Oracle в дата-центрі для конкретної компанії. Тепер є технології зберігання даних, що існують по всьому хмарі в різних формах, якими він повинен керувати.
Незважаючи на те, що багато хто з цих нових технологій баз даних автоматизували більшу частину того, що зазвичай робив АБД, це зовсім не означає, що відбулося зменшення навантаження на адмінів БД. «Я вважаю, що автоматизація зменшила потребу в традиційних Ops'ах, так як вони допомагають масштабувати апаратне забезпечення і, отже, обсяги запитів, - сказав Лалонд. - Але існує не так багато інструментів, які допомагають знаходити і виправляти повільні запити, а також вибирати найкращий shard key, - пояснив він. - Я впевнений, що автоматизація дозволить працювати у великих масштабах з меншими ресурсами, але в кінцевому підсумку вам як і раніше потрібен експерт, розбирається в усьому цьому ».
Горман вважає, що складність нового середовища обробки даних робить роботу адміністраторів БД не легше, а ще важче, ніж раніше. Це почасти тому, що адміни БД вже не можуть бути настільки вузько спеціалізованими, як вони були колись. «Колись я запускав сервери баз даних для PayPal і eBay за один день, - пояснює він, - і у нас була одна-дві технології, а не 50. Якщо ти знав Oracle, ти міг, можливо, розібратися з Microsoft SQL сервером - ці технології доповнюють один одного ». Тепер все не так, стверджує Горман. Сьогодні ви повинні розуміти різницю між Elasticsearch, Hadoop, [Apache] Kafka і Oracle - чим вони відрізняються, і чому в конкретному випадку одна з них краще, ніж інша ».
Через темпів зміни технологій зберігання даних і запитів тепер навіть не зовсім зрозуміло, що ж таке база даних. І багато технологій, що передаються професіоналам у сфері обробки даних, мало схожі (незважаючи на їх назви) на що-небудь з того, з чим вони працювали раніше.
«Наша професія поступово еволюціонувала, залишивши позаду системи управління і зберігання даних в роді БД, - сказав Горман. Oracle була явно базою даних. Але в наші дні саме поняття про те, що таке база даних, змінилася. Наприклад, Hadoop - це база даних? »У ObjectRocket Горман вибудував дата-сервіси навколо MongoDB. «Досить очевидно, що це база даних, - сказав він, - але наш новий стартап заснований на [Apache] Kafka - а це база даних?» (Kafka - це сервер, іменований брокером, який поставляє додатків реального часу потоки даних з «підписок »запитів)« Ну так, вона має властивості бази даних. Тобто перетасовує дані в режимі реального часу. Таким чином, це божевільна еволюція, при якій ми навіть не знаємо, чи є взагалі продукт або інфраструктура даних - базою даних. Вода дуже мутна. Тепер це реально системи обробки даних, і у кожної з них є свої нюанси і компоненти ».
Але дещо не змінилося навіть з приходом нових технологій. «Оптимізація запитів і переміщення даних нікуди не поділися, так само як і потреба контролювати і підтримувати ці бази даних, - вважає Лалонд. - І у цих «бессхемних» баз даних, як з'ясовується, в дійсності теж є схеми, - просто вони більш вільно визначаються ».
В результаті, підсумував Лалонд, адміни БД «повинні мати ті ж навички, які вони мали завжди. Звичайно, сучасні адміни повинні бути більш гнучкими, розуміти весь спектр технологій, а також добре себе почувати в гнучкою методології розробки (agile). Загалом, ми очікуємо того, хто дійсно розуміє основи теорії баз даних, тому що розуміння цих основ прекрасно транслюється крізь різні технології ».
І все ж, хто такий АБД?
Зрушення в інформаційних технологіях (технологіях обробки даних) і то, як вони розгорнуті, не тільки додав роботи адміну БД - він також визначив, хто такий АБД.
З поширенням операційних завдань, пов'язаних з базами даних і тяжіють до операційної стороні «DevOps», роль АБД набагато тісніше пов'язана з процесом розробки додатків. А навички, традиційно приписувані АБД, тепер набагато важливіше для команд розробників і операціонщіков.
«Я вважаю, що автоматизація зменшила потребу в традиційних Ops'ах, так як вони допомагають масштабувати апаратне забезпечення і, отже, обсяги запитів ... Я впевнений, що автоматизація дозволить працювати у великих масштабах з меншими ресурсами, але в кінцевому підсумку вам як і раніше потрібен експерт, розбирається в усьому цьому ».
«Я думаю, що ролі розробника, DevOp'а і фахівця з даними - це може бути data engineer, АБД або data scientist - повинні справлятися з безліччю нових технологій, - вважає Горман. Кожна з цих технологій має свій власний спектр зрілості, функцій і можливостей ». А це означає, що кожна з цих ролей тепер вимагає принаймні деяких навичок АБД.
Той, хто в кінцевому підсумку стає адміном БД для цих систем, не просто повинен мати загальне уявлення про них, - він потребує куди більш тонкому розумінні того, що відбувається всередині їх систем, ніж йому було потрібно колись для реляційних баз даних. Подібно до того, як поведінка SQL запитів можна налаштувати в достатній мірі для будь-якої реляційної бази даних, отримання максимальної продуктивності від новітніх нереляційних систем вимагає від АБД глибокого розуміння їх внутрішньої роботи.
Це той рівень обізнаності, який колись був прерогативою найбільш досвідчених адміністраторів баз даних і програмістів. Але оскільки дані стають все більш децентралізованими, розширюються і вимоги до ролі АБД в IT-організації. Беручи до уваги той факт, скільки часу багато людей витрачають на управління своїм особистим масивом структурованих і неструктурованих даних, ми все можемо стати хорошими АБД з цієї точки зору.