De fleste applikationer har brug for en eller anden form for vedholdenhed - en måde at gemme dataene uden for applikationen til opbevaring. Den mest basale måde er at skrive data til filsystemet, men det kan hurtigt blive en langsom og uhåndterlig måde at løse problemet på. En fuldblæst database giver en effektiv måde at indeksere og hente data på, men det kan også være for stort. Nogle gange er alt, hvad du har brug for, en hurtig måde at tage et fritformet stykke information på, knytte det til en etiket, opbevare det et eller andet sted og trække det ud igen i et øjeblik.
Indtast nøgleværdilageret. Det er i det væsentlige en NoSQL-database, men en med et meget specifikt formål og et bevidst begrænset design. Dens opgave er at lade dig tage data (en værdi), anvende en etiket på den (en nøgle) og gemme den enten i hukommelsen eller i et eller andet lagersystem, der er optimeret til hurtig hentning. Applikationer bruger nøgleværdidatabaser til alt fra cache-objekter til deling af almindeligt anvendte data mellem applikationsknudepunkter.
Mange relationsdatabaser kan fungere som nøgleværdibutikker, men det er lidt som at bruge en traktor-trailer til at køre dagligvarer. Det virker, men det er dramatisk ineffektivt, og der er langt lettere måder at løse problemet på. En nøgleværdibutik, som andre NoSQL-databaser, giver lige nok infrastruktur til simpel værdilagring og -hentning, integreres mere direkte med applikationer, der bruger den, og skaleres på en mere detaljeret måde med applikationsarbejdet.
Nøgleværdi NoSQL-databasefunktioner sammenlignet
Fem vidt anvendte produkter (inklusive en skytjeneste) er værd at overveje; de faktureres eksplicit som nøgleværdidatabaser eller tilbyder nøgleværdilagring som en central funktion. Deres grundlæggende forskelle:
- Hazelcast og Memcached har tendens til minimalisme og gider ikke engang at sikkerhedskopiere dataene på disken.
- Aerospike, Cosmos DB og Redis er mere komplette, men drejer sig stadig om nøgleværdimetaforen.
Tabel: Sammenlignet nøgleværdi NoSQL-databaseprodukter
| Aerospike | Hazelcast IMDG | Microsoft Azure Cosmos DB | Memcached | Redis | |
|---|---|---|---|---|---|
| Platforme | LWMO | Java | Kun sky | LWMO | LWMO |
| Nuværende version | 3.14.1.1 | 3.9 | Ikke relevant | 1.5.1 | 4.0.1 |
| Første udgivelse | 2012 | 2008 | 2017 | 2003 | 2009 |
| Licens | AGPL | Apache 2 | Proprietære | BSD | BSD |
| Disk-sikkerhedskopieret | Ja | Ingen | Ja | Ingen | JaBSD |
| Klyngedannelse | Ja | Ja | Ja | Ingen | Ja |
| Sharding / partitionering | Ja | Ja | Ja | Ingen | Ja |
| Native scripting | Ja | Java | Ja | Ingen | Ja |
| Transaktioner | Per tast | Ja | Ja | Ingen | Ja |
| Kan integreres | Ja* | Ja | Ingen | Ja* | Ja* |
Aerospike nøgleværdi NoSQL-database i dybden
Hvis Redis er Memcached på steroider, kan Aerospike siges at være Redis på steroider. Ligesom Redis er Aerospike en nøgleværdibutik, der kan fungere som en vedvarende database eller en datacache. Aerospike er designet til at være let at gruppere og let at skalere for bedre at understøtte arbejdsbelastninger for virksomheder.
Funktioner unikke for Aerospike
Meget i Aerospike ekko både andre nøgleværdibutikker og andre NoSQL-databaser. Data gemmes og hentes via nøgler, og dataene kan opbevares i et antal grundlæggende datatyper, herunder 64-bit heltal, strenge, dobbeltpræcisionsflydninger og rå binære data, der er serialiseret fra et antal almindelige programmeringssprog.
Aerospike kan også gemme data i kompleks typer - lister over værdier, samlinger af nøgleværdipar kaldet kort og geospatiale data i GeoJSON-format. Aerospike kan udføre native behandling af geospatiale data - som f.eks. At bestemme, hvilke placeringer der er gemt i databasen, der er tættest på hinanden ved blot at udføre en forespørgsel - hvilket gør det til en attraktiv mulighed for udviklere af applikationer, der er afhængige af placering.
Data gemt i Aerospike kan organiseres i flere hierarkiske containere. Nogle NoSQL-systemer er dokumentorienterede, hvilket betyder, at data er indkapslet i en slags objekt, typisk JSON. Med Aerospike er containere omtrent som dokumenter, men med funktioner og adfærd, der er specifikke for Aerospike. Hver type container giver dig mulighed for at indstille forskellige adfærdsmæssige egenskaber på dataene inde i den.
For eksempel det øverste niveau af containere, navneområder, bestemmer, om dataene er gemt på disken, i RAM eller begge dele; om dataene replikeres i klyngen eller på tværs af klynger; og hvornår eller hvordan data udløber eller bortkastes. Via navneområder giver Aerospike udviklere mulighed for at gemme de hyppigst tilgængelige data i hukommelsen for at få det hurtigst mulige svar.
Sådan håndterer Aerospike opbevaring og klynger
Aerospike kan gemme sine data på næsten ethvert filsystem, men det er blevet skrevet specifikt for at drage fordel af SSD'er. Når det er sagt, forvent ikke at droppe Aerospike på nogen gammel SSD og forvent gode resultater. Aerospikes udviklere vedligeholder en liste over godkendte SSD-enheder, og de har oprettet et værktøj kaldet ACT til at bedømme ydelsen for SSD-lagerenheder under Aerospike-arbejdsbelastninger.
Aerospike bruger som de fleste NoSQL-systemer en delt-ingenting-arkitektur af hensyn til replikering og klyngedannelse. Aerospike har ingen masternoder og ingen manuel afskærmning. Hver knude er identisk. Data fordeles tilfældigt på tværs af noderne og balanceres automatisk for at forhindre, at flaskehalse dannes. Hvis du vil, kan du indstille regler for, hvor aggressivt data balanceres igen. Du kan konfigurere flere klynger, der kører i forskellige netværkssegmenter eller endda forskellige datacentre, så de synkroniseres med hinanden.
Scripting i Aerospike
Ligesom Redis tillader Aerospike udviklere at skrive Lua-scripts eller UDF'er (brugerdefinerede funktioner), der kører inde i Aerospike-motoren. Du kan bruge UDF'er til at læse eller ændre poster, men det er bedst at bruge dem til at udføre hurtige, skrivebeskyttede, kortreducerende operationer på tværs af samlinger eller "streams" af poster på flere noder.
Hvor kan man få Aerospike
Aerospikes community-udgave kan downloades direkte fra Aerospikes hjemmeside. Dette inkluderer serverudgaver til Linux, desktopversioner til Apples MacOS og Microsofts Windows, cloududgaver til Amazon EC2, Azure og Google Compute Engine og Docker-containere. Enterprise-udgaven af Aerospike er tilgængelig via Aerospikes Quick Start-program, der giver en ubegrænset 90-dages prøveversion.
Kildekoden er tilgængelig på GitHub.
Hazelcast IMDG-nøgleværdi NoSQL-database i dybden
Hazelcast leveres som et "datagitter i hukommelsen", i det væsentlige en måde at samle RAM og CPU-ressourcer på tværs af flere maskiner for at tillade, at datasæt distribueres på tværs af disse maskiner og manipuleres i hukommelsen.
NoSQL-databaser tilbyder nøgleværdi-, graf- eller dokumentfunktioner. Hazelcast koncentrerer sig om nøgleværdifunktionalitet og understreger hurtig adgang til distribuerede data. Ifølge dets producenter kan det også bruges som et alternativ til produkter som Pivotal Gemfire, Software Terracotta og Oracle Coherence.
Hazelcast kan køres som en distribueret tjeneste eller integreres direkte i en Java-applikation. Klienter er tilgængelige for Java, Scala, .Net, C / C ++, Python og Node.js, og en til Go er på vej.
Funktioner unikke for Hazelcast
Hazelcast er bygget med Java og har et Java-centreret økosystem. Hver knude i en Hazelcast-klynge kører en forekomst af Hazelcasts kernebibliotek, IMDG, på JVM. Hvordan Hazelcast fungerer med data kortlægges også tæt på Java's sprogstrukturer. Java's Map-interface bruges for eksempel af Hazelcast til at levere nøgleværdilagring. Som med Memcached skrives intet til disken; alt holdes i hukommelsen hele tiden.
En fordel, som Hazelcast kan tilbyde i et distribueret miljø, er "nær cache", hvor ofte anmodede objekter migreres til serveren, der fremsætter anmodningerne. På denne måde kan anmodningerne udføres direkte i hukommelsen på det samme system uden at kræve en rundtur på tværs af netværket.
Bortset fra nøgleværdipar kan du gemme og distribuere mange andre slags datastrukturer gennem Hazelcast. Nogle er enkle implementeringer af Java-objekter som Map. Andre er specifikke for Hazelcast. MultiMap er for eksempel en variant på nøgleværdilagring, der kan gemme flere værdier under den samme nøgle. Disse funktioner gør det muligt at efterligne adfærd fra andre NoSQL-systemer, såsom organisering af data i dokumenter, men empasis er på strukturer, der gør det muligt at distribuere og få adgang til data hurtigt.
Hvordan Hazelcast håndterer klynger
Hazelcast-klynger har ingen master / slave-opsætning; alt er peer-to-peer. Data deles automatisk og distribueres på tværs af alle medlemmer af klyngen. Du kan også udpege bestemte klyngemedlemmer som “lite”, som først ikke indeholder nogen data, men senere kan promoveres til fulde medlemmer. Dette gør det muligt at bruge nogle noder strengt til beregning eller distribuere data gradvist gennem en klynge, mens de bringes online.
Hazelcast kan også sikre, at operationer kun fortsætter, hvis mindst et bestemt antal noder er online. Du skal dog konfigurere denne adfærd manuelt, og den fungerer kun for visse datastrukturer. Fra Hazelcast version 3.9 kan du omkonfigurere datastrukturer på tværs af en klynge uden først at skulle tage den offline.
Hvor kan man få Hazelcast
Hazelcast kan downloades direkte fra Hazelcast-webstedet. Det implementeres typisk som en samling af Java .JAR-filer. Docker-billeder er også tilgængelige i det officielle Docker-register.
Du kan downloade virksomhedsudgaven af Hazelcast direkte fra Hazelcast. Du kan også få en 30-dages gratis prøvenøgle til Hazelcast.
Memcached nøgleværdi NoSQL-database i dybden
Memcached er omtrent lige så grundlæggende og hurtig som nøgleværdilagring bliver. Oprindeligt skrevet som et accelerationslag til bloggingplatformen LiveJournal, er Memcached siden blevet en allestedsnærværende komponent i webteknologi-stakke. Hvis du har mange små fragmenter af data, der kan tilknyttes en simpel nøgle og ikke behøver at blive replikeret mellem cache-forekomster, er Memcached det rigtige værktøj.
Funktioner, der er unikke for Memcached
Memcached bruges mest til cache-forespørgsler fra en database og udelukkende at gemme resultaterne i hukommelsen. I den henseende er det i modsætning til mange andre NoSQL-databaser, nøgleværdi eller på anden måde, da de gemmer data i en eller anden vedvarende form.
Memcached bakker ikke datalageret til noget. Alle taster holdes kun i hukommelsen, så de fordamper, når Memcached-forekomsten eller serveren, der hoster den, nulstilles. Således kan Memcached ikke rigtig bruges som erstatning for en NoSQL-database.
Hvad det dog kan bruges til, er en højhastigheds måde at gemme almindeligt anvendte data på, der kan tage størrelsesordener mere tid at spørge fra en kilde.
Alle data, der kan serialiseres til en binær strøm, kan gemmes i Memcached. Værdier kan indstilles til at udløbe efter et bestemt tidsrum eller efter behov ved at henvise til nøglerne til værdierne fra en applikation. Mængden af hukommelse, du bruger til en given forekomst af Memcached, er helt op til dig, og flere servere kan køre Memcached side om side for at sprede belastningen. Desuden skaleres Memcached lineært med antallet af kerner, der er tilgængelige i et system, fordi det er et multitrådet program.
De mest populære programmeringssprog har klientbiblioteker til Memcached. For eksempel, libmemcached tillader C- og C ++ - programmer at arbejde direkte med Memcached-forekomster. Det lader også Memcached integreres i C-programmer.
Sådan håndterer Memcached klynger
Selvom du kan køre flere forekomster af Memcached, hvad enten det er på den samme server eller på flere noder på tværs af et netværk, er der ingen automatisk føderation eller synkronisering af data blandt forekomster. Dataene indsat i en Memcached-forekomst er kun tilgængelig fra den pågældende forekomst, periode.
Hvor kan man få Memcached
Memcached's kildekode kan downloades fra GitHub og fra det officielle Memcached-sted. Linux-binære filer er tilgængelige i repositorierne til de fleste Linux-distributioner. Windows-brugere kan bygge det direkte fra kilden; nogle uofficielle binære filer er blevet bygget tidligere, men synes ikke at være pålideligt tilgængelige.
Microsoft Azure Cosmos DB-nøgleværdi NoSQL-database i dybden
De fleste databaser har et overordnet paradigme: dokumentlager, nøgleværdilager, bred kolonnelager, grafdatabase osv. Ikke så Azure Cosmos DB. Afledt af Microsofts NoSQL-database som en service, DocumentDB, Cosmos DB er Microsofts forsøg på at oprette en enkelt database, der kan bruge flere paradigmer.
Funktioner, der er unikke for Azure Cosmos DB
Cosmos DB bruger det, der kaldes et atom-record-sekvens lagersystem til at understøtte forskellige datamodeller. Atomer er primitive typer som strenge, heltal og boolske værdier. Records er samlinger af atomer, ligesom structs i C. Sekvenser er arrays af enten atomer eller records.
Cosmos DB bruger disse byggesten til at replikere adfærden for flere databasetyper. Det kan gengive opførslen af tabeller, der findes i konventionelle relationsdatabaser. Men det kan også gengive funktionaliteten af datatyper, der findes i NoSQL-systemer - skematiske JSON-dokumenter (DocumentDB og MongoDB) og grafer (Gremlin, Apache TinkerPop).
