"Ovo je neophodno", rekla je glasno, ne obraćajući se nikome. - Ovo je neophodno! Upravo to kaže: glavni zadatak poduzeća je ostvarivanje dobiti u interesu dioničara. Pa, razmislite o tome! Oni se ničega ne boje!
Yuliy Dubov, “Manje zlo”
Vidjevši takav naslov, vjerojatno ste već zaključili da je članak ili glupost ili provokacija. Ali nemojte žuriti sa zaključcima: zaposlenici velikih korporacija, posebno korporacija s državnim sudjelovanjem, često moraju uspoređivati različite platforme, uključujući potpuno različite - na primjer, one u naslovu.
Naravno, nitko ne uspoređuje DBMS na ovaj način, jer su njihove snage i slabosti dobro poznate. Usporedbi u pravilu podliježu platforme koje rješavaju neki aplikacijski problem. U članku ću prikazati metodologiju koja se u ovom slučaju koristi na primjeru baza podataka kao teme koja je čitateljima Habra poznata iz prve ruke. Tako,
Motivacija
Kada započnete obrazovni projekt ili projekt iz hobija, motivacija za odabir platforme može biti vrlo raznolika: „ovo je platforma koju najbolje poznajem“, „Zanima me da razumijem ovu“, „ovdje je najbolja dokumentacija“ ... U slučaju trgovačkog društva, kriterij odabira je isti: koliko ću morati platiti i što ću dobiti za taj novac.
Naravno, želite platiti manje, a dobiti više. Međutim, morate odlučiti što 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 i dodijelimo težinu od 40% čvoru „Cost“, a 60% čvoru „Mogućnosti“.
U velikim korporacijama obično je suprotno – troškovna težina 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 čvorova djeteta bilo kojeg čvora roditelja mora biti 100%.
Uvjeti rezanja
Web stranica Poznato je oko 500 sustava za upravljanje bazama podataka. Naravno, ako odaberete ciljanu platformu među toliko opcija, možete završiti s preglednim člankom, ali ne i komercijalnim projektom. Kako bi se smanjio prostor izbora, formuliraju se granični kriteriji, a ako platforma ne zadovoljava te kriterije, onda se ne razmatra.
Granični kriteriji mogu se odnositi na tehnološke značajke, na primjer:
- ACID jamstva;
- relacijski podatkovni model;
- Podrška za SQL jezik (napomena, ovo nije isto što i "relacijski model");
- mogućnost horizontalnog skaliranja.
Mogu postojati opći kriteriji:
- dostupnost komercijalne podrške u Rusiji;
- otvoreni izvor;
- dostupnost platforme u Upisniku Ministarstva telekomunikacija i masovnih komunikacija;
- prisutnost platforme u nekoj ocjeni (na primjer, u prvih stotinu ocjene db-engines.com);
- prisutnost stručnjaka na tržištu (na primjer, na temelju rezultata pretraživanja naziva platforme u životopisu na web stranici hh.ru).
Uostalom, mogu postojati kriteriji specifični za poduzeće:
- dostupnost stručnjaka u osoblju;
- kompatibilnost sa sustavom nadzora X ili backup sustavom Y, na kojem se temelji sva podrška...
Najvažnije je da postoji popis graničnih kriterija. 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 odabrao platformu Z, ja znam da je najbolja”.
Procjena troškova
Trošak rješenja očito se sastoji od troška licenci, troška podrške i troška opreme.
Ako su sustavi približno iste klase (npr. Microsoft SQL Server i PostgreSQL), tada radi 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 puno vremena i truda. Ako morate uspoređivati potpuno različite sustave (recimo Oracle vs. Redis), onda je očito da je za ispravnu procjenu potrebno napraviti dimenzioniranje (izračun količine opreme). Dimenzioniranje nepostojećeg sustava vrlo je nezahvalan posao, pa se takve usporedbe ipak trude izbjeći. To je lako učiniti: u graničnim uvjetima piše se nulti gubitak podataka i relacijski model ili obrnuto - opterećenje od 50 tisuća transakcija u sekundi.
Za procjenu licenci dovoljno je od dobavljača ili njegovih partnera zatražiti cijenu licence za fiksni broj jezgri i podršku za fiksno razdoblje. U pravilu, tvrtke već imaju čvrste odnose s dobavljačima softvera, a ako odjel za operacije baze podataka ne može sam odgovoriti na pitanje troškova, tada je dovoljno jedno slovo da se dobije ta informacija.
Različiti dobavljači mogu imati različite metrike licenciranja: prema broju jezgri, količini podataka ili broju čvorova. Standby baza može biti besplatna ili se može licencirati na isti način kao i glavna. Ako se otkriju bilo kakve razlike u metrici, morat ćete detaljno opisati postolje modela i izračunati troškove licenci za postolje.
Važna točka za ispravnu usporedbu su isti uvjeti podrške. Na primjer, podrška za Oracle košta 22% cijene licence godišnje, ali ne morate platiti podršku za PostgreSQL. Je li ispravno ovako uspoređivati? Ne, jer pogreška koju ne možete sami popraviti ima potpuno drugačije posljedice: u prvom slučaju stručnjaci za podršku brzo će vam pomoći da je popravite, ali u drugom slučaju postoji rizik od kašnjenja projekta ili zastoja gotovog sustav na neodređeno vrijeme.
Uvjete izračuna možete izjednačiti na tri načina:
- Koristite Oracle bez podrške (u stvarnosti se to ne događa).
- Kupite podršku za PostgreSQL - na primjer, od Postgres Professional.
- 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, prekid rada sustava bio bi 1 radni dan. Predviđena dobit od korištenja sustava je 40 milijardi MNT godišnje, stopa nesreća se procjenjuje na 1/400, stoga se rizik nedostatka podrške procjenjuje na približno 100 milijuna MNT godišnje. Očito, "planirana dobit" i "procijenjena učestalost nesreća" su virtualne vrijednosti, ali puno je bolje imati takav model nego ga nemati.
U stvarnosti, sustav može biti previše važan da bi reputacijski trošak dugotrajnog zastoja bio neprihvatljiv, pa će biti potrebna podrška. Ako je zastoj dopušten, odbijanje podrške ponekad može biti dobar način za uštedu novca.
Pretpostavimo da nakon svih izračuna trošak rada platforme A za 5 godina iznosi 800 milijuna MNT, trošak rada platforme B iznosi 650 milijuna MNT, a trošak rada platforme C iznosi 600 milijuna MNT. Platforma C kao pobjednička dobiva pun bod za cijenu, dok platforme A i B dobivaju nešto manje, proporcionalno tome koliko su puta skuplje. U ovom slučaju – 0.75 odnosno 0.92 boda.
Procjena mogućnosti
Procjena prilika podijeljena je u mnogo skupina, čiji je broj ograničen samo maštom onog tko procjenjuje. Čini se da je optimalna opcija podijeliti sposobnosti u timove koji će te sposobnosti koristiti; u našem primjeru to su programeri, administratori i službenici za informacijsku sigurnost. Pretpostavimo da su težine ovih funkcija raspoređene kao 40:40:20.
Razvojne funkcije uključuju:
- jednostavnost manipulacije podacima;
- skaliranje;
- prisutnost sekundarnih indeksa.
Popis kriterija, kao i njihova težina, vrlo su subjektivni. Čak i kada rješavate isti problem, ti će se popisi, težine stavki i odgovori značajno razlikovati ovisno o sastavu vašeg tima. Na primjer, Facebook koristi MySQL za pohranu podataka, a Instagram je izgrađen na Cassandri. Malo je vjerojatno da su programeri ovih aplikacija ispunili takve tablice. Može se samo nagađati da je Mark Zuckerberg odabrao potpuni relacijski model, plativši ga potrebom za primijenjenim dijeljenjem, dok je Kevin Systrom izgradio skaliranje pomoću platforme, žrtvujući jednostavnost pristupa podacima.
Funkcije administracije uključuju:
- mogućnosti sigurnosnog sustava;
- jednostavnost praćenja;
- jednostavnost upravljanja kapacitetom - diskovi i čvorovi;
- mogućnosti replikacije podataka.
Imajte na umu da pitanja moraju biti formulirana na kvantitativni način. Možete se čak dogovoriti kako će se ocijeniti određena funkcija. Pokušajmo, na primjer, ocijeniti alate za sigurnosno kopiranje koristeći primjer alata isporučenih s Oracle DBMS-om:
Oruđe
Komentirati
Procjena
imp/exp
Prijenos i učitavanje podataka
0.1
početak/kraj sigurnosnog kopiranja
Kopiranje datoteka
0.3
RMAN
Mogućnost inkrementalnog kopiranja
0.7
ZDLRA
Samo inkrementalno kopiranje, najbrži oporavak do točke
1.0
Ako nema jasnih kriterija ocjenjivanja, ima smisla zamoliti nekoliko stručnjaka da daju ocjene, a zatim ih prosječno ocijeniti.
Na kraju, jednostavno navodimo funkcije informacijske sigurnosti:
- dostupnost politika upravljanja lozinkama;
- mogućnost povezivanja vanjskih alata za provjeru autentičnosti (LDAP, Kerberos);
- uzor pristupa;
- revizijske sposobnosti;
- šifriranje podataka na disku;
- šifriranje tijekom prijenosa preko mreže (TLS);
- zaštita podataka od strane administratora.
Testiranje performansi
Zasebno bih želio upozoriti na korištenje rezultata 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 10-15 godina prodavači baza podataka voljeli su se razmetati rezultatima postignutim u TPC testovima, ali sada, čini se, nitko te rezultate ne shvaća ozbiljno.
Drugo, performanse sustava uvelike ovise o tome za koju je platformu kod izvorno napisan i na kojoj je opremi test proveden. Vidio sam mnoge testove u kojima je Oracle uspoređivan s PostgreSQL-om. Rezultati se kreću od bezuvjetne superiornosti jednog sustava do jednako bezuvjetne superiornosti drugog.
I na kraju, treće, ne znate ništa o tome tko je radio test. Važne su obje kvalifikacije koje utječu na kvalitetu postavljanja OS-a i platforme, kao i motivacija koja utječe na rezultate testiranja više od svih ostalih faktora zajedno.
Ako je izvedba kritični čimbenik, provedite test sami, po mogućnosti uz pomoć ljudi koji će konfigurirati i održavati proizvodni sustav.
Rezultirati
Konačno, rezultat cjelokupnog obavljenog rada trebala bi biti proračunska tablica u kojoj se sve procjene kombiniraju, množe i zbrajaju:
Kao što razumijete, promjenom ljestvice i podešavanjem ocjena možete postići bilo koji željeni rezultat, ali to je sasvim druga priča...
Izvor: www.habr.com