– Erre szükség van – mondta hangosan, senkihez sem szólva. - Ez szükséges! Pontosan ez áll benne: egy cég fő feladata, hogy a részvényesek érdekében profitot termeljen. Nos, gondolj bele! Nem félnek semmitől!
Julij Dubov, „Kisebb gonosz”
Egy ilyen címet látva valószínűleg már eldöntötte, hogy a cikk vagy hülyeség, vagy provokáció. De ne rohanjon le a következtetésekkel: a nagyvállalatok, különösen az állami részvételű vállalatok alkalmazottainak gyakran kell összehasonlítaniuk a különböző platformokat, beleértve a teljesen eltérő platformokat is - például a címben szereplőket.
Természetesen senki sem hasonlítja össze így a DBMS-eket, mert az erősségeik és gyengeségeik jól ismertek. Általában az alkalmazási problémákat megoldó platformok összehasonlíthatók. A cikkben bemutatom az ebben az esetben alkalmazott módszertant, az adatbázisok példáján, mint a Habr-olvasók számára első kézből ismert témakörön keresztül. Így,
motiváció
Amikor elindít egy oktatási projektet vagy egy hobbiprojektet, a platform kiválasztásának motivációja nagyon sokféle lehet: „ez az a platform, amelyet a legjobban ismerek”, „Érdekel, hogy megértsem ezt”, „itt a legjobb dokumentáció” ... Kereskedelmi cégnél a kiválasztási szempont ugyanaz: mennyit kell fizetnem és mit kapok ezért a pénzért.
Természetesen kevesebbet szeretne fizetni, és többet szeretne kapni. Azonban el kell döntenie, hogy mi a fontosabb - kevesebbet fizetni vagy többet kapni, és minden csomóponthoz súlyt kell rendelnie. Tételezzük fel, hogy a jó minőségű megoldás fontosabb számunkra, mint az olcsó, és a „Költség” csomóponthoz 40%-ot, a „Lehetőségek” csomóponthoz 60%-os súlyt rendelünk.
A nagyvállalatoknál általában ennek az ellenkezője igaz - a költségsúly nem esik 50% alá, és talán több, mint 60%. A modellpéldában csak az a fontos, hogy bármely szülőcsomópont gyermekcsomópontjainak összsúlya 100% legyen.
Vágási feltételek
Webhely Mintegy 500 adatbázis-kezelő rendszer ismert. Természetesen, ha ilyen sok lehetőség közül választ egy célplatformot, akkor egy áttekintő cikkhez juthat, de nem egy kereskedelmi projekthez. A választási tér csökkentése érdekében kivágási kritériumokat fogalmaznak meg, és ha a platform nem felel meg ezeknek, akkor nem veszik figyelembe.
Az elzárási kritériumok vonatkozhatnak technológiai jellemzőkre, például:
- ACID garanciák;
- relációs adatmodell;
- SQL nyelv támogatása (megjegyzés, ez nem azonos a „relációs modellel”);
- vízszintes skálázás lehetősége.
Lehetnek általános kritériumok:
- kereskedelmi támogatás elérhetősége Oroszországban;
- nyílt forráskód;
- a platform elérhetősége a Távközlési és Tömegkommunikációs Minisztérium nyilvántartásában;
- a platform jelenléte valamilyen értékelésben (például a db-engines.com értékelés első százában);
- szakértők jelenléte a piacon (például a platform nevére a hh.ru webhelyen található önéletrajzban való keresés eredménye alapján).
Végül is lehetnek vállalatspecifikus kritériumok:
- szakemberek rendelkezésre állása a személyzetnél;
- kompatibilitás az X felügyeleti rendszerrel vagy az Y tartalék rendszerrel, amelyen minden támogatás alapul...
A legfontosabb dolog az, hogy van egy lista a határértékekről. Ellenkező esetben biztosan lesz olyan szakértő (vagy „szakértő”), aki különleges bizalmat élvez a vezetőség részéről, aki azt mondja: „miért nem a Z platformot választotta, tudom, hogy ez a legjobb”.
Költségbecslés
A megoldás költsége nyilvánvalóan a licencek költségéből, a támogatás költségéből és a felszerelés költségéből áll.
Ha a rendszerek megközelítőleg azonos osztályúak (például Microsoft SQL Server és PostgreSQL), akkor az egyszerűség kedvéért feltételezhetjük, hogy mindkét megoldás felszerelési mennyisége megközelítőleg azonos lesz. Ez lehetővé teszi, hogy ne értékelje a berendezést, ezáltal sok időt és erőfeszítést takaríthat meg. Ha teljesen különböző rendszereket kell összehasonlítani (mondjuk Oracle vs. Redis), akkor nyilvánvaló, hogy a helyes értékeléshez méretezést (felszereltségszámítást) kell végezni. Egy nem létező rendszer méretezése nagyon hálátlan feladat, ezért továbbra is igyekeznek kerülni az ilyen összehasonlításokat. Ez könnyen megtehető: a cut-off körülmények között nulla adatvesztés és relációs modell íródik, vagy fordítva - 50 ezer tranzakció másodpercenként.
A licencek értékeléséhez elegendő a szállítótól vagy partnereitől elkérni a fix számú mag licencének költségét és a meghatározott időtartamú támogatást. A cégek rendszerint már erős kapcsolatokat ápolnak a szoftverszállítókkal, és ha az adatbázis-üzemeltetési osztály nem tud önállóan válaszolni a költségkérdésre, akkor egy levél is elegendő az információ megszerzéséhez.
A különböző szállítók eltérő licencmérőkkel rendelkezhetnek: a magok száma, az adatmennyiség vagy a csomópontok száma szerint. A készenléti alap lehet ingyenes, vagy ugyanúgy licencelhető, mint a fő. Ha a mérőszámokban eltéréseket fedez fel, részletesen le kell írnia a modellállványt, és ki kell számítania az állvány licenceinek költségét.
A helyes összehasonlítás fontos szempontja az azonos támogatási feltételek. Például az Oracle támogatás a licenc árának 22%-ába kerül évente, de nem kell fizetni a PostgreSQL támogatásért. Helyes így összehasonlítani? Nem, mert egy önmagában nem javítható hiba egészen más következményekkel jár: az első esetben a támogatási szakemberek gyorsan segítenek a javításban, de a második esetben fennáll a projekt késésének vagy a kész leállásának a veszélye. rendszer határozatlan ideig.
A számítási feltételeket háromféleképpen lehet kiegyenlíteni:
- Használja az Oracle-t támogatás nélkül (a valóságban ez nem történik meg).
- Vásároljon támogatást a PostgreSQL-hez – például a Postgres Professional-tól.
- Vegye figyelembe a támogatás hiányával járó kockázatokat.
Például egy kockázatszámítás így nézhet ki: végzetes adatbázishiba esetén a rendszer leállási ideje 1 munkanap. A rendszer használatából származó tervezett nyereség évi 40 milliárd MNT, a baleseti ráta 1/400-ra becsülhető, így a támogatás hiányának kockázata körülbelül évi 100 millió MNT-re becsülhető. Nyilvánvalóan a „tervezett profit” és a „becsült baleseti gyakoriság” virtuális értékek, de sokkal jobb, ha van ilyen modell, mint ha nincs.
A valóságban a rendszer túlságosan fontos lehet ahhoz, hogy a hosszú távú leállások hírnevét befolyásoló költségek elfogadhatatlanok legyenek, ezért támogatásra lesz szükség. Ha az állásidő megengedett, akkor a támogatás megtagadása néha jó módja annak, hogy pénzt takarítson meg.
Tételezzük fel, hogy az összes számítás után az A platform üzemeltetési költsége 5 évre 800 millió MNT, a B üzemeltetési költsége 650 millió MNT, a C platformé pedig 600 millió MNT. A C platform nyertesként egy teljes pontot kap az árért, míg az A és B platformok valamivel kevesebbet kapnak, ahányszor drágábbak. Ebben az esetben – 0.75 és 0.92 pont.
Esélyértékelés
A lehetőségek felmérése sok csoportra oszlik, amelyek számának csak az értékelő fantáziája szab határt. Az optimális megoldásnak az tűnik, ha a képességeket olyan csapatokra osztják, amelyek használni fogják ezeket a képességeket; példánkban ezek fejlesztők, rendszergazdák és információbiztonsági tisztek. Tegyük fel, hogy ezeknek a függvényeknek a súlya 40:40:20-ban oszlik meg.
A fejlesztési funkciók a következők:
- egyszerű adatkezelés;
- méretezés;
- másodlagos indexek jelenléte.
A kritériumok listája, valamint azok súlya nagyon szubjektív. Még akkor is, ha ugyanazt a problémát oldja meg, ezek a listák, a tételek súlya és a válaszok jelentősen eltérnek a csapat összetételétől függően. Például a Facebook MySQL-t használ az adatok tárolására, az Instagram pedig Cassandra épül. Nem valószínű, hogy ezen alkalmazások fejlesztői ilyen táblázatokat töltöttek ki. Csak sejteni lehet, hogy Mark Zuckerberg egy teljes értékű relációs modellt választott, amiért az alkalmazott sharding szükségességével fizetett, míg Kevin Systrom a skálázást a platform segítségével építette fel, feláldozva az adatokhoz való könnyű hozzáférést.
Az adminisztrációs funkciók közé tartozik:
- biztonsági mentési rendszer képességei;
- könnyű megfigyelés;
- könnyű kapacitáskezelés – lemezek és csomópontok;
- adatreplikációs képességek.
Felhívjuk figyelmét, hogy a kérdéseket mennyiségileg kell megfogalmazni. Még abban is megállapodhat, hogy hogyan értékel egy adott funkciót. Próbáljuk meg például értékelni a biztonsági mentési eszközöket az Oracle DBMS-hez mellékelt eszközök példájával:
szerszám
Megjegyzés
Értékelés
imp/exp
Adatok fel- és betöltése
0.1
a biztonsági mentés kezdete/vége
Fájlok másolása
0.3
RMAN
Növekményes másolási lehetőség
0.7
ZDLRA
Csak növekményes másolás, a leggyorsabb helyreállás a pontig
1.0
Ha nincsenek egyértelmű értékelési kritériumok, érdemes több szakértőt felkérni, hogy adjanak értékelést, majd átlagolják azokat.
Végül egyszerűen felsoroljuk az információbiztonsági funkciókat:
- jelszókezelési szabályzatok elérhetősége;
- külső hitelesítési eszközök (LDAP, Kerberos) csatlakoztatásának képessége;
- a hozzáférés példaképe;
- auditálási képességek;
- lemezen lévő adatok titkosítása;
- titkosítás a hálózaton keresztüli átvitel során (TLS);
- adatvédelmet az adminisztrátortól.
Teljesítményfelmérés
Külön szeretném felhívni a figyelmet arra, hogy ne használjon olyan terhelési tesztek eredményeit érvként, amelyeket nem Ön készített.
Először is, a tesztelt alkalmazások adatszerkezete és terhelési profilja jelentősen eltérhet a megoldandó problémától. Körülbelül 10-15 évvel ezelőtt az adatbázis-szállítók előszeretettel fitogtatták a TPC-teszteken elért eredményeket, de most úgy tűnik, ezeket az eredményeket senki sem veszi komolyan.
Másodszor, a rendszer teljesítménye erősen függ attól, hogy a kódot eredetileg milyen platformra írták, és milyen berendezésen végezték el a tesztet. Sok olyan tesztet láttam, ahol az Oracle-t összehasonlították a PostgreSQL-lel. Az eredmények az egyik rendszer feltétlen felsőbbrendűségétől a másik rendszer ugyanolyan feltétlen felsőbbrendűségéig terjednek.
És végül, harmadszor, semmit sem tudsz arról, hogy ki végezte a tesztet. Mindkét minősítés fontos, befolyásolja az operációs rendszer és a platform beállításának minőségét, valamint a motivációt, amely jobban befolyásolja a teszteredményeket, mint az összes többi tényező együttvéve.
Ha a teljesítmény kritikus tényező, végezze el a tesztet saját maga, lehetőleg olyan emberek segítségével, akik konfigurálják és karbantartják a termelési rendszert.
Eredmény
Végül az összes elvégzett munka eredménye egy táblázat legyen, ahol az összes becslést összevonják, megszorozzák és összegzik:
Amint érti, a skála megváltoztatásával és az értékelések módosításával bármilyen kívánt eredményt elérhet, de ez egy teljesen más történet...
Forrás: will.com