„Ovo je neophodno“, rekla je glasno, ne obraćajući se nikome. - Ovo je neophodno! Upravo to kaže: glavni zadatak kompanije je ostvarivanje profita u interesu dioničara. Pa, razmisli o tome! Oni se ničega ne boje!
Julij Dubov, “Manje zlo”
Vidjevši takav naslov, vjerovatno ste već odlučili da je članak ili glupost ili provokacija. Ali nemojte žuriti sa zaključcima: zaposlenici velikih korporacija, posebno korporacija s državnim učešćem, često moraju uspoređivati različite platforme, uključujući potpuno različite - na primjer, one u naslovu.
Naravno, niko ne poredi DBMS na ovaj način, jer su njihove prednosti i mane dobro poznate. Po pravilu, platforme koje rješavaju neki aplikativni problem podliježu usporedbi. U članku ću pokazati metodologiju koja se koristi u ovom slučaju, koristeći primjer baza podataka kao predmeta koji je čitateljima Habra poznat iz prve ruke. dakle,
Motivacija
Kada započnete obrazovni ili hobi projekat, motivacija za odabir platforme može biti veoma raznolika: „ovo je platforma koju najbolje poznajem“, „zainteresovan sam da razumem ovu“, „evo najbolje dokumentacije“ ... U slučaju komercijalnog preduzeća, kriterijum izbora je isti: koliko ću morati da platim i šta ću dobiti za ovaj novac.
Naravno, želite da platite manje, a dobijete više. Međutim, morate odlučiti šta je važnije - platiti manje ili dobiti više, i dodijeliti težinu svakom čvoru. Pretpostavimo da nam je kvalitetno rješenje važnije od jeftinog, a čvoru “Cost” dodjeljujemo težinu od 40%, a čvoru “Mogućnosti” 60%.
U velikim korporacijama obično je suprotno – težina troškova ne pada ispod 50%, a možda i više od 60%. U primjeru modela, sve što je važno je da ukupna težina podređenih čvorova bilo kojeg roditeljskog čvora mora biti 100%.
Uslovi rezanja
Website Poznato je oko 500 sistema za upravljanje bazama podataka. Naravno, ako odaberete ciljnu platformu među toliko opcija, možete završiti s preglednim člankom, ali ne i komercijalnim projektom. Kako bi se smanjio prostor izbora, formulišu se granični kriterijumi, a ako platforma ne zadovoljava ove kriterijume, onda se ne razmatra.
Kriterijumi ograničenja mogu se odnositi na tehnološke karakteristike, na primjer:
- ACID garancije;
- relacijski model podataka;
- Podrška za SQL jezik (napomena, ovo nije isto što i “relacijski model”);
- mogućnost horizontalnog skaliranja.
Mogu postojati opšti kriterijumi:
- dostupnost komercijalne podrške u Rusiji;
- open source;
- dostupnost platforme u Registru Ministarstva telekomunikacija i masovnih komunikacija;
- prisutnost platforme u nekoj ocjeni (na primjer, u prvih sto ranga db-engines.com);
- prisutnost stručnjaka na tržištu (na primjer, na osnovu rezultata pretraživanja naziva platforme u životopisu na web stranici hh.ru).
Na kraju krajeva, mogu postojati kriterijumi specifični za preduzeće:
- dostupnost stručnjaka u osoblju;
- kompatibilnost sa nadzornim sistemom X ili backup sistemom Y, na kojem se zasniva sva podrška...
Najvažnije je da postoji lista graničnih kriterijuma. Inače će se sigurno naći neki stručnjak (ili „stručnjak“) koji uživa posebno povjerenje menadžmenta koji će reći „zašto nisi izabrao platformu Z, znam da je najbolja“.
Procjena troškova
Trošak rješenja očito se sastoji od cijene licenci, cijene podrške i cijene opreme.
Ako su sistemi približno iste klase (na primjer, Microsoft SQL Server i PostgreSQL), onda zbog jednostavnosti možemo pretpostaviti da će količina opreme za oba rješenja biti približno ista. To će vam omogućiti da ne procjenjujete opremu, čime ćete uštedjeti mnogo vremena i truda. Ako treba da uporedite potpuno različite sisteme (recimo, Oracle vs. Redis), onda je očigledno da je za ispravnu procenu potrebno uraditi dimenzionisanje (proračun količine opreme). Dimenzioniranje nepostojećeg sistema je vrlo nezahvalan zadatak, pa se i dalje trude izbjeći takva poređenja. To je lako učiniti: u graničnim uslovima upisuje se nulti gubitak podataka i relacioni model, ili obrnuto - opterećenje od 50 hiljada transakcija u sekundi.
Za procjenu licenci, dovoljno je pitati dobavljača ili njegove partnere za cijenu licence za fiksni broj jezgara i podršku za fiksni period. Po pravilu, kompanije već imaju čvrste odnose sa dobavljačima softvera, a ako odjel za upravljanje bazama podataka ne može sam odgovoriti na pitanje o troškovima, onda je jedno slovo dovoljno za dobivanje ove informacije.
Različiti proizvođači mogu imati različite metrike licenciranja: prema broju jezgara, volumenu podataka ili broju čvorova. Standby baza može biti besplatna, ili može biti licencirana na isti način kao i glavna. Ako se otkriju bilo kakve razlike u metrikama, morat ćete detaljno opisati štand modela i izračunati cijenu licenci za štand.
Važna tačka za ispravno poređenje su isti uslovi podrške. Na primjer, Oracle podrška košta 22% cijene licence godišnje, ali ne morate platiti podršku za PostgreSQL. Da li je ispravno ovako porediti? Ne, jer greška koju ne možete sami ispraviti ima potpuno drugačije posljedice: u prvom slučaju stručnjaci za podršku će vam brzo pomoći da je popravite, ali u drugom slučaju postoji rizik od odgode projekta ili zastoja gotovog sistema na neodređeno vreme.
Uslove izračunavanja možete izjednačiti na tri načina:
- Koristite Oracle bez podrške (u stvarnosti se to ne dešava).
- Kupite podršku za PostgreSQL - na primjer, od Postgres Professionala.
- Uzmite u obzir rizike povezane s nedostatkom podrške.
Na primjer, izračun rizika može izgledati ovako: u slučaju fatalnog kvara baze podataka, zastoj sistema bi bio 1 radni dan. Predviđena dobit od korišćenja sistema je 40 milijardi MNT godišnje, stopa nezgoda je procenjena na 1/400, tako da se rizik od nedostatka podrške procenjuje na oko 100 miliona MNT godišnje. Očigledno, „planirani profit“ i „procijenjena učestalost nesreća“ su virtuelne vrijednosti, ali mnogo je bolje imati takav model nego ga ne imati.
U stvarnosti, sistem može biti previše važan da bi reputacijski trošak dugotrajnog zastoja bio neprihvatljiv, pa će biti potrebna podrška. Ako se dopusti prekid rada, onda odbijanje podrške ponekad može biti dobar način za uštedu novca.
Pretpostavimo da nakon svih kalkulacija, trošak operativne platforme A za 5 godina ispada 800 miliona MNT, trošak operativne platforme B je 650 miliona MNT, a trošak operativne platforme C je 600 miliona MNT. Platforma C, kao pobednik, dobija pun bod za cenu, dok platforme A i B dobijaju nešto manje, srazmerno tome koliko su puta skuplje. U ovom slučaju – 0.75 i 0.92 poena, respektivno.
Opportunity Assessment
Procjena mogućnosti podijeljena je u više grupa, čiji je broj ograničen samo maštom osobe koja procjenjuje. Čini se da je optimalna opcija da se sposobnosti podijele u timove koji će koristiti ove sposobnosti; u našem primjeru, to su programeri, administratori i službenici za sigurnost informacija. Pretpostavimo da su težine ovih funkcija raspoređene kao 40:40:20.
Razvojne funkcije uključuju:
- lakoća manipulacije podacima;
- skaliranje;
- prisustvo sekundarnih indeksa.
Lista kriterijuma, kao i njihova težina, veoma su subjektivni. Čak i kada rješavate isti problem, ove liste, težine stavki i odgovori značajno će se razlikovati ovisno o sastavu vašeg tima. Na primjer, Facebook koristi MySQL za pohranu podataka, a Instagram je izgrađen na Cassandri. Malo je vjerovatno da su programeri ovih aplikacija ispunili takve tabele. Može se samo nagađati da je Mark Zuckerberg odabrao punopravni relacijski model, plativši to potrebom za primijenjenim šardiranjem, dok je Kevin Systrom izgradio skaliranje koristeći platformu, žrtvujući lakoću pristupa podacima.
Administrativne funkcije uključuju:
- mogućnosti rezervnog sistema;
- lakoća praćenja;
- jednostavnost upravljanja kapacitetom - diskovi i čvorovi;
- mogućnosti replikacije podataka.
Imajte na umu da pitanja moraju biti formulisana na kvantitativan način. Možete se čak dogovoriti o tome kako procijeniti određenu funkciju. Pokušajmo, na primjer, ocijeniti alate za izradu sigurnosnih kopija koristeći primjer alata koji se isporučuju s Oracle DBMS:
Alat
komentar
procjena
imp/exp
Učitavanje i učitavanje podataka
0.1
početak/završetak sigurnosne kopije
Kopiranje fajlova
0.3
RMAN
Mogućnost inkrementalnog kopiranja
0.7
ZDLRA
Samo inkrementalno kopiranje, najbrži oporavak do tačke
1.0
Ako ne postoje jasni kriterijumi za ocjenjivanje, ima smisla zamoliti nekoliko stručnjaka da daju ocjene, a zatim ih u prosjeku.
Na kraju, jednostavno navodimo funkcije sigurnosti informacija:
- dostupnost politika upravljanja lozinkama;
- mogućnost povezivanja eksternih alata za autentifikaciju (LDAP, Kerberos);
- uzor pristupa;
- sposobnosti revizije;
- šifriranje podataka na disku;
- enkripcija tokom prenosa preko mreže (TLS);
- zaštita podataka od administratora.
Testiranje performansi
Zasebno, želio bih upozoriti da ne koristite rezultate bilo kakvih testova opterećenja koje niste napravili kao argumente.
Prvo, struktura podataka i profil opterećenja aplikacija koje se testiraju mogu se značajno razlikovati od problema koji ćete riješiti. Prije otprilike 10-15 godina, prodavci baza podataka su voljeli da se razmeću rezultatima postignutim na TPC testovima, ali sada, čini se, ove rezultate niko ne shvata ozbiljno.
Drugo, performanse sistema dosta zavise od toga za koju platformu je kod prvobitno napisan i na kojoj opremi je test sproveden. Video sam mnoge testove u kojima je Oracle upoređivan sa PostgreSQL-om. Rezultati se kreću od bezuslovne superiornosti jednog sistema do jednako bezuslovne superiornosti drugog.
I na kraju, treće, ne znate ništa o tome ko je radio test. Obje kvalifikacije su važne, utiču na kvalitet postavljanja OS-a i platforme, kao i na motivaciju koja utiče na rezultate testa više od svih ostalih faktora zajedno.
Ako su performanse kritičan faktor, izvršite test sami, po mogućnosti uz pomoć ljudi koji će konfigurirati i održavati proizvodni sistem.
rezultat
Konačno, rezultat svega obavljenog posla trebao bi biti tabela u kojoj se sve procjene kombinuju, množe i sumiraju:
Kao što razumijete, promjenom skale i prilagođavanjem ocjena možete postići bilo koji željeni rezultat, ali to je sasvim druga priča...
izvor: www.habr.com