jos haluat lisätietoja Cassandran ja muiden NoSQL-tietokantojen pysyvyydestä, katso, Mikä on NoSQL?
pysyvyyden merkityksen ymmärtäminen on tärkeää eri tietovarastojärjestelmien arvioinnissa. Kun otetaan huomioon tietovaraston merkitys useimmissa nykyaikaisissa sovelluksissa, huonosti informoidun valinnan tekeminen voi merkitä huomattavaa seisokkia tai tietojen menetystä. Tässä viestissä, keskustelemme pysyvyys ja data store suunnittelu lähestymistapoja ja antaa joitakin tausta näistä yhteydessä Cassandra.
pysyvyys on ”vaikutuksen jatkumista sen jälkeen, kun sen syy on poistettu”. Kun tieto tallennetaan tietojärjestelmään, tämä tarkoittaa, että tieto säilyy sen prosessin päätyttyä, jolla se luotiin. Toisin sanoen, jotta tietovarastoa voidaan pitää pysyvänä, sen on kirjoitettava haihtumattomaan tallennustilaan.
jos tarvitset pysyvyyttä tietovarastossasi, sinun on myös ymmärrettävä ne neljän ihmisen suunnittelumallit, joita tietovarasto voi käyttää, ja miten (tai jos) nämä mallit tarjoavat pysyvyyttä:
-
puhdas muisti, ei pysyvyyttä ollenkaan, kuten memcaches tai Scalaris
-
in-memory jaksollisilla tilannekuvilla, kuten Oracle Coherence tai Redis
-
Levypohjainen update-in-place-kirjoituksilla, kuten MySQL ISAM tai MongoDB
-
Commitlog-pohjainen, kuten kaikki perinteiset OLTP-tietokannat (Oracle, SQL Server jne.)
in-muisti lähestymistapoja voidaan saavuttaa paahtava nopeus, mutta kustannuksella on rajoitettu suhteellisen pieni tietojoukko. Useimmat työkuormat ovat suhteellisen pieni ”kuuma” (aktiivinen) osajoukko niiden koko TIEDOT; järjestelmät, jotka vaativat koko datset mahtua muistiin eikä vain aktiivinen osa ovat hienoja välimuistit, mutta huono sovi useimmille muille sovelluksille. Koska tieto on vain muistissa, se ei selviä prosessin päättymisestä. Tämän vuoksi tämäntyyppisiä tietovarastoja ei pidetä pysyvinä.
helpoin tapa lisätä pysyvyyttä muistijärjestelmään on jaksolliset tilannekuvat levylle konfiguroitavalla välein. Näin, voit menettää jopa että väli arvoinen päivityksiä.
Update-in-place-ja commitlog-pohjaiset järjestelmät tallentuvat haihtumattomaan muistiin välittömästi, mutta vain commitlog-pohjainen pysyvyys tarjoaa kestävyyden — D in ACID — jokaisen kirjoituksen säilyessä, ennen kuin onnistuminen palautetaan asiakkaalle.
Cassandra toteuttaa commit-log-pohjaisen pysyvyysmallin, mutta tarjoaa samalla viritettävän kestävyystason. Näin voit päättää, mitä oikea kauppa pois on turvallisuuden ja suorituskyvyn välillä. Voit valita, kunkin kirjoitusoperaation, odottaa, että päivitys puskuroidaan muistiin, kirjoitetaan levylle yhdellä koneella, kirjoitetaan levylle useilla koneilla tai jopa kirjoitetaan levylle useilla koneilla eri konesaleissa. Tai, voit hyväksyä kirjoittaa nopeasti kuin mahdollista, kuittaamalla niiden vastaanottamisesta välittömästi ennen kuin ne ovat edes täysin deserialized verkosta.
loppujen lopuksi olet ainoa, joka tietää, mikä on oikea suorituskyky/kestävyys kauppa pois on tietosi. Tietoisen päätöksen tekeminen tietovaraston teknologioista on ratkaisevan tärkeää tämän kaupan käsittelemiseksi ehdoillasi. Koska Cassandra tarjoaa tällaisen viritettävyyden, se on looginen valinta järjestelmille, joilla on tarve kestävälle, performant-tietovarastolle.