Wat is beter – Oracle of Redis of hoe om die keuse van platform te regverdig

"Dit is nodig," het sy hard gesê en niemand aangespreek nie. - Dit is nodig! Dit is presies wat dit sê: die hooftaak van 'n maatskappy is om wins te maak in belang van aandeelhouers. Wel, dink daaroor! Hulle is vir niks bang nie!

Yuliy Dubov, "Lesser Evil"

Nadat jy so 'n opskrif gesien het, het jy seker al besluit dat die artikel óf onnoselheid óf 'n provokasie is. Maar moenie tot gevolgtrekkings jaag nie: werknemers van groot korporasies, veral korporasies met staatsdeelname, moet dikwels verskillende platforms vergelyk, insluitend heeltemal verskillendes - byvoorbeeld dié in die titel.

Wat is beter – Oracle of Redis of hoe om die keuse van platform te regverdig

Natuurlik vergelyk niemand DBBS'e op hierdie manier nie, want hul sterk- en swakpunte is welbekend. As 'n reël is platforms wat een of ander toepassingsprobleem oplos, onderhewig aan vergelyking. In die artikel sal ek die metodologie wys wat in hierdie geval gebruik word, met die voorbeeld van databasisse as 'n onderwerp wat eerstehands aan Habr-lesers bekend is. Dus,

Motivering

Wanneer jy 'n opvoedkundige projek of 'n stokperdjieprojek begin, kan die motivering vir die keuse van 'n platform baie uiteenlopend wees: "dit is die platform wat ek die beste ken", "Ek stel belang om hierdie een te verstaan", "hier is die beste dokumentasie" ... In die geval van 'n kommersiële maatskappy is die seleksiekriterium dieselfde: hoeveel sal ek moet betaal en wat sal ek vir hierdie geld kry.

Natuurlik wil jy minder betaal en meer kry. Jy moet egter besluit wat belangriker is - minder betaal of meer kry, en 'n gewig aan elke nodus toeken. Kom ons neem aan dat 'n oplossing van hoë gehalte vir ons belangriker is as 'n goedkoop een, en ons ken 'n gewig van 40% toe aan die "Koste"-nodus en 60% aan die "Geleenthede"-knoop.

Wat is beter – Oracle of Redis of hoe om die keuse van platform te regverdig

In groot korporasies is die teenoorgestelde gewoonlik waar - die kostegewig val nie onder 50% nie, en miskien meer as 60%. In die modelvoorbeeld is al wat belangrik is dat die totale gewig van die kindnodusse van enige ouernodus 100% moet wees.

Afsnytoestande

Werf db-engines.com Daar is ongeveer 500 databasisbestuurstelsels bekend. Natuurlik, as u 'n teikenplatform uit soveel opsies kies, kan u uiteindelik 'n resensieartikel kry, maar nie 'n kommersiële projek nie. Om die keuseruimte te verminder, word afsnykriteria geformuleer, en as die platform nie aan hierdie kriteria voldoen nie, word dit nie oorweeg nie.

Afsnykriteria kan verband hou met tegnologiese kenmerke, byvoorbeeld:

  • SUUR waarborge;
  • relasionele datamodel;
  • SQL-taalondersteuning (let wel, dit is nie dieselfde as die "relasionele model" nie);
  • moontlikheid van horisontale skaal.

Daar kan algemene kriteria wees:

  • beskikbaarheid van kommersiële ondersteuning in Rusland;
  • oop bron;
  • beskikbaarheid van die platform in die register van die Ministerie van Telekommunikasie en Massakommunikasie;
  • teenwoordigheid van die platform in sommige graderings (byvoorbeeld in die eerste honderd van die db-engines.com-gradering);
  • die teenwoordigheid van kundiges in die mark (byvoorbeeld, gebaseer op die resultate van die soektog na die naam van die platform in 'n CV op die webwerf hh.ru).

Daar kan immers ondernemingspesifieke kriteria wees:

  • beskikbaarheid van spesialiste op personeel;
  • verenigbaarheid met moniteringstelsel X of rugsteunstelsel Y, waarop alle ondersteuning gebaseer is ...

Die belangrikste ding is dat daar 'n lys van afsnykriteria is. Andersins sal daar beslis een of ander kundige (of "kenner") wees wat spesiale vertroue van die bestuur geniet wat sal sê "hoekom het jy nie platform Z gekies nie, ek weet dit is die beste."

Kosteberekening

Die koste van die oplossing bestaan ​​natuurlik uit die koste van lisensies, die koste van ondersteuning en die koste van toerusting.

As die stelsels ongeveer dieselfde klas is (byvoorbeeld Microsoft SQL Server en PostgreSQL), dan kan ons vir eenvoud aanvaar dat die hoeveelheid toerusting vir beide oplossings ongeveer dieselfde sal wees. Dit sal jou toelaat om nie die toerusting te evalueer nie, en sodoende baie tyd en moeite bespaar. As jy heeltemal verskillende stelsels moet vergelyk (sê Oracle vs. Redis), dan is dit duidelik dat dit vir 'n korrekte assessering nodig is om grootte te doen (berekening van die hoeveelheid toerusting). Die grootte van 'n nie-bestaande stelsel is 'n baie ondankbare taak, so hulle probeer steeds sulke vergelykings vermy. Dit is maklik om te doen: in die afsnytoestande word geen dataverlies en 'n relasionele model geskryf, of omgekeerd - 'n las van 50 duisend transaksies per sekonde.

Om lisensies te evalueer, is dit genoeg om die verkoper of sy vennote te vra vir die koste van 'n lisensie vir 'n vaste aantal kerne en ondersteuning vir 'n vasgestelde tydperk. As 'n reël het maatskappye reeds sterk verhoudings met sagtewareverkopers, en as die databasisbedryfsafdeling nie die kostevraag op sy eie kan beantwoord nie, dan is een brief genoeg om hierdie inligting te bekom.

Verskillende verskaffers kan verskillende lisensiemaatstawwe hê: volgens aantal kerns, datavolume of aantal nodusse. Die bystandbasis kan gratis wees, of dit kan op dieselfde manier as die hoof een gelisensieer word. Indien enige verskille in metrieke ontdek word, sal jy die modelstand in detail moet beskryf en die koste van lisensies vir die standplaas moet bereken.

'n Belangrike punt vir 'n korrekte vergelyking is dieselfde ondersteuningstoestande. Oracle-ondersteuning kos byvoorbeeld 22% van die lisensieprys per jaar, maar jy hoef nie vir PostgreSQL-ondersteuning te betaal nie. Is dit korrek om so te vergelyk? Nee, want 'n fout wat nie op jou eie reggemaak kan word nie, het heeltemal ander gevolge: in die eerste geval sal ondersteuningspesialiste jou vinnig help om dit reg te stel, maar in die tweede geval is daar 'n risiko dat die projek of stilstand van die voltooide vertraag word. stelsel vir 'n onbepaalde tydperk.

U kan die berekeningsvoorwaardes op drie maniere gelykmaak:

  1. Gebruik Oracle sonder ondersteuning (in werklikheid gebeur dit nie).
  2. Koop ondersteuning vir PostgreSQL - byvoorbeeld by Postgres Professional.
  3. Neem die risiko's wat verband hou met 'n gebrek aan ondersteuning in ag.

Byvoorbeeld, 'n risikoberekening kan soos volg lyk: in die geval van 'n noodlottige databasismislukking, sal die stelselstilstand 1 werksdag wees. Die geprojekteerde wins uit die gebruik van die stelsel is 40 miljard MNT per jaar, die ongeluksyfer word geskat op 1/400, dus word die risiko van gebrek aan ondersteuning op ongeveer 100 miljoen MNT per jaar geraam. Uiteraard is "beplande wins" en "geskatte ongeluksfrekwensie" virtuele waardes, maar dit is baie beter om so 'n model te hê as om nie enige te hê nie.

In werklikheid is die stelsel dalk te belangrik vir die reputasiekoste van langtermyn-stilstand om onaanvaarbaar te wees, so ondersteuning sal vereis word. As stilstand toegelaat word, kan die weiering van ondersteuning soms 'n goeie manier wees om geld te spaar.

Kom ons neem aan dat na al die berekeninge, die koste van bedryfsplatform A vir 5 jaar blyk 800 miljoen MNT te wees, die koste van bedryfsplatform B is 650 miljoen MNT, en die koste van bedryfsplatform C is 600 miljoen MNT. Platform C, as die wenner, kry 'n volle punt vir die prys, terwyl platforms A en B 'n bietjie minder kry, in verhouding tot hoeveel keer hulle duurder is. In hierdie geval – onderskeidelik 0.75 en 0.92 punte.

Geleentheidsbeoordeling

Die assessering van geleenthede word in baie groepe verdeel, waarvan die aantal slegs beperk word deur die verbeelding van die persoon wat die assessering doen. Die optimale opsie blyk te wees om die vermoëns in spanne te verdeel wat hierdie vermoëns sal gebruik; in ons voorbeeld is dit ontwikkelaars, administrateurs en inligtingsekuriteitsbeamptes. Kom ons neem aan dat die gewigte van hierdie funksies as 40:40:20 versprei is.

Ontwikkelingsfunksies sluit in:

  • gemak van datamanipulasie;
  • skaalvorming;
  • teenwoordigheid van sekondêre indekse.

Die lys van kriteria, sowel as hul gewigte, is baie subjektief. Selfs wanneer dieselfde probleem opgelos word, sal hierdie lyste, itemgewigte en antwoorde aansienlik verskil na gelang van die samestelling van jou span. Facebook gebruik byvoorbeeld MySQL om data te stoor, en Instagram is op Cassandra gebou. Dit is onwaarskynlik dat die ontwikkelaars van hierdie toepassings sulke tabelle ingevul het. Mens kan net raai dat Mark Zuckerberg 'n volwaardige verhoudingsmodel gekies het, en daarvoor betaal het met die behoefte aan toegepaste sharding, terwyl Kevin Systrom skaal gebou het deur die platform te gebruik, wat die gemak van toegang tot data opgeoffer het.

Administrasie funksies sluit in:

  • rugsteunstelselvermoëns;
  • gemak van monitering;
  • gemak van kapasiteitsbestuur - skywe en nodusse;
  • data replikasie vermoëns.

Neem asseblief kennis dat vrae op 'n kwantitatiewe wyse bewoord moet word. Jy kan selfs saamstem oor hoe om 'n spesifieke funksie te evalueer. Kom ons probeer byvoorbeeld om rugsteunnutsmiddels te gradeer deur gebruik te maak van die voorbeeld van gereedskap wat met die Oracle DBMS verskaf word:

Tool
Lewer kommentaar
Evaluering

imp/exp
Oplaai en laai van data
0.1

begin/beëindig rugsteun
Kopieer lêers
0.3

RMAN
Inkrementele kopieervermoë
0.7

ZDLRA
Slegs inkrementele kopiëring, vinnigste herstel na punt
1.0

As daar nie duidelike evalueringskriteria is nie, maak dit sin om verskeie kundiges te vra om graderings te gee en dit dan te gemiddelde.

Ten slotte lys ons bloot die inligtingsekuriteitsfunksies:

  • beskikbaarheid van wagwoordbestuurbeleide;
  • die vermoë om eksterne verifikasie-instrumente (LDAP, Kerberos) te koppel;
  • rolmodel van toegang;
  • ouditvermoëns;
  • enkripsie van data op skyf;
  • enkripsie tydens transmissie oor die netwerk (TLS);
  • databeskerming deur die administrateur.

Prestasietoetsing

Afsonderlik wil ek daarteen waarsku om die resultate van enige lastoetse wat nie deur jou gemaak is nie as argumente te gebruik.

Eerstens kan die datastruktuur en vragprofiel van die toepassings wat getoets word aansienlik verskil van die probleem wat jy gaan oplos. Ongeveer 10-15 jaar gelede het databasisverkopers daarvan gehou om die resultate wat in TPC-toetse behaal is, te pronk, maar nou, dit blyk, neem niemand hierdie resultate ernstig op nie.

Tweedens hang stelselwerkverrigting redelik sterk af van watter platform die kode oorspronklik geskryf is en van watter toerusting die toets uitgevoer is. Ek het baie toetse gesien waar Oracle met PostgreSQL vergelyk is. Die resultate wissel van die onvoorwaardelike meerderwaardigheid van een sisteem tot die ewe onvoorwaardelike meerderwaardigheid van 'n ander.

En laastens, derdens, weet jy niks van wie die toets gedoen het nie. Beide kwalifikasies is belangrik, wat die kwaliteit van die opstel van die bedryfstelsel en platform beïnvloed, sowel as motivering, wat die toetsresultate meer beïnvloed as alle ander faktore saam.

As prestasie 'n kritieke faktor is, voer die toets self uit, verkieslik met die hulp van die mense wat die produksiestelsel sal konfigureer en in stand hou.

Gevolg

Ten slotte, die resultaat van al die werk wat gedoen is, moet 'n sigblad wees waar al die skattings gekombineer, vermenigvuldig en opgesom word:

Wat is beter – Oracle of Redis of hoe om die keuse van platform te regverdig

Soos u verstaan, kan u enige gewenste resultaat bereik deur die skale te verander en die graderings aan te pas, maar dit is 'n heeltemal ander storie ...

Bron: will.com

Voeg 'n opmerking