Kumpi on parempi – Oracle vai Redis vai Kuinka perustella alustan valinta

"Tämä on välttämätöntä", hän sanoi äänekkäästi puhumatta kenellekään. - Tämä on välttämätöntä! Juuri näin sanotaan: yrityksen päätehtävä on tuottaa voittoa osakkeenomistajien edun mukaisesti. No, mieti sitä! He eivät pelkää mitään!

Yuliy Dubov, "Pienempi paha"

Nähtyään tällaisen otsikon olet todennäköisesti jo päättänyt, että artikkeli on joko tyhmyyttä tai provokaatiota. Mutta älä kiirehdi johtopäätöksiin: suurten yritysten, erityisesti valtion osallistuvien yritysten, työntekijöiden on usein verrattava erilaisia ​​​​alustoja, mukaan lukien täysin erilaisia ​​- esimerkiksi otsikossa olevia.

Kumpi on parempi – Oracle vai Redis vai Kuinka perustella alustan valinta

Tietenkään kukaan ei vertaa DBMS-järjestelmiä tällä tavalla, koska niiden vahvuudet ja heikkoudet tunnetaan hyvin. Yleensä alustat, jotka ratkaisevat jonkin sovellusongelman, ovat vertailun kohteena. Artikkelissa esitän tässä tapauksessa käytettävän metodologian käyttämällä esimerkkiä tietokannoista aiheena, joka on Habr-lukijalle omakohtaisesti tuttu. Niin,

Motivaatio

Kun aloitat koulutusprojektin tai harrastusprojektin, motivaatio alustan valintaan voi olla hyvin monipuolinen: "tämän alustan tunnen parhaiten", "Olen kiinnostunut ymmärtämään tämän", "tässä on paras dokumentaatio" ... Kaupallisen yrityksen tapauksessa valintakriteeri on sama: kuinka paljon joudun maksamaan ja mitä saan tällä rahalla.

Luonnollisesti haluat maksaa vähemmän ja saada enemmän. Sinun on kuitenkin päätettävä, mikä on tärkeämpää - maksaa vähemmän vai saada enemmän, ja määritettävä paino jokaiselle solmulle. Oletetaan, että laadukas ratkaisu on meille tärkeämpi kuin halpa, ja annamme 40 %:n painoarvon ”Kustannus”-solmulle ja 60 %:n ”Opportunities”-solmulle.

Kumpi on parempi – Oracle vai Redis vai Kuinka perustella alustan valinta

Suurissa yrityksissä asia on yleensä päinvastoin - kustannuspaino ei putoa alle 50 % ja ehkä yli 60 %. Malliesimerkissä on tärkeää vain se, että minkä tahansa pääsolmun alisolmujen kokonaispainon on oltava 100 %.

Katkaisuehdot

Sivusto db-engines.com Tietokannan hallintajärjestelmiä tunnetaan noin 500. Luonnollisesti, jos valitset kohdealustan niin monista vaihtoehdoista, saatat päätyä katsausartikkeliin, mutta et kaupalliseen projektiin. Valintatilan pienentämiseksi muotoillaan rajakriteerit, ja jos alusta ei täytä näitä kriteerejä, sitä ei huomioida.

Katkaisukriteerit voivat liittyä teknisiin ominaisuuksiin, esimerkiksi:

  • ACID takuut;
  • relaatiotietomalli;
  • SQL-kielen tuki (huomaa, tämä ei ole sama kuin "relaatiomalli");
  • vaakasuuntaisen skaalauksen mahdollisuus.

Yleisiä kriteerejä voi olla:

  • kaupallisen tuen saatavuus Venäjällä;
  • avoin lähdekoodi;
  • alustan saatavuus tele- ja joukkoviestintäministeriön rekisterissä;
  • alustan läsnäolo jossain luokituksessa (esimerkiksi db-engines.com-luokituksen sadassa ensimmäisessä);
  • asiantuntijoiden läsnäolo markkinoilla (esimerkiksi sivuston hh.ru-sivuston ansioluettelossa olevan alustan nimen haun tulosten perusteella).

Loppujen lopuksi voi olla yrityskohtaisia ​​kriteerejä:

  • asiantuntijoiden saatavuus henkilöstöön;
  • Yhteensopivuus valvontajärjestelmän X tai varajärjestelmän Y kanssa, joihin kaikki tuki perustuu...

Tärkeintä on, että on olemassa luettelo katkaisukriteereistä. Muuten on varmasti joku asiantuntija (tai "asiantuntija"), joka nauttii johdon erityisestä luottamuksesta ja joka sanoo "miksi et valinnut alustaa Z, tiedän sen olevan paras."

Kustannusarvio

Ratkaisun kustannukset koostuvat luonnollisesti lisenssikustannuksista, tukikustannuksista ja laitekustannuksista.

Jos järjestelmät ovat suunnilleen samaa luokkaa (esimerkiksi Microsoft SQL Server ja PostgreSQL), voidaan yksinkertaisuuden vuoksi olettaa, että molempien ratkaisujen laitemäärä on suunnilleen sama. Tämä antaa sinun olla arvioimatta laitteita, mikä säästää paljon aikaa ja vaivaa. Jos joutuu vertailemaan täysin erilaisia ​​järjestelmiä (esim. Oracle vs. Redis), niin on selvää, että oikeaa arviointia varten on tarpeen tehdä mitoitus (laitteiden määrän laskeminen). Olemattoman järjestelmän mitoitus on erittäin kiittämätön tehtävä, joten tällaisia ​​vertailuja pyritään silti välttämään. Tämä on helppo tehdä: katkaisuolosuhteissa kirjoitetaan nolla datahäviö ja relaatiomalli tai päinvastoin - kuormitus 50 tuhatta tapahtumaa sekunnissa.

Lisenssien arvioimiseksi riittää, että kysytään myyjältä tai sen kumppaneilta lisenssin hinta kiinteälle määrälle ytimiä ja tuki tietylle ajanjaksolle. Pääsääntöisesti yrityksillä on jo vahvat suhteet ohjelmistotoimittajiin, ja jos tietokantatoimintaosasto ei itse pysty vastaamaan kustannuskysymykseen, riittää yksi kirje tämän tiedon saamiseksi.

Eri toimittajilla voi olla erilaisia ​​lisensointimittareita: ytimien lukumäärän, tietomäärän tai solmujen lukumäärän mukaan. Valmiustila voi olla ilmainen tai se voidaan lisensoida samalla tavalla kuin päätukiasema. Jos mittareissa havaitaan eroja, sinun on kuvattava mallistoa yksityiskohtaisesti ja laskettava osaston lisenssikustannukset.

Tärkeä seikka oikean vertailun kannalta on samat tukiehdot. Esimerkiksi Oraclen tuki maksaa 22 % lisenssihinnasta vuodessa, mutta sinun ei tarvitse maksaa PostgreSQL-tuesta. Onko oikein vertailla näin? Ei, koska virheellä, jota ei voida korjata itse, on täysin erilaiset seuraukset: ensimmäisessä tapauksessa tukiasiantuntijat auttavat sinua nopeasti korjaamaan sen, mutta toisessa tapauksessa on olemassa riski, että projekti viivästyy tai valmiin käyttökatkos. järjestelmä määräämättömäksi ajaksi.

Voit tasoittaa laskentaehdot kolmella tavalla:

  1. Käytä Oraclea ilman tukea (todellisuudessa näin ei tapahdu).
  2. Osta tuki PostgreSQL:lle – esimerkiksi Postgres Professionalilta.
  3. Ota huomioon tuen puutteeseen liittyvät riskit.

Esimerkiksi riskilaskenta voi näyttää tältä: vakavan tietokannan vian sattuessa järjestelmän seisokkiaika olisi 1 arkipäivä. Järjestelmän käytön ennustettu tuotto on 40 miljardia MNT vuodessa, tapaturmaasteen arvioidaan olevan 1/400, joten tuen puutteen riskiksi arvioidaan noin 100 miljoonaa MNT vuodessa. On selvää, että "suunniteltu voitto" ja "arvioitu tapaturmataajuus" ovat virtuaalisia arvoja, mutta on paljon parempi olla tällainen malli kuin ilman sitä.

Todellisuudessa järjestelmä voi olla liian tärkeä, jotta pitkän aikavälin seisokkien mainekustannukset eivät ole hyväksyttäviä, joten tukea tarvitaan. Jos seisokit sallitaan, tuesta kieltäytyminen voi joskus olla hyvä tapa säästää rahaa.

Oletetaan, että kaikkien laskelmien jälkeen käyttöalustan A kustannukset 5 vuodeksi osoittautuvat 800 miljoonaksi MNT, käyttöalustan B kustannukset 650 miljoonaksi MNT ja käyttöalustan C kustannukset 600 miljoonaksi MNT. Alusta C saa voittajana täyden pisteen hinnasta, kun taas alustat A ja B saavat hieman vähemmän suhteessa siihen, kuinka monta kertaa ne ovat kalliimpia. Tässä tapauksessa 0.75 ja 0.92 pistettä.

Mahdollisuuksien arviointi

Mahdollisuuksien arviointi on jaettu useisiin ryhmiin, joiden määrää rajoittaa vain arvioijan mielikuvitus. Optimaalinen vaihtoehto näyttää olevan jakaa valmiudet tiimeihin, jotka käyttävät näitä ominaisuuksia; esimerkissämme nämä ovat kehittäjiä, ylläpitäjiä ja tietoturvavastaavia. Oletetaan, että näiden funktioiden painot jakautuvat 40:40:20.

Kehitystehtäviin kuuluvat:

  • tietojen käsittelyn helppous;
  • skaalaus;
  • toissijaisten indeksien läsnäolo.

Kriteeriluettelo ja niiden painoarvot ovat hyvin subjektiivisia. Vaikka ratkaisisit saman ongelman, nämä luettelot, kohteiden painot ja vastaukset vaihtelevat merkittävästi tiimisi kokoonpanon mukaan. Esimerkiksi Facebook käyttää MySQL:ää tietojen tallentamiseen, ja Instagram on rakennettu Cassandralle. On epätodennäköistä, että näiden sovellusten kehittäjät olisivat täyttäneet tällaisia ​​taulukoita. Voidaan vain arvata, että Mark Zuckerberg valitsi täysimittaisen relaatiomallin ja maksoi siitä sovelletun shardingin tarpeella, kun taas Kevin Systrom rakensi skaalauksen alustan avulla uhraten tietojen helppokäyttöisyyden.

Hallintotehtäviin kuuluvat:

  • varmuuskopiointijärjestelmän ominaisuudet;
  • seurannan helppous;
  • kapasiteetin hallinnan helppous - levyt ja solmut;
  • tietojen replikointiominaisuudet.

Huomaa, että kysymykset on muotoiltava määrällisesti. Voit jopa sopia siitä, kuinka tietty toiminto arvioidaan. Yritetään esimerkiksi arvioida varmuuskopiointityökaluja käyttämällä esimerkkiä Oracle DBMS:n mukana toimitetuista työkaluista:

Työkalu
Kommentti
Arviointi

imp/exp
Tietojen lataaminen ja lataaminen
0.1

aloita/lopeta varmuuskopiointi
Tiedostojen kopioiminen
0.3

RMAN
Inkrementaalinen kopiointimahdollisuus
0.7

ZDLRA
Vain asteittainen kopiointi, nopein palautus kohteeseen
1.0

Jos selkeitä arviointiperusteita ei ole, on järkevää pyytää useita asiantuntijoita antamaan arvosanat ja sitten laskea niistä.

Lopuksi luetellaan vain tietoturvatoiminnot:

  • salasananhallintakäytäntöjen saatavuus;
  • kyky yhdistää ulkoisia todennustyökaluja (LDAP, Kerberos);
  • pääsyn roolimalli;
  • tarkastusominaisuudet;
  • levyllä olevien tietojen salaus;
  • salaus verkon kautta lähetyksen aikana (TLS);
  • tietosuoja järjestelmänvalvojalta.

Suorituskyvyn testaus

Haluaisin erikseen varoittaa käyttämästä argumentteina sellaisten kuormitustestien tuloksia, joita et ole tehnyt.

Ensinnäkin testattavien sovellusten tietorakenne ja kuormitusprofiili voivat poiketa merkittävästi ongelmasta, jota aiot ratkaista. Noin 10-15 vuotta sitten tietokantatoimittajat rakastivat TPC-testeissä saavutettuja tuloksia, mutta nyt näyttää siltä, ​​että kukaan ei ota näitä tuloksia vakavasti.

Toiseksi järjestelmän suorituskyky riippuu melko voimakkaasti siitä, mille alustalle koodi alun perin kirjoitettiin ja millä laitteilla testi suoritettiin. Olen nähnyt monia testejä, joissa Oraclea verrattiin PostgreSQL:ään. Tulokset vaihtelevat yhden järjestelmän ehdottomasta paremmuudesta toisen yhtä ehdottomaan paremmuuteen.

Ja lopuksi, kolmanneksi, et tiedä mitään siitä, kuka testin teki. Molemmat pätevyydet ovat tärkeitä, sillä ne vaikuttavat käyttöjärjestelmän ja alustan asennuksen laatuun sekä motivaatioon, joka vaikuttaa testituloksiin enemmän kuin kaikki muut tekijät yhteensä.

Jos suorituskyky on kriittinen tekijä, suorita testi itse, mieluiten tuotantojärjestelmän konfiguroivien ja ylläpitävien henkilöiden avulla.

Tulos

Lopuksi kaiken tehdyn työn tuloksena tulisi olla laskentataulukko, jossa kaikki arviot yhdistetään, kerrotaan ja lasketaan yhteen:

Kumpi on parempi – Oracle vai Redis vai Kuinka perustella alustan valinta

Kuten ymmärrät, asteikkoja muuttamalla ja arvosanoja säätämällä voit saavuttaa haluamasi tuloksen, mutta se on täysin eri tarina...

Lähde: will.com

Lisää kommentti