+38 044 333 61 23 Business Center “Gulliver”,Sportyvna Square 1,Kyiv, 01023 info@allstars-it.com

Недоліки безкоштовних СУБД

Ми звикли вважати відкрите програмне забезпечення своєрідним безкоштовним ключем до вирішення всіх проблем. Проте подібна система керування базами даних може стати джерелом досить дорогих у вирішенні проблем. Ви зможете зрозуміти детальніше в статті Євгена Недашківського, DBA/Developer в AllStars-IT Ukraine.

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

Звісно, не буває поганих інструментів, бувають тільки неоптимально підібрані. І якщо довготривала експлуатація показала правильність архітектурного рішення – вас можна тільки поздоровити. Якщо ж ні… Часто вартість змін себе не виправдовує і доводиться працювати з тим, що є.

Переваги опенсорсу

На сьогодні досить популярним вибором системних архітекторів є програмне забезпечення з відкритим програмним кодом. Дійсно, у порівнянні з “класичним” захищеним патентами ПЗ, “опенсорс” має низку незаперечних переваг, а саме:

  • Нульова ціна придбання

  • Можливість вільно модифікувати код під свої потреби

  • Велика кількість гілок та варіацій

  • Значна розповсюдженість популярних продуктів та рішень

  • Наявність спільнот, що активно тестують та поліпшують подібні СУБД

Проте є у таких рішень і низка мінусів, про які не заведено згадувати. Сьогодні ми говоримо саме про них. І почнемо з…

Загальнодоступність коду

Почнемо з мінуса, який витікає з плюсу та є добре відомим – легкість аналізу коду сторонніми особами. Security in obscurity. Важко зламати те, що невідомо як працює. Коли ж код відкрито всім – його проблеми загальнодоступні. Пошук вразливих місць в рази спрощується, і немає жодних гарантій, що спеціаліст, який знайшов проблему, має добрі наміри.

Проблеми з версіями

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

Проблеми з пререквізитами

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

Встановлення

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

Імпорт даних

Сама по собі СУБД ніщо без баз даних, якими вона керує. Якщо мова йде не про новий проект, де інфраструктура даних створюється з нуля, то потрібно замислитися про перенесення вже накопиченої інформації у новий формат. Цим успішно займаються консалтингові фірми, які заробили не один мільйон доларів на подібних задачах. Чому? Тому що вони не є тривіальними. Різні типи даних, особливості реалізації мови SQL, обмеження в функціональності об’єктів та архітектури – досить короткий перелік того, з чим доведеться зіштовхнутись. Міграція з однієї СУБД на іншу – це завжди великий та вартісний проект. Звісно, це не залежить від того, про відкритий продукт ми говоримо, проте дуже часто закриті корпоративні продукти, на кшталт Microsoft SQL Server мають вбудовані та акомпануючі інструменти з імпорту та міграції. Більшість відкритих рішень не можуть похизуватися нічим подібним.

Інтеграція з існуючими системами

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

Кастомізація ПЗ

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

Навчання

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

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

Коли ж програмний продукт потрібно продати, роботу з ним намагаються зробити максимально зручною та простою. До послуг покупця безкоштовні семінари, друковані та відео навчальні матеріали. А запопадливі менеджери готові відповісти на всі ваші питання.

Обслуговування

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

Підтримка

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

Спеціалісти

Також існує і певна кадрова проблема. По-перше, існує думка, що якщо у компанії немає коштів на придбання програмного забезпечення, то звідки в неї гроші на оплату провідних спеціалістів? Відштовхуючись від цієї ідеї, досить багато експертів вирішують будувати свою кар’єру трохи далі від відкритого програмного забезпечення, мотивуючись тим, що знання пропрієтарного ПЗ краще оплачується на ринку. Думка не позбавлена підґрунтя.
Пов’язаною проблемою також є навчання та сертифікація подібних спеціалістів. Зазвичай такі компанії як Oracle, Microsoft та SAP пропонують спеціалізовані курси та перевірку знань відповідним тестуванням, що дозволяє спростити компаніям-клієнтам процес пошуку та підняття кваліфікації співробітників. Відкриті СУБД, за деякими винятками, не можуть похизуватися подібним підходом.

Жодних гарантій

Наскільки ви впевнені в тому, що ваша опенсорс СУБД буде розвиватися і далі? Що вийдуть нові релізи? Що знайдені проблеми будуть виправлені, а функціонал, про який всі давно просили буде додано? Навіть великі та досить успішні проекти, які мають активну підтримку спільноти та багаторічну історію часто уповільнюють темп розробки, а іноді й взагалі зникають з обрію. Що вже говорити про щось нове.
Можете задати собі питання і про те, хто буде відповідальним у разі втрати або псування даних у випадку програмної помилки? Ваш співробітник? Спільнота? Група розробників-волонтерів, що написали СУБД? Розробник пропрієтарного продукту відповідав би за законом. У світі вільного ПЗ ніхто нічого нікому не винен.
Можливо це і є однією з причин, чому частина спеціалістів у галузі намагається триматися від нього подалі. Адже де гарантії, що ваша СУБД не зникне, залишивши вас без роботи? Або що “цапом відбувайлом” у випадку проблем з продуктами не зроблять розробника, адміністратора, чи їх керівника?
Немає жодних гарантій.

Вартість

Свого часу керівник Sun Microsystems Скот МакНіллі у плані витрат порівняв відкрите програмне забезпечення з цуценям. Так, можливо взяти з притулку маленьке щеня – це благородна справа, яка вам нічого не варта… Але чи є у вас ілюзії, що утримання чотирилапого друга буде безкоштовним?

Враховуючи пункти, що були зазначені вище, стає зрозумілим, що вартість життєвого циклу (англ. Total Cost of Ownership, TCO) для опенсорсу – це тисячі та тисячі доларів. А якщо рішення, що будується – велике, то це сотні, якщо не мільйони грошових одиниць на рік на впровадження, підтримку та навчання персоналу.

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

Висновки

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

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

Leave a Reply