De fleste applikasjoner trenger en eller annen form for utholdenhet - en måte å lagre dataene utenfor applikasjonen for å oppbevare. Den mest grunnleggende måten er å skrive data til filsystemet, men det kan fort bli en langsom og uhåndterlig måte å løse problemet på. En fullverdig database gir en kraftig måte å indeksere og hente data på, men det kan også være for mye. Noen ganger er alt du trenger er en rask måte å ta en informasjonsform med fri form, knytte den til en etikett, stappe den et sted og trekke den ut igjen i en blikk.
Angi nøkkelverdilageret. Det er egentlig en NoSQL-database, men en med et svært spesifikt formål og en bevisst begrenset design. Jobben er å la deg ta data (en verdi), bruke en etikett på den (en nøkkel) og lagre den enten i minnet eller i noe lagringssystem som er optimalisert for rask gjenfinning. Applikasjoner bruker nøkkelverdidatabaser for alt fra hurtigbufring av objekter til deling av brukte data mellom applikasjonsnoder.
Mange relasjonsdatabaser kan fungere som nøkkelverdibutikker, men det er litt som å bruke en traktor-trailer til å kjøre dagligvarekjøring. Det fungerer, men det er dramatisk ineffektivt, og det er langt lettere måter å løse problemet på. En nøkkelverdilager, som andre NoSQL-databaser, gir akkurat nok infrastruktur for enkel lagring og henting av verdier, integreres mer direkte med applikasjoner som bruker den, og skalerer på en mer detaljert måte med applikasjonsarbeidsbelastningen.
Nøkkelverdi NoSQL-databasefunksjoner sammenlignet
Fem brukte produkter (inkludert en skytjeneste) er verdt å vurdere; de faktureres eksplisitt som nøkkelverdidatabaser eller tilbyr nøkkelverdilagring som en sentral funksjon. Deres grunnleggende forskjeller:
- Hazelcast og Memcached har en tendens til minimalisme, og gidder ikke engang å sikkerhetskopiere dataene på disken.
- Aerospike, Cosmos DB og Redis har full funksjoner, men dreier seg fortsatt om nøkkelverdimetaforen.
Tabell: Nøkkelverdi NoSQL-databaseprodukter sammenlignet
| Aerospike | Hazelcast IMDG | Microsoft Azure Cosmos DB | Memcached | Redis | |
|---|---|---|---|---|---|
| Plattformer | LWMO | Java | Bare sky | LWMO | LWMO |
| Gjeldende versjon | 3.14.1.1 | 3.9 | Ikke relevant | 1.5.1 | 4.0.1 |
| Første utgivelse | 2012 | 2008 | 2017 | 2003 | 2009 |
| Tillatelse | AGPL | Apache 2 | Proprietær | BSD | BSD |
| Diskstøttet | Ja | Nei | Ja | Nei | JaBSD |
| Gruppering | Ja | Ja | Ja | Nei | Ja |
| Skjæring / partisjonering | Ja | Ja | Ja | Nei | Ja |
| Innfødte skript | Ja | Java | Ja | Nei | Ja |
| Transaksjoner | Per tast | Ja | Ja | Nei | Ja |
| Innbyggbar | Ja* | Ja | Nei | Ja* | Ja* |
Aerospike nøkkelverdi NoSQL-database i dybden
Hvis Redis er Memcached på steroider, kan Aerospike sies å være Redis på steroider. I likhet med Redis er Aerospike en nøkkelverdi-butikk som kan fungere som en vedvarende database eller en datacache. Aerospike er designet for å være enkelt å gruppere og lett å skalere, for bedre å støtte arbeidsbelastninger.
Funksjoner unike for Aerospike
Mye i Aerospike ekko både andre nøkkelverdibutikker og andre NoSQL-databaser. Data lagres og hentes via nøkler, og dataene kan oppbevares i en rekke grunnleggende datatyper, inkludert 64-biters heltall, strenger, dobbel-presisjonsflyter og rå binære data seriell fra en rekke vanlige programmeringsspråk.
Aerospike kan også lagre data i komplisert typer - lister over verdier, samlinger av nøkkelverdipar som kalles kart og geospatiale data i GeoJSON-format. Aerospike kan utføre naturlig behandling av geospatiale data - for eksempel å bestemme hvilke steder som er lagret i databasen som er nærmest hverandre ved å bare utføre en forespørsel - noe som gjør det til et attraktivt alternativ for utviklere av applikasjoner som er avhengige av beliggenhet.
Data lagret i Aerospike kan organiseres i flere hierarkiske containere. Noen NoSQL-systemer er dokumentorienterte, noe som betyr at data er innkapslet i en slags objekt, vanligvis JSON. Med Aerospike er containere omtrent som dokumenter, men med funksjoner og atferd som er spesifikke for Aerospike. Hver type container lar deg angi forskjellige atferdsegenskaper på dataene i den.
For eksempel det øverste nivået av containere, navnerom, avgjør om dataene er lagret på disken, i RAM eller begge deler; om dataene blir replikert i klyngen eller på tvers av klynger; og når eller hvordan data er utløpt eller kastet ut. Gjennom navneområder lar Aerospike utviklere beholde de dataene som er mest tilgjengelige i minnet for raskest mulig respons.
Hvordan Aerospike håndterer lagring og klynging
Aerospike kan beholde dataene sine på nesten alle filsystemer, men det er skrevet spesielt for å dra nytte av SSD-er. Når det er sagt, ikke forvent å slippe Aerospike på noen gammel SSD og forvent gode resultater. Aerospikes utviklere holder en liste over godkjente SSD-enheter, og de har laget et verktøy som heter ACT for å rangere ytelsen til SSD-lagringsenheter under Aerospike-arbeidsbelastninger.
Aerospike, som de fleste NoSQL-systemer, bruker en delt-ingenting-arkitektur for replikering og klynging. Aerospike har ingen hovednoder og ingen manuell skjæring. Hver node er identisk. Data fordeles tilfeldig over nodene og balanseres automatisk for å hindre at flaskehalser dannes. Hvis du vil, kan du sette regler for hvor aggressivt data balanseres på nytt. Du kan konfigurere flere klynger, som kjører i forskjellige nettverkssegmenter eller til og med forskjellige datasentre, for å synkronisere med hverandre.
Skripting i Aerospike
I likhet med Redis tillater Aerospike utviklere å skrive Lua-skript, eller UDF-er (brukerdefinerte funksjoner), som kjører inne i Aerospike-motoren. Du kan bruke UDF-er til å lese eller endre poster, men det er best å bruke dem til å utføre høyhastighets, skrivebeskyttet, kartreduserende operasjoner på tvers av samlinger eller "streams" av poster på flere noder.
Hvor får jeg Aerospike
Aerospikes samfunnsutgave kan lastes ned direkte fra Aerospikes nettsted. Dette inkluderer serverutgaver for Linux, stasjonære versjoner for Apples MacOS og Microsofts Windows, skyutgaver for Amazon EC2, Azure og Google Compute Engine og Docker-containere. Enterprise-utgaven av Aerospike er tilgjengelig via Aerospikes Quick Start-program, som gir en ubegrenset prøveversjon på 90 dager.
Kildekoden er tilgjengelig på GitHub.
Hazelcast IMDG nøkkelverdi NoSQL-database i dybden
Hazelcast blir fakturert som et "datarutenett i minnet", egentlig en måte å samle RAM og CPU-ressurser på flere maskiner for å tillate datasett å distribueres over disse maskinene og manipuleres i minnet.
NoSQL-databaser tilbyr nøkkelverdi-, graf- eller dokumentfunksjoner. Hazelcast konsentrerer seg om nøkkelverdifunksjonalitet, og legger vekt på rask tilgang til distribuert data. I følge produsentene kan den også brukes som et alternativ til produkter som Pivotal Gemfire, Software Terracotta og Oracle Coherence.
Hazelcast kan kjøres som en distribuert tjeneste eller være innebygd direkte i et Java-program. Klienter er tilgjengelige for Java, Scala, .Net, C / C ++, Python og Node.js, og en for Go er i ferd.
Funksjoner unike for Hazelcast
Hazelcast er bygget med Java og har et Java-sentrisk økosystem. Hver node i en Hazelcast-klynge kjører en forekomst av Hazelcasts kjernebibliotek, IMDG, på JVM. Hvordan Hazelcast fungerer med data er også tett kartlagt til Java sine språkstrukturer. Java's Map-grensesnitt, for eksempel, brukes av Hazelcast for å gi nøkkelverdilagring. Som med Memcached skrives ingenting til disken; alt holdes i minnet hele tiden.
En fordel Hazelcast kan gi i et distribuert miljø er "nær cache", der ofte etterspurte objekter blir migrert til serveren som gjør forespørslene. På denne måten kan forespørslene utføres direkte i minnet på samme system, uten at det kreves en rundtur over nettverket.
Bortsett fra nøkkelverdipar, kan du lagre og distribuere mange andre typer datastrukturer gjennom Hazelcast. Noen er enkle implementeringer av Java-objekter, som Map. Andre er spesifikke for Hazelcast. MultiMap, for eksempel, er en variant på nøkkelverdilagring som kan lagre flere verdier under samme nøkkel. Disse funksjonene gjør det mulig å etterligne oppførselen til andre NoSQL-systemer, for eksempel å organisere data i dokumenter, men empasen er på strukturer som gjør det mulig å distribuere og få tilgang til data raskt.
Hvordan Hazelcast håndterer klynging
Hazelcast-klynger har ikke noe master / slave-oppsett; alt er peer-to-peer. Data deles automatisk og distribueres over alle medlemmene i klyngen. Du kan også utpeke visse klyngemedlemmer som “lite”, som ikke inneholder data først, men som senere kan promoteres til fullverdige medlemmer. Dette lar noen noder brukes strengt til beregning, eller for å distribuere data gradvis gjennom en klynge mens de blir brakt online.
Hazelcast kan også sikre at operasjoner bare fortsetter hvis minst et visst antall noder er online. Du må imidlertid konfigurere denne oppførselen manuelt, og den fungerer bare for visse datastrukturer. Fra og med Hazelcast versjon 3.9 kan du konfigurere datastrukturer på nytt over en klynge uten å måtte ta den offline.
Hvor får du Hazelcast
Hazelcast er tilgjengelig for nedlasting direkte fra Hazelcast-nettstedet. Den distribueres vanligvis som en samling av Java .JAR-filer. Docker-bilder er også tilgjengelig i det offisielle Docker-registeret.
Du kan laste ned bedriftsutgaven av Hazelcast direkte fra Hazelcast. Du kan også få en 30-dagers gratis prøveversjonsnøkkel for Hazelcast.
Memcached nøkkelverdi NoSQL-database i dybden
Memcached er omtrent like grunnleggende og raskt som nøkkelverdilagring blir. Opprinnelig skrevet som et akselerasjonslag for bloggplattformen LiveJournal, har Memcached siden blitt en allestedsnærværende komponent i stabler for webteknologi. Hvis du har mange små fragmenter av data som kan knyttes til en enkel nøkkel og ikke trenger å replikeres mellom cache-forekomster, er Memcached det rette verktøyet.
Funksjoner unike for Memcached
Memcached brukes oftest til caching av spørsmål fra en database og for å holde resultatene utelukkende i minnet. I så måte er det ulikt mange andre NoSQL-databaser, nøkkelverdi eller annet, siden de lagrer data i en eller annen vedvarende form.
Memcached tar ikke tilbake datalageret til noe. Alle nøkler holdes bare i minnet, så de fordamper når Memcached-forekomsten eller serveren som er vert for den tilbakestilles. Dermed kan Memcached egentlig ikke brukes som erstatning for en NoSQL-database.
Det det kan brukes til, er imidlertid en høyhastighets måte å stash ofte brukte data på, som kan ta større størrelsesorden mer tid å spørre fra en kilde.
Alle data som kan serialiseres til en binær strøm kan lagres i Memcached. Verdier kan settes til å utløpe etter en viss tid, eller på forespørsel, ved å referere til nøklene til verdiene fra et program. Mengden minne du bruker til en gitt forekomst av Memcached, er helt opp til deg, og flere servere kan kjøre Memcached side om side for å spre belastningen. Videre skalerer Memcached lineært med antall kjerner som er tilgjengelige i et system fordi det er et flertrådet program.
De mest populære programmeringsspråkene har klientbiblioteker for Memcached. For eksempel, libmemcached lar C- og C ++ - programmer fungere direkte med Memcached-forekomster. Det lar også Memcached være innebygd i C-programmer.
Hvordan Memcached håndterer klynging
Selv om du kan kjøre flere forekomster av Memcached, enten på samme server eller på flere noder over et nettverk, er det ingen automatisk føderasjon eller synkronisering av data mellom forekomster. Dataene som er satt inn i en Memcached-forekomst er bare tilgjengelige fra den forekomsten, periode.
Hvor får jeg Memcached
Memcaches kildekode er tilgjengelig for nedlasting fra GitHub og fra det offisielle Memcached-nettstedet. Linux-binærfiler er tilgjengelige i repositoriene for de fleste Linux-distribusjoner. Windows-brukere kan bygge den direkte fra kilden; noen uoffisielle binærfiler er bygget tidligere, men ser ikke ut til å være pålitelig tilgjengelige.
Microsoft Azure Cosmos DB nøkkelverdi NoSQL-database i dybden
De fleste databaser har ett overordnet paradigme: dokumentbutikk, nøkkelverdilager, bred kolonnelager, grafdatabase og så videre. Ikke så Azure Cosmos DB. Hentet fra Microsofts NoSQL-database som en tjeneste, er DocumentDB, Cosmos DB Microsofts forsøk på å lage en enkelt database som kan bruke flere paradigmer.
Funksjoner unike for Azure Cosmos DB
Cosmos DB bruker det som kalles et atom-post-sekvens lagringssystem for å støtte forskjellige datamodeller. Atomer er primitive typer som strenger, heltall og boolske verdier. Postene er samlinger av atomer, som strukturer i C. Sekvenser er matriser av enten atomer eller poster.
Cosmos DB bruker disse byggesteinene til å replikere oppførselen til flere databasetyper. Det kan gjengi oppførselen til tabeller som finnes i konvensjonelle relasjonsdatabaser. Men det kan også gjengi funksjonaliteten til datatypene som finnes i NoSQL-systemer - skjemale JSON-dokumenter (DocumentDB og MongoDB) og grafer (Gremlin, Apache TinkerPop).
