NoSQL har vært en av de mest snakket om emner de siste par månedene. Denne opplæringen vil introdusere deg til CouchDB, en NoSQL-implementering og lære deg hvordan du kommer i gang med plattformen.
NoSQL er skjemafri - du trenger ikke å bestemme strukturen foran.
NoSQL [ikke bare SQL] er en bevegelse mot dokumentforretninger som ikke benytter seg av relasjonsmodellen. Det grunnleggende paradigmeskiftet er i måten de lagrer data på. For eksempel, når du trenger å lagre data om en faktura, må du i RDBMS distillere denne informasjonen i tabeller og deretter bruke et språk på server-siden for å transformere disse dataene tilbake til virkelige objekter. På den annen side, i NoSQL, lagrer du bare fakturaen. NoSQL er skjemafri, noe som betyr at du ikke trenger å designe dine bord og strukturer opp foran - du kan bare begynne å lagre nye verdier.
Ved å fortsette fakturaeksemplet kan enkelte fakturaer inkludere et momsnummer, noen kan ikke. I en RDBMS må du fortelle bordet ditt å først akseptere et momsnummer og da at det muligens kan være null. I NoSQL kan du imidlertid bare lagre fakturaer med eller uten et momsnummer - det er ikke noe skjema. Husk at NoSQL ikke er en sølvkule. Hvis dataene dine er relasjonelle, vil det være riktig å holde fast med RDBMS.
MapReducing har fordeler over SQL-spørringer fordi kartet / redusere oppgaven kan fordeles mellom flere noder, noe som ikke er mulig i RDBMS.
NoSQL databaser bruker kart / redusere for å spørre og indeksere databasen. I RDBMS kjører du en spørring som knytter seg til flere tabeller sammen for å først opprette et datapool og deretter kjører spørringen opprette en resultatsett, en delmengde av de totale dataene. I NoSQL bruker du kart / reduksjon for å opprette en 'visning' (lik en resultat) denne visningen er en del av de samlede dataene.
Kartet utvider i hovedsak data og reduserer dataaggregering. Jo mer kjent du er med RDBMS, jo vanskeligere å gripe kart / redusere vil være. MapReducing fordeler over SQL-spørringer fordi kartet / redusere oppgaven kan fordeles mellom flere noder, noe ikke mulig i RDBMS. Å legge til en ny post i databasen utgjør ikke alltid at kart / redusere oppgaven blir fullstendig omvendt.
Noen få fakta om CouchDB som du burde vite:
CouchDB er en database designet for å kjøre på internett i dag.
CouchDB lar deg skrive et klientsideprogram som snakker direkte til saken uten at det er behov for et mellomstort i server-siden, noe som reduserer utviklings tiden betydelig. Med CouchDB, kan du enkelt håndtere etterspørselen ved å legge til flere repliseringsnoder med letthet. CouchDB lar deg kopiere databasen til klienten din og med filtre kan du til og med kopiere den bestemte brukerens data.
Å ha databasen lagret lokalt betyr at klientsiden din kan kjøre med nesten ingen latens. CouchDB vil håndtere replikering til skyen for deg. Brukerne dine kunne få tilgang til sine fakturaer på mobiltelefonen og gjøre endringer uten merkbar ventetid, alt sammen mens de er offline. Når en tilkobling er til stede og brukbar, vil CouchDB automatisk kopiere disse endringene til Cloud CouchDB.
CouchDB er en database designet for å kjøre på internett i dag for dagens desktop-lignende applikasjoner og de tilkoblede enhetene som vi får tilgang til på internett.
Den enkleste måten å få CouchDB opp og kjører på systemet er å gå til CouchOne og laste ned en CouchDB-distribusjon for OS-OSX i mitt tilfelle. Last ned zip, trekk ut det og slipp CouchDBX i min applikasjonsmappe (instruksjoner for andre OS på CouchOne).
Til slutt, åpne CouchDBX.
Etter at CouchDB har startet, bør du se Futon-kontrollpanelet i CouchDBX-applikasjonen. I tilfelle du ikke kan, kan du få tilgang til Futon via nettleseren din. Ser på loggen, forteller CouchDBX oss CouchDB ble startet på http://127.0.0.1:5984/
(kan være forskjellig på systemet ditt). Åpne en nettleser og gå til http://127.0.0.1:5984/_utils/
og du bør se Futon.
Gjennom resten av denne opplæringen vil jeg bruke Futon i Firefox. Jeg vil også ha Firebug og konsollvisningen åpen for å se alle HTTP-forespørslene Futon sender bak kulissene. Dette er nyttig ettersom søknaden din kan gjøre alt Futon gjør. La oss gå videre og opprette en database som heter mycouchshop
.
Futon bruker faktisk et jQuery-plugin for å samhandle med CouchDB. Du kan se det pluginet på http://127.0.0.1:5984/_utils/script/jquery.couch.js
(Husk at porten din kan være annerledes). Dette gir deg et godt eksempel på interaksjon med CouchDB.
CouchDB, som standard, er helt åpen, noe som gir hver bruker adminrettigheter til forekomsten og alle dens databaser. Dette er flott for utvikling, men åpenbart dårlig for produksjon. La oss gå videre og sette opp en admin. Nederst til høyre ser du "Velkommen til Admin Party! Alle er admin! Løs dette".
Gå videre og klikk fiks dette og gi deg selv et brukernavn og passord. Dette skaper en adminkonto og gir anonyme brukere tilgang til å lese og skrive operasjoner på alle databasene, men ingen konfigurasjonsrettigheter.
I CouchDB ville det være uklokt å lage en enkelt superbruker og få den brukeren til å gjøre alt lese / skrive.
Brukere i CouchDB kan være litt forvirrende å forstå først, spesielt hvis du er vant til å opprette en enkelt bruker for hele programmet og deretter administrere brukere selv i en brukertabell (ikke MySQL-brukerstabellen). I CouchDB ville det være uklokt å skape en enkelt superbruker og få den brukeren til å gjøre alt les / skriv, fordi hvis appen din er klient-siden, vil denne superbrukerens legitimasjon være i klart syn i JavaScript-kildekoden.
CouchDB har brukeropprettelse og autentisering bakket inn. Du kan opprette brukere med jQuery-pluginet ved hjelp av $ .Couch.signup ()
. Disse blir i hovedsak brukerne av systemet ditt. Brukere er bare JSON-dokumenter som alt annet, slik at du kan lagre eventuelle andre attributter du ønsker, for eksempel e-post. Du kan deretter bruke grupper innenfor CouchDB til å kontrollere hvilke dokumenter hver bruker har skrive tilgang til. For eksempel kan du opprette en database for den brukeren som de kan skrive til og deretter legge dem til en gruppe med leseadgang til de andre databasene etter behov.
La oss nå lage vårt første dokument ved hjelp av Futon gjennom følgende trinn:
mycouchshop
database.Gå opp et nivå, tilbake til databasen, og du bør se ett dokument oppført med forrige ID som nøkkel og en verdi som begynner medRev:
. Dette er JSON-dokumentet du nettopp har opprettet.
CouchDB er en tilleggsdatabase - nye oppdateringer legges til databasen og overskriver ikke den gamle versjonen. Hver ny oppdatering til et JSON-dokument med en eksisterende ID vil legge til en ny versjon. Dette er hva den automatisk innsatte revisjonstasten betyr. Følg trinnene nedenfor for å se dette i aksjon:
mycouchshop
database, klikk den eneste platen som er synlig.Etter å ha slått på lagring, bør en ny revisjonstast være synlig med nummer 2. Går tilbake til nivået til mycouchshop
databasevisning, vil du fortsatt se bare ett dokument, dette er den siste revisjonen av produktdokumentet.
Mens CouchDB bruker revisjoner internt, prøv å ikke lene seg på det for mye. Revisjonene kan rengjøres gjennom Futon ganske enkelt, og det er ikke laget for å bli brukt som revisjonskontrollsystem. CouchDB bruker revisjonene som en del av replikasjonsfunksjonaliteten.
Jeg har allerede nevnt at CouchDB bruker et RESTful grensesnitt og eagle eyed leseren ville ha lagt merke til Futon bruker dette via konsollen i Firebug. Hvis du ikke gjorde det, la oss bevise dette ved å sette inn et dokument ved hjelp av cURL via terminalen.
Først, la oss lage et JSON-dokument med innholdet under og lagre det på skrivebordet som ringer filen person.json
.
"fornavn": "Gavin", "etternavn": "Cooper", "type": "person")
neste, åpne terminalen og utfør cd ~ / skrivebord /
sette deg i riktig katalog og deretter utføre innsatsen med krølle -X POST http://127.0.0.1:5984/mycouchshop/ -d @ person.json -H "Content-Type: application / json"
. CouchDB burde ha returnert et JSON-dokument som ligner på det nedenfor.
"Ok": true, "id": "c6e2f3d7f8d0c91ce7938e9c0800131c", "rev": "1-abadd48a09c270047658dbc38dc8a892"
Dette er ID- og revisjonsnummeret til det innsatte dokumentet. CouchDB følger RESTful-konvensjonen og dermed:
Vi kan videre verifisere vår innsats ved å se alle dokumentene i vår mycouchshop
database ved å utføre curl -X GET http://127.0.0.1:5984/mycouchshop/_all_docs
.
Å se alle dokumenter er ganske ubrukelig i praksis. Det som ville være mer ideelt er å se alle produktdokumenter. Følg trinnene nedenfor for å oppnå dette:
funksjon (doc) if (doc.type === "product" && doc.name) emit (doc.name, doc);
Etter å ha opprettet denne enkle kartfunksjonen, kan vi nå be om denne visningen og se innholdet over HTTP ved hjelp av følgende kommando curl -X GET http://127.0.0.1:5984/mycouchshop/_design/products/_view/products
.
En liten ting å legge merke til er hvordan vi får dokumentets ID og revisjon som standard.
For å utføre en nyttig reduksjon, la oss legge til et annet produkt i vår database og legge til et prisattributt med verdien av 1,75 til vårt første produkt.
"navn": "Mitt produkt", "pris": 2,99, "type": "produkt"
For vår nye visning vil vi inkludere en reduksjon så vel som et kart. Først må vi kartlegge definert som nedenfor.
funksjon (doc) if (doc.type === "product" && doc.price) emit (doc.id, doc.price);
Ovennevnte kartfunksjon kontrollerer bare for å se om det innførte dokumentet er et produkt og at det har en pris. Hvis disse betingelsene er oppfylt, sendes produktprisen. Reduksjonsfunksjonen er under.
funksjon (nøkler, priser) returbeløp (priser);
Ovennevnte funksjon tar prisene og returnerer summen ved å bruke en av CouchDBs innebygde reduseringsfunksjoner. Pass på at du sjekker reduksjonsalternativet øverst til høyre i resultattabellen, da du ellers ikke kan se resultatene av reduksjonen. Det kan hende du må gjøre en hardoppdatering på siden for å se reduksjonsalternativet
I denne opplæringen tok vi et kort, men fokusert blikk på CouchDB. Vi så den potensielle kraften til CouchDB og hvor lett det er å komme i gang. Jeg er sikker på at du har mange spørsmål på dette punktet, så vær så snill å chime i nedenfor. Takk så mye for å lese!