– Невероятно, – сказала она громко, не обращаясь к никому. – Невероятно! Прямо написано – главната задача на обществото е да печели в интерес на акционерите. Помислете си! Никакви страхове!
Юлий Дубов, «По-малкото зло»
След като видите такова заглавие, вероятно вече сте решили, че статията е или глупост, или провокация. Но не бързайте с изводите: служителите на големите корпорации, особено тези с държавно участие, доста често трябва да сравняват различни платформи, включително съвсем различни – например, както е посочено в заглавието.
Разбира се, никой не сравнява СУБД, тъй като техните силни и слаби страни са добре известни. Как правило, сравнението подлежи на платформите, решаващи даден приложен проблем. В статията ще покажа методологията, която се използва, на примера на базите данни, добре познати на читателите на Хабра. И така,
Мотивация
Когато започнете учебен проект или хоби проект, мотивацията за избор на платформа може да бъде разнообразна: «тази платформа я знам най-добре», «интересно ми е да разбера тази», «тук е най-добрата документация»... В случая с търговска компания критерият за избор е един: колко ще трябва да платя и какво ще получа за тези пари.
Естествено, искате да платите по-малко, а да получите повече. Въпреки това, трябва да решите, което е по-важно – да платите по-малко или да получите повече, и да зададете тегло на всеки възел. Нека предположим, че качественото решение е по-важно от евтиното и задаваме на възела «Цена» тегло 40%, а на възела «Възможности» – 60%.
В големите корпорации обикновено е точно обратното – теглото за цена не пада под 50%, а може би дори над 60%. В моделирания пример е важно само това, че общото тегло на дочерните възли на който и да е родителски възел трябва да бъде 100%.
Изключващи условия
Сайтът знае около 500 системи за управление на бази данни. Естествено, ако избирате целева платформа от такова количество опции, статията може да се окаже обзорна, но не и търговски проект. За да се стесни пространството за избор, се формулират изключващи критерии, и ако платформата не отговаря на тези критерии, то тя не се разглежда.
Отсеиращите критерии могат да се отнасят до технологични характеристики, например:
- ACID гаранции;
- релационен модел на данни;
- поддръжка на SQL (обърнете внимание, че това не е същото като „релационен модел“);
- възможност за хоризонтално мащабиране.
Могат да бъдат критерии от общо естество:
- наличие на търговска поддръжка в България;
- отворен код;
- наличие на платформата в Регистъра на Министерството на транспорта;
- наличие на платформата в някаква класация (например, в първата стотица на класацията db-engines.com);
- наличие на експерти на пазара (например, по резултатите от търсенето на името на платформата в резюмета на сайта hh.ru).
В крайна сметка, могат да бъдат критерии, специфични за предприятието:
- наличие на специалисти в екипа;
- совместимост с мониторингова система X или с резервна система Y, на която е базирано всичкото обслужване…
Най-важното е, че списъкът с отсеиращи критерии съществува. В противен случай непременно ще се намери някой експерт (или 'експерт'), който се ползва с особено доверие от ръководството, и ще каже 'а какво за платформата Z, знам, че тя е най-добра'.
Оценка на цената
Цената на решението явно се определя от цената на лицензите, цената на поддръжката и цената на оборудването.
Ако системите са от приблизително един и същ клас (например, Microsoft SQL Server и PostgreSQL), то за опростяване може да се счита, че количеството оборудване за двете решения ще бъде приблизително същото. Това ще спести време и усилия в оценката на оборудването. Ако обаче трябва да се сравняват съвсем различни системи (например, Oracle срещу 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
начало/край на резервно копиране
Копиране на файлове
0.3
RMAN
Възможност за инкрементално копиране
0.7
ZDLRA
Само инкрементално копиране, по-бързо възстановяване до точка
1.0
Ако ясни критерии за оценка липсват, има смисъл да помолите няколко експерти да дадат оценки, а след това да ги средите.
Накрая, просто ще изброим функциите на информационната сигурност:
- наличие на политики за управление на паролите;
- възможност за свързване на външни средства за автентикация (LDAP, Kerberos);
- роли за достъп;
- възможности за одит;
- шифроване на данни на диска;
- шифроване при предаване по мрежата (TLS);
- защита на данните от администратора.
Тестване на производителността
Поотделно бих искал да предупредя да не използвате като аргументи резултати от някакви натоварващи тестове, направени не от вас.
На първо място, структурата на данните и профилът на натоварване на тестваните приложения могат да се различават значително от тази задача, която предстоящо да решите. Преди 10-15 години производителите на бази данни обичаха да се хвалят с резултатите, постигнати в тестовете TPC, но сега вече, изглежда, никой не възприема тези резултати сериозно.
На второ място, производителността на системата зависи в значителна степен от платформата, за която е написан кодът, и на какво оборудване е проведен тестът. Бях свидетел на множество тестове, в които Oracle се сравняваше с PostgreSQL. Резултатите варират - от безусловното надмощие на едната система до също толкова безусловното надмощие на другата.
И накрая, на трето място, не знаете нищо за това, кой е провел теста. Важна е както квалификацията, която влияе на качеството на настройката на ОС и платформата, така и мотивацията, която влияе на резултатите от теста по-силно от всички останали фактори заедно.
Ако производителността е критично важен фактор, проведете тест сами, за предпочитане с участието на специалисти, които ще настройват и поддържат промишлената система.
Резултат
Накрая, резултатът от всички усилия трябва да бъде електронна таблица, в която всички оценки са обобщени, умножени и сумирани:
Както разбирате, чрез промяна на тежестите и коригиране на оценките може да се постигне всеки необходим резултат, но това вече е съвсем друга история…
Източник: habr.com
