„Ова е неопходно“, рече таа гласно, не обраќајќи се никому. - Ова е неопходно! Токму тоа го вели: главната задача на една компанија е да оствари профит во интерес на акционерите. Па, размислете за тоа! Не се плашат од ништо!
Јулиј Дубов, „Помало зло“
Откако видовте ваков наслов, веројатно веќе сте решиле дека статијата е или глупост или провокација. Но, не брзајте со заклучоците: вработените во големите корпорации, особено корпорациите со државно учество, доста често треба да споредуваат различни платформи, вклучително и сосема различни - на пример, оние во насловот.
Се разбира, никој не ги споредува DBMS-овите на овој начин, бидејќи нивните силни и слаби страни се добро познати. Како по правило, платформите кои решаваат одреден проблем со апликацијата се предмет на споредба. Во написот ќе ја покажам методологијата што се користи во овој случај, користејќи го примерот на базите на податоци како тема што им е позната на читателите на Habr од прва рака. Значи,
Мотивација
Кога започнувате образовен проект или проект за хоби, мотивацијата за избор на платформа може да биде многу разновидна: „ова е платформата што ја знам најдобро“, „Јас сум заинтересиран да ја разберам оваа“, „еве ја најдобрата документација“ ... Во случај на комерцијална компанија, критериумот за избор е ист: колку ќе треба да платам и што ќе добијам за овие пари.
Нормално, сакате да платите помалку и да добивате повеќе. Сепак, треба да одлучите што е поважно - да плаќате помалку или да добивате повеќе и да доделите тежина на секој јазол. Да претпоставиме дека висококвалитетното решение ни е поважно од евтиното, и доделуваме тежина од 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 годишно. Очигледно, „планираниот профит“ и „проценетата фреквенција на несреќи“ се виртуелни вредности, но многу е подобро да се има таков модел отколку да се нема.
Во реалноста, системот може да биде премногу важен за репутациските трошоци за долгорочни прекини да бидат неприфатливи, па затоа ќе биде потребна поддршка. Ако е дозволено застој, тогаш одбивањето поддршка понекогаш може да биде добар начин да заштедите пари.
Да претпоставиме дека по сите пресметки, цената на оперативната платформа А за 5 години излегува 800 милиони МНТ, цената на оперативната платформа Б е 650 милиони МНТ, а цената на оперативната платформа Ц е 600 милиони МНТ. Платформата Ц како победник добива целосен поен за цената, додека платформите А и Б добиваат нешто помалку, пропорционално на тоа колку пати се поскапи. Во овој случај – 0.75 и 0.92 поени, соодветно.
Проценка на можности
Проценката на можностите е поделена на многу групи, чиј број е ограничен само од имагинацијата на лицето кое ја врши проценката. Се чини дека оптималната опција е да се поделат способностите во тимови кои ќе ги користат овие способности; во нашиот пример, тоа се програмери, администратори и службеници за безбедност на информации. Да претпоставиме дека тежините на овие функции се распределени како 40:40:20.
Развојните функции вклучуваат:
- леснотија на манипулација со податоци;
- скалирање;
- присуство на секундарни индекси.
Списокот на критериуми, како и нивната тежина, се многу субјективни. Дури и кога го решавате истиот проблем, овие списоци, тежини на ставки и одговори значително ќе се разликуваат во зависност од составот на вашиот тим. На пример, Facebook користи MySQL за складирање податоци, а Instagram е изграден на Касандра. Малку е веројатно дека развивачите на овие апликации пополниле такви табели. Може само да се погоди дека Марк Цукерберг избра полноправен релациски модел, плаќајќи за тоа со потребата за применето сердинг, додека Кевин Систром изгради скалирање користејќи ја платформата, жртвувајќи го леснотијата на пристап до податоците.
Административните функции вклучуваат:
- способности на резервниот систем;
- леснотија на следење;
- леснотија на управување со капацитет - дискови и јазли;
- способности за репликација на податоци.
Ве молиме имајте предвид дека прашањата мора да бидат формулирани на квантитативен начин. Можете дури и да се договорите како да оцените одредена функција. Ајде, на пример, да се обидеме да ги оцениме алатките за резервна копија користејќи го примерот на алатките обезбедени со Oracle DBMS:
Алатка
Коментар
Евалуација
imp/exp
Поставување и вчитување податоци
0.1
започне/заврши резервна копија
Копирање датотеки
0.3
RMAN
Способност за инкрементално копирање
0.7
ЗДЛРА
Само постепено копирање, најбрзо обновување до точка
1.0
Ако не постојат јасни критериуми за оценување, има смисла да се замолат неколку експерти да дадат оценки и потоа да ги просечат.
Конечно, ние едноставно ги наведуваме функциите за безбедност на информациите:
- достапност на политики за управување со лозинка;
- можност за поврзување на надворешни алатки за автентикација (LDAP, Kerberos);
- модел на пристап;
- способности за ревизија;
- шифрирање на податоци на дискот;
- шифрирање при пренос преку мрежа (TLS);
- заштита на податоците од администраторот.
Тестирање на перформанси
Одделно, би сакал да предупредам да не ги користите резултатите од какви било тестови за оптоварување што не беа направени од вас како аргументи.
Прво, структурата на податоците и профилот на оптоварување на апликациите што се тестираат може значително да се разликуваат од проблемот што ќе го решите. Пред околу 10-15 години, продавачите на бази на податоци сакаа да ги истакнуваат резултатите постигнати во TPC тестовите, но сега, се чини, никој не ги сфаќа овие резултати сериозно.
Второ, перформансите на системот доста силно зависат од тоа за која платформа првично е напишан кодот и од која опрема е извршен тестот. Сум видел многу тестови каде Oracle бил споредуван со PostgreSQL. Резултатите се движат од безусловна супериорност на еден систем до подеднакво безусловна супериорност на друг.
И за крај, трето, не знаеш ништо за тоа кој го направил тестот. И двете квалификации се важни, кои влијаат на квалитетот на поставувањето на ОС и платформата, како и на мотивацијата, што влијае на резултатите од тестот повеќе од сите други фактори заедно.
Ако перформансите се критичен фактор, спроведете го тестот сами, по можност со помош на луѓето кои ќе го конфигурираат и одржуваат производниот систем.
Резултира
Конечно, резултатот од целата завршена работа треба да биде табела каде што сите проценки се комбинираат, множат и сумираат:
Како што разбирате, со менување на вагата и прилагодување на рејтингот можете да го постигнете посакуваниот резултат, но тоа е сосема друга приказна...
Извор: www.habr.com