- Це ж треба, - ні до кого не звертаючись, голосно сказала вона. - Це ж треба! Так прямо і написано – головним завданням суспільства є одержання прибутку на користь акціонерів. Ну, ви подумайте! Нічого не бояться!
Юлій Дубов, «Менше зло»
Побачивши такий заголовок, ви напевно вже вирішили, що стаття – чи то дурість, чи то провокація. Але не поспішайте з висновками: співробітникам великих корпорацій, особливо корпорацій з державною участю, часто доводиться порівнювати різні платформи, в тому числі й зовсім різні - наприклад, як ті, що винесені в заголовок.
Звичайно, СУБД так ніхто не порівнює, бо їхні сильні та слабкі сторони добре відомі. Як правило, порівнянню підлягають платформи, що вирішують будь-яке прикладне завдання. У статті я покажу методику, яка при цьому використовується, на прикладі баз даних як предмета, не з чуток знайомого читачам Хабра. Отже,
Мотивація
Коли ви починаєте навчальний проект або проект-хобі, мотивація для вибору платформи може бути найрізноманітнішою: «цю платформу я найкраще знаю», «з цією мені цікаво розібратися», «тут найкраща документація»… У разі комерційної компанії критерій вибору один: скільки доведеться заплатити і що я за ці гроші отримаю.
Звичайно, хочеться заплатити поменше, а отримати більше. Однак необхідно вирішити, що важливіше менше заплатити або більше отримати, і приписати кожному вузлу вагу. Припустимо, що нам важливіше якісне рішення, ніж дешеве, і припишемо вузлу «Вартість» вага 40%, а вузлу «Можливості» – 60%.
У великих корпораціях зазвичай все навпаки – вага вартості не опускається нижче 50%, а може бути й більше ніж 60%. У модельному прикладі важливо лише те, що сумарна вага дочірніх вузлів будь-якого батьківського вузла має бути 100%.
Відсікаючі умови
Сайту відомо близько 500 систем керування базами даних. Звичайно, якщо вибирати цільову платформу з такої кількості варіантів, то може вийти оглядова стаття, але не комерційний проект. Для того, щоб скоротити простір вибору, формулюються критерії, що відсікають, і якщо платформа цим критеріям не задовольняє, то вона не розглядається.
Відсікаючі критерії можуть належати до технологічних особливостей, наприклад:
- ACID-гарантії;
- реляційна модель даних;
- підтримка мови SQL (зверніть увагу, це не те саме, що «реляційна модель»);
- можливість горизонтального масштабування.
Можуть бути критерії загального характеру:
- наявність комерційної підтримки у Росії;
- відкритий вихідний код;
- наявність платформи у Реєстрі Мінкомзв'язку;
- наявність платформи у якомусь рейтингу (наприклад, у першій сотні рейтингу db-engines.com);
- наявність експертів на ринку (наприклад, за результатами пошуку назви платформи у резюме на сайті hh.ru).
Зрештою, можуть бути критерії, специфічні для підприємства:
- наявність спеціалістів у штаті;
- сумісність із системою моніторингу X або із системою резервного копіювання Y, на яку зав'язано весь супровід…
Найголовніше, щоб список критеріїв, що відсікали, був. А якщо ні, то обов'язково знайдеться якийсь експерт (або «експерт»), який користується особливою довірою керівництва, який скаже «та що ж ви не вибрали платформу Z, я знаю, вона краща».
Оцінка вартості
Вартість рішення складається очевидно з вартості ліцензій, вартості супроводу та вартості обладнання.
Якщо системи приблизно одного класу (наприклад, Microsoft SQL Server та PostgreSQL), то для простоти можна вважати, що кількість обладнання для того та іншого рішення буде приблизно однаковою. Це дозволить не оцінювати обладнання, заощадивши тим самим багато часу і сил. Якщо ж доводиться порівнювати різні системи (скажімо, Oracle vs. Redis), то очевидно, що для коректної оцінки необхідно зробити сайзинг (розрахунок кількості обладнання). Сайзинг неіснуючої системи - заняття дуже невдячне, тому такого порівняння все ж таки намагаються не допускати. Зробити це просто: в умовах відсікання пишуться нульова втрата даних і реляційна модель або навпаки - навантаження від 50 тисяч транзакцій в секунду.
Для оцінки ліцензій достатньо запросити у вендора чи його партнерів вартість ліцензії на фіксовану кількість ядер та підтримки на фіксований термін. Як правило, у компаній вже збудовані міцні відносини з вендорами програмного забезпечення, і якщо відділ експлуатації БД не може відповісти на питання про вартість самостійно, то для отримання цієї інформації достатньо одного листа.
У різних вендорів можуть бути різні метрики ліцензування: за кількістю ядер, обсягом даних чи кількістю вузлів. Standby-база може бути безкоштовною, а може ліцензуватись так само, як і основна. Якщо тільки виявились якісь відмінності в метриках, доведеться детально описувати модельний стенд та рахувати вартість ліцензій для стенду.
Важливим моментом для коректного порівняння є однакові умови підтримки. Скажімо, підтримка Oracle коштує 22% вартості ліцензії на рік, а за підтримку PostgreSQL можна не платити. Чи правильно так порівнювати? Ні, тому що помилка, яка не може бути усунена власними силами, зовсім різні наслідки: у першому випадку фахівці підтримки швидко допоможуть її усунути, а в другому є ризик затримки проекту або простою готової системи протягом невизначеного терміну.
Зрівняти умови розрахунку можна трьома способами:
- Використовувати Oracle без підтримки (насправді такого не буває).
- Купити підтримку на PostgreSQL – наприклад, у компанії Postgres Professional.
- Закласти в облік ризики, пов'язані з відсутністю підтримки.
Наприклад, розрахунок ризиків може мати такий вигляд: у разі непереборного збою бази даних простої системи складе 1 робочий день. Запланований прибуток від використання системи – 40 млрд монгольських тугриків на рік, частота аварій оцінюється як 1/400, таким чином ризик відсутності супроводу оцінюється приблизно у 100 млн монгольських тугриків на рік. Вочевидь, що «планований прибуток» і «оцінна частота аварій» – величини віртуальні, але краще мати таку модель, ніж мати.
Насправді система може бути дуже важливою, і репутаційні втрати від тривалого простою виявляться неприпустимими, тому підтримка буде потрібна. Якщо ж простий допускається, то відмова від підтримки може бути непоганим способом заощадити.
Припустимо, що після всіх розрахунків вартість експлуатації платформи A протягом 5 років виявилася 800 млн. монгольських тугриків, вартість експлуатації платформи B - 650 млн. тугриків, а вартість експлуатації платформи C - 600 млн. тугриків. Платформа C як переможець отримує за вартість повноцінний бал, а платформи A і B – трохи менше, пропорційно до того, у скільки разів вони дорожчі. У цьому випадку – 0.75 та 0.92 балів відповідно.
оцінка можливостей
Оцінка можливостей ділиться на безліч груп, кількість яких обмежена лише фантазією того, хто оцінює. Оптимальним варіантом здається розподіл можливостей по командам, які цими можливостями користуватимуться; у нашому прикладі це розробники, адміністратори та офіцери інформаційної безпеки. Припустимо, що ваги цих функцій розподіляються як 40:40:20.
До функцій розробки можна віднести:
- зручність маніпуляції даними;
- масштабування;
- наявність вторинних індексів.
Список критеріїв, як та його ваги, дуже суб'єктивні. Навіть при вирішенні одного і того ж завдання ці списки, ваги пунктів та відповіді істотно відрізнятимуться залежно від складу вашої команди. Так, наприклад, Facebook для зберігання даних використовує MySQL, а Instagram побудовано на базі Cassandra. Навряд розробники цих додатків заповнювали такі таблиці. Можна лише здогадуватися, що Марк Цукерберг вибрав повноцінну реляційну модель, заплативши за це необхідністю прикладного шардування, тоді як Кевін Сістром заклав масштабування засобами платформи, пожертвувавши зручністю доступу до даних.
До функцій адміністрування належать:
- можливості системи резервного копіювання;
- зручність моніторингу;
- зручність управління потужностями – дисками та вузлами;
- можливості реплікації даних.
Зауважте, що формулювання питань повинні допускати кількісну оцінку. Можна навіть домовитись, як оцінювати ту чи іншу функцію. Давайте, наприклад, спробуємо поставити оцінки інструментам резервного копіювання на прикладі інструментів, які постачаються з СУБД Oracle:
Інструмент
Коментар
Оцінка
imp/exp
Вивантаження та завантаження даних
0.1
begin/end backup
Копіювання файлів
0.3
РМАН
Можливість інкрементального копіювання
0.7
ZDLRA
Тільки інкрементальне копіювання, якнайшвидше відновлення на точку
1.0
Якщо чіткі критерії оцінки відсутні, є сенс попросити кількох експертів виставити оцінки, а потім їх усереднити.
Нарешті просто перерахуємо функції інформаційної безпеки:
- наявність політик керування паролями;
- можливість підключення зовнішніх засобів аутентифікації (LDAP, Kerberos);
- рольова модель доступу;
- можливості аудиту;
- шифрування даних на диску;
- шифрування під час передачі через мережу (TLS);
- захист даних від адміністратора.
Тестування роботи
Окремо хотілося б застерегти від використання як аргументи результатів будь-яких навантажувальних тестів, зроблених не вами.
По-перше, структура даних і профіль навантаження додатків, що тестуються, можуть істотно відрізнятися від того завдання, яке збираєтеся вирішувати ви. Років 10-15 тому виробники баз даних любили хизуватися результатами, досягнутими в тестах TPC, але зараз уже, здається, ніхто не сприймає ці результати всерйоз.
По-друге, продуктивність системи досить сильно залежить від того, під яку платформу спочатку написано код і на якому устаткуванні проводився тест. Мені доводилося бачити багато тестів, де Oracle порівнювали з PostgreSQL. Результати – від беззаперечної переваги однієї системи до так само беззаперечної переваги іншої.
І, нарешті, по-третє, ви нічого не знаєте про те, хто проводив тест. Важлива як кваліфікація, що впливає якість налаштування ОС і платформи, і мотивація, що впливає результати тесту сильніше, ніж інші чинники разом узяті.
Якщо продуктивність є критично важливим фактором, проведіть тест самостійно, бажано за участю фахівців, які налаштовуватимуть та підтримуватимуть промислову систему.
Результат
Нарешті, результатом усієї виконаної роботи має стати електронна таблиця, де всі оцінки зведені, перемножені та підсумовані:
Як ви розумієте, зміною ваг і коригуванням оцінок можна досягти будь-якого необхідного результату, але це вже зовсім інша історія.
Джерело: habr.com