– Ez hihetetlen, – mondta hangosan, senkihez sem fordulva. – Ez hihetetlen! Így van leírva: a társadalom fő feladata a részvényesek érdekében profitot termelni. Gondoljatok csak bele! Semmitől sem félnek!
Julij Dubov, "A kisebbik rossz"
Ha ilyen címet láttatok, valószínűleg már eldöntöttétek, hogy a cikk – vagy butaság, vagy provokáció. De ne siessetek a következtetésekkel: a nagyvállalatok, különösen az állami részvétellel működő cégek alkalmazottainak gyakran kell összehasonlítaniuk különböző platformokat, akár teljesen eltérőket is – például azokat, amik a címben szerepelnek.
Persze, az adatbázis-kezelő rendszereket senki sem hasonlítja össze, mivel erősségeik és gyengeségeik jól ismertek. Általában a platformok összehasonlításra kerülnek, amelyek valamilyen alkalmazási feladatot oldanak meg. A cikkben bemutatom a módszertant, ami közben alkalmazva van, az adatbázisok példáján, ami a Habr olvasói számára nem ismeretlen. Szóval,
Motiváció
Amikor oktatási projektet vagy hobbi projektet indítotok, a platformválasztás motivációja a legkülönbözőbb lehet: "ezt a platformot ismerem a legjobban", "ez érdekes, ezzel szeretnék foglalkozni", "itt a legjobb a dokumentáció"... Kereskedelmi cég esetén egyetlen kritérium van: mennyit kell fizetni és mit kapok ezért a pénzért.
Természetesen kevesebbet szeretnénk fizetni, és többet kapni. Azonban meg kell határozni, mi a fontosabb – kevesebb fizetni vagy többet kapni, és minden egyes szempontnak súlyt kell adni. Tegyük fel, hogy a minőségi megoldás fontosabb számunkra, mint a költség, így „Költség” szempontnak 40%-os súlyt, és a „Lehetőségek” szempontnak 60%-os súlyt adunk.
A nagyvállalatoknál általában éppen ellenkező a helyzet – a költség súlya nem csökken 50% alá, és lehet, hogy eléri a 60%-ot is. A modell példában csak az a fontos, hogy bármely szülő csomópont alcsomópontjainak összes súlya 100% kell, hogy legyen.
Kizáró feltételek
Az oldal körülbelül 500 adatbázis-kezelő rendszert ismer. Nyilvánvaló, hogy ha egy célt választunk ilyen mennyiségű választási lehetőségből, akkor lehet, hogy áttekintő cikk születik, de nem kereskedelmi projekt. A választási lehetőségek szűkítése érdekében kizárási kritériumokat fogalmaznak meg, és ha egy platform nem felel meg ezeknek a kritériumoknak, akkor nem kerül megfontolásra.
A kizárási kritériumok kapcsolódhatnak a technológiai sajátosságokhoz, például:
- ACID-garanciák;
- relációs adatmodell;
- SQL nyelv támogatása (jegyezze meg, hogy ez nem ugyanaz, mint a „relációs modell”);
- a horizontális skálázhatóság képessége.
Lehetnek általános jellegű kritériumok is:
- kereskedelmi támogatás elérhetősége Magyarországon;
- nyílt forráskód;
- a platform megléte a Miniszterelnökség nyilvántartásában;
- a platform megléte valamely rangsorban (például a db-engines.com első száz helyezettje között);
- a piacon elérhető szakértők megléte (például a platform nevének keresése a hh.ru weboldalon található önéletrajzokban).
Végül lehetnek vállalatra jellemző kritériumok is:
- a vállalaton belüli szakemberek megléte;
- kompatibilitás az X monitorozó rendszerrel vagy az Y mentési rendszerrel, amelyhez minden karbantartás kapcsolódik...
A legfontosabb az, hogy legyen lista a kizárási kritériumokról. Ellenkező esetben biztosan lesz olyan szakértő (vagy „szakértő”), akit a vezetőség különösen megbízhatónak tart, aki azt mondja: „hogyhogy nem választották a Z platformot, tudom, hogy az a legjobb”.
Árértékelés
A megoldás költsége nyilvánvalóan a licencek költségéből, a karbantartás költségéből és a berendezések költségéből áll össze.
Ha a rendszerek körülbelül azonos osztályba tartoznak (például Microsoft SQL Server és PostgreSQL), akkor egyszerűség kedvéért feltételezhetjük, hogy a berendezések száma mindkét megoldáshoz körülbelül azonos lesz. Ez lehetővé teszi, hogy ne kelljen értékelni a berendezéseket, így rengeteg időt és energiát spórolhatunk meg. Ha viszont teljesen eltérő rendszereket kell összehasonlítani (például Oracle és Redis), akkor nyilvánvaló, hogy a helyes értékeléshez szükség van a méretezésre (a berendezések mennyiségének kiszámítására). A nem létező rendszer méretezése azonban meglehetősen hálátlan feladat, ezért ilyen összehasonlítást igyekeznek elkerülni. Ez egyszerűen megvalósítható: a kizárási feltételek között fel kell tüntetni a nulla adatvesztés és a relációs modell, vagy éppen ellenkezőleg – 50 ezer tranzakció másodperces terheléssel.
A licencák értékeléséhez elegendő, ha megkérdezzük a szállítót vagy partnereit az adott magok számához és a meghatározott időszakra vonatkozó támogatás költségéről. Általában a cégeknek már kiépített stabil kapcsolataik vannak a szoftverszolgáltatókkal, és ha az adatbázis üzemeltetési osztály nem tud válaszolni a költséggel kapcsolatos kérdésre, ehhez elegendő egy levél megküldése.
Különböző szállítóknál eltérő lehet a licencelési metrika: a magok száma, az adatmennyiség vagy a csomópontok száma alapján. A standby adatbázis lehet ingyenes, vagy ugyanúgy licencelhető, mint a fő. Ha csak különbségek merülnek fel a metrikákban, részletesen le kell írni a modellstandot, és ki kell számolni a licencdíjakat a standra.
Fontos szempont a helyes összehasonlításhoz – azonos támogatási feltételek. Például az Oracle támogatása évente a licenc költségének 22%-ába kerül, míg a PostgreSQL támogatásáért nem kell fizetni. Helyes-e így összehasonlítani? Nem, mert a saját erőből nem megoldható hibák következményei teljesen eltérőek: az első esetben a támogatási szakemberek gyorsan segítenek, a második esetben viszont kockázatot jelenthet a projekt késlekedése vagy a kész rendszer leállása meghatározatlan időre.
A számítási feltételeket három módon lehet egyeztetni:
- Használni az Oracle-t támogatás nélkül (a valóságban ez nem létezik).
- Megvásárolni a PostgreSQL támogatását – például a Postgres Professional cégtől.
- Belevonni a számításba a támogatás hiányával kapcsolatos kockázatokat.
Például a kockázatok számítása így nézhet ki: ha az adatbázisban nem orvosolható hiba következik be, a rendszer leállása 1 munkanapot jelent. A rendszer használatából tervezett nyereség évente 40 milliárd mongol tugrik, a meghibásodások gyakorisága 1/400-ra becsülhető, így a támogatás hiányának kockázata körülbelül 100 millió mongol tugrik évente. Nyilvánvaló, hogy a 'tervezett nyereség' és az 'észlelt hibafrekvencia' virtuális mennyiségek, de sokkal jobb egy ilyen modell birtokában lenni, mint hogy ne legyen semmilyen.
Valójában a rendszer túl fontos lehet, és a hosszan tartó leállásból eredő hírnévveszteség elfogadhatatlan lesz, ezért szükség lesz a támogatásra. Ha azonban a leállás megengedett, néha érdemes lehet lemondani a támogatásról a költségek csökkentése érdekében.
Tegyük fel, hogy minden számítás után az A platform üzemeltetési költsége 5 év alatt 800 millió mongol tugrik, a B platformé 650 millió tugrik, a C platformé pedig 600 millió tugrik lett. A C platform mint győztes a költség alapján teljes pontszámot kap, míg az A és B platformok arányosabban kevesebbet, attól függően, hogy mennyivel drágábbak. Ebben az esetben 0,75 és 0,92 pontot kaptak, respectivamente.
Lehetőségek értékelése
A lehetőségek értékelése számos csoportra oszlik, melyek számát csupán a becslést készítő fantáziája korlátozza. Optimális megközelítés, ha a lehetőségeket azokra a csapatokra osztjuk, akik ezeket igénybe veszik; példaként említsük a fejlesztőket, a rendszergazdákat és az információbiztonsági hivatalnokokat. Tegyük fel, hogy ezeknek a funkcióknak a súlyozása 40:40:20 arányban oszlik meg.
A fejlesztési funkciók közé tartozik:
- az adatok kezelésének kényelme;
- skálázhatóság;
- másodlagos indexek megléte.
A kritériumok listája és azok súlyai rendkívül szubjektívek. Még egyazon probléma megoldása esetén is a listák, a pontok súlyai és a válaszok jelentősen eltérhetnek a csapat összetételétől függően. Például a Facebook MySQL-t használ az adatok tárolására, míg az Instagram Cassandra alapjaira épül. Valószínűleg e programok fejlesztői nem töltötték ki ilyen táblázatokat. Csak találgathatunk, hogy Mark Zuckerberg a teljes relációs modellt választotta, és ezért alkalmazási shardingra volt szüksége, míg Kevin Systrom a platform eszközeivel számolta a skálázhatóságot feláldozva az adatokhoz való hozzáférés kényelmét.
A rendszergazdai funkciók közé tartoznak:
- a biztonsági mentési lehetőségek;
- a felügyelet kényelme;
- a teljesítmény kezelésének kényelme – lemezek és csomópontok;
- az adatok replikációs lehetőségei.
Vegyél figyelembe, hogy a kérdések megfogalmazásának lehetővé kell tennie a mennyiségi értékelést. Meg lehet akár állapodni abban is, hogy miként értékeljük az egyes funkciókat. Próbáljuk meg például értékelni a mentési eszközöket az Oracle DB által biztosított eszközök példáján keresztül:
Eszköz
Megjegyzés
Értékelés
imp/exp
Adatok ki- és betöltése
0.1
kezdeti/végső mentés
Fájlok másolása
0.3
RMAN
Inkrementális mentés lehetősége
0.7
ZDLRA
Csak inkrementális mentés, a leggyorsabb helyreállítás a megadott pontra
1.0
Ha nincsenek világos értékelési kritériumok, érdemes lehet néhány szakértőt kérni arra, hogy adjanak értékelést, majd azokat átlagolni.
Végül egyszerűen soroljuk fel az információbiztonság funkcióit:
- jelszókezelési politikák megléte;
- külső hitelesítési eszközök csatlakoztatásának lehetősége (LDAP, Kerberos);
- hozzáférési szerepmodell;
- auditálási lehetőségek;
- adatok titkosítása a lemezen;
- titkosítás hálózaton történő átvitelkor (TLS);
- adatok védelme az adminisztrátorokkal szemben.
Teljesítménytesztelés
Szeretném külön felhívni a figyelmet arra, hogy kerülni kell minden olyan terhelési teszt eredményének felhasználását, amelyet nem te hajtottál végre.
Először is, az adatok struktúrája és a tesztelt alkalmazások terhelési profilja jelentősen eltérhet attól a feladattól, amelyet meg szeretnél oldani. 10-15 évvel ezelőtt az adatbázis-gyártók nagy büszkeséggel mutogatták a TPC tesztek eredményeit, de úgy tűnik, manapság már senki sem veszi ezeket komolyan.
Másodszor, a rendszer teljesítménye erősen függ attól, hogy milyen platformra írták az eredeti kódot, és hogy milyen berendezéseken végezték a tesztet. Sok tesztet láttam, ahol az Oracle-t a PostgreSQL-lel hasonlították össze. Az eredmények a rendszer egyértelmű fölényétől az ugyanolyan egyértelmű fölényéig terjedtek.
Végül, harmadszor, semmit sem tudsz arról, hogy ki végezte a tesztet. Fontos a szakértelem, amely befolyásolja az operációs rendszer és a platform konfigurálásának minőségét, valamint a teszt eredményeire ható motiváció, amely erősebben befolyásolhatja az eredményt, mint minden más tényező együttvéve.
Ha a teljesítmény kritikus jelentőségű tényező, végezz tesztet saját magad, lehetőleg olyan szakemberekkel, akik be fogják állítani és karbantartják az ipari rendszert.
Eredmény
Végül a végzett munka eredményeként egy táblázatnak kell születnie, ahol az összes értékelés össze van gyűjtve, szorozva és összegezve van:
Ahogy látja, a súlyok módosításával és az értékelések kiigazításával bármilyen kívánt eredményt elérhet, de ez már egy egészen másik történet...
Forrás: habr.com
