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