Kjennetegn på NoSQL-databaser

2.1 Fremveksten av begrepet NoSQL

Nylig har begrepet "NoSQL" blitt veldig fasjonabelt og populært, alle slags programvareløsninger blir aktivt utviklet og promotert under dette tegnet. NoSQL har blitt synonymt med enorme mengder data, lineær skalerbarhet, klynger, feiltoleranse, ikke-relasjonalitet. Det er imidlertid få som har en klar forståelse av hva NoSQL-lagring er, hvordan begrepet dukket opp og hvilke fellestrekk de har. La oss prøve å fylle dette gapet.

Det mest interessante med begrepet er at til tross for at det først ble brukt på slutten av 90-tallet, fikk det reell betydning i den formen det brukes nå i midten av 2009. I utgangspunktet var dette navnet på en åpen -kildedatabase laget av Carlo Strozzi, som lagret alle data som ASCII-filer og brukte shell-skript i stedet for SQL for å få tilgang til dataene. Det hadde ingenting å gjøre med "NoSQL" i sin nåværende form.

I juni 2009 arrangerte Johan Oskarsson et møte i San Francisco for å diskutere nye trender i IT-lagrings- og prosesseringsmarkedet. Den viktigste drivkraften for møtet var nye åpen kildekode-produkter som BigTable og Dynamo. For et lyst tegn for et møte var det nødvendig å finne et romslig og kortfattet begrep som passet perfekt inn i Twitter-hashtaggen. Et av disse begrepene ble foreslått av Eric Evans fra RackSpace - "NoSQL". Begrepet var planlagt for bare ett møte og hadde ikke en dyp semantisk belastning, men det hendte at det spredte seg over hele det globale nettverket som en viral reklame og ble de facto navnet på en hel retning i IT-bransjen. Forresten talte Voldemort (Amazon Dynamo-klon), Cassandra, Hbase (analoger av Google BigTable), Hypertable, CouchDB, MongoDB på konferansen.

Det er verdt å understreke nok en gang at begrepet «NoSQL» er helt spontant opphav og ikke har en allment akseptert definisjon eller vitenskapelig institusjon bak seg. Dette navnet karakteriserer snarere vektoren for IT-utvikling bort fra relasjonsdatabaser. Det står for Not Only SQL, selv om det er tilhengere av den direkte definisjonen av No SQL. Pramod Sadalaj og Martin Fowler prøvde å gruppere og systematisere kunnskap om NoSQL-verdenen i sin ferske bok "NoSQL Distillered".

2.2 Grunnleggende egenskaper ved NoSQL-databaser

Det er få fellestrekk for all NoSQL, siden mange heterogene systemer nå er skjult under NoSQL-etiketten (kanskje den mest komplette listen finnes på http://nosql-database.org/). Mange egenskaper er særegne bare for visse NoSQL-databaser, jeg vil definitivt nevne dette ved oppføring.

1. Ingen SQL brukes

Jeg mener ANSI SQL DML, siden mange databaser prøver å bruke spørringsspråk som ligner på den velkjente favorittsyntaksen, men ingen har klart å implementere det fullt ut og det er usannsynlig at de vil lykkes. Selv om det ryktes om startups som prøver å implementere SQL, for eksempel i hadup ( http://www.drawntoscalehq.com/ og http://www.hadapt.com/ ).

2. Ustrukturert (uten skjema)

Meningen er at i NoSQL-databaser, i motsetning til relasjonsdatabaser, er ikke datastrukturen regulert (eller svakt skrevet, hvis vi trekker analogier med programmeringsspråk) - du kan legge til et vilkårlig felt i en egen linje eller dokument uten først å endre strukturen deklarativt. av hele bordet. Derfor, hvis det er behov for å endre datamodellen, er den eneste tilstrekkelige handlingen å gjenspeile endringen i applikasjonskoden.

For eksempel, når du gir nytt navn til et felt i MongoDB:

BasicDBObject order = new BasicDBObject();
order.put("date", orderDate); // this field was a long time ago
order.put("totalSum", total); // before we just used "sum"

Hvis vi endrer applikasjonslogikken, så forventer vi et nytt felt også ved lesing. Men på grunn av mangelen på et dataskjema, mangler totalSum-feltet fra andre allerede eksisterende Order-objekter. I denne situasjonen er det to alternativer for videre handling.

Den første er å gjennomsøke alle dokumenter og oppdatere dette feltet i alle eksisterende dokumenter. På grunn av datavolumet skjer denne prosessen uten noen låser (sammenlignbar med kommandoen endre tabell endre navn på kolonne), så under oppdateringen kan allerede eksisterende data leses av andre prosesser. Derfor er det andre alternativet - å sjekke inn applikasjonskoden - uunngåelig:

BasicDBObject order = new BasicDBObject();
Double totalSum = order.getDouble("sum"); // This is the old model
if (totalSum  == null)
totalSum = order.getDouble("totalSum"); // This is the updated model

Og allerede når vi tar opp på nytt, vil vi skrive dette feltet til databasen i et nytt format.

En hyggelig konsekvens av fraværet av et skjema er effektiviteten av å jobbe med sparsomme data. Hvis ett dokument har et date_published-felt, og det andre ikke har det, vil det ikke opprettes et tomt date_published-felt for det andre. Dette er i prinsippet logisk, men et mindre åpenbart eksempel er NoSQL-databaser i kolonnefamilien, som bruker de kjente begrepene tabeller/kolonner. På grunn av mangelen på et skjema er kolonner imidlertid ikke deklarativt deklarert og kan endres/legges til under en brukers databaseøkt. Dette tillater spesielt bruk av dynamiske kolonner for implementering av lister.

Det ustrukturerte skjemaet har sine ulemper - i tillegg til de ovennevnte overheadene i applikasjonskoden ved endring av datamodellen - fraværet av alle slags restriksjoner fra basen (ikke null, unik, sjekkbegrensning, etc.), pluss det er ytterligere vanskeligheter med å forstå og kontrollere strukturdataene når du arbeider med databasen for forskjellige prosjekter parallelt (det er ingen ordbøker på siden av databasen). Men i en moderne verden i rask endring er slik fleksibilitet fortsatt en fordel. Et eksempel er Twitter, som for fem år siden, sammen med tweeten, bare lagret litt ekstra informasjon (tid, Twitter-håndtak og noen flere byte med metainformasjon), men nå, i tillegg til selve meldingen, noen flere kilobyte med metadata lagres i databasen.

(Heretter snakker vi hovedsakelig om nøkkelverdi-, dokument- og kolonnefamiliedatabaser, grafdatabaser har kanskje ikke disse egenskapene)

2.3. Representasjon av data i form av aggregater (aggregater)

I motsetning til relasjonsmodellen, som lagrer applikasjonens logiske forretningsenhet i ulike fysiske tabeller for normaliseringsformål, opererer NoSQL-butikker på disse enhetene som helhetlige objekter:

Dette eksemplet viser aggregeringer for en standard konseptuell relasjonsmodell for e-handel "Ordre - Ordrevarer - Betalinger - Produkt". I begge tilfeller kombineres bestillingen med posisjoner til ett logisk objekt, mens hver posisjon lagrer en lenke til produktet og noen av dets attributter, for eksempel navnet (en slik denormalisering er nødvendig for ikke å be om et produktobjekt ved henting en ordre - hovedregelen for distribuerte systemer er "sammenføyninger" mellom objekter). I ett aggregat kombineres betalinger med bestillingen og er en integrert del av objektet, i det andre plasseres de i et eget objekt. Dette demonstrerer hovedregelen for å designe en datastruktur i NoSQL-databaser - den må følge kravene til applikasjonen og optimaliseres så mye som mulig for de hyppigste forespørslene.

Mange vil protestere, og bemerker at arbeid med store, ofte denormaliserte, objekter er fulle av mange problemer når man prøver vilkårlige søk på data når søk ikke passer inn i strukturen til aggregater. Hva om vi bruker bestillinger sammen med ordrelinjer og betalinger (slik fungerer appen), men bedriften ber oss telle hvor mange enheter av et bestemt produkt som ble solgt forrige måned? I dette tilfellet, i stedet for å skanne OrderItem-tabellen (i tilfelle av en relasjonsmodell), vil vi måtte hente hele ordrene i NoSQL-lagring, selv om vi ikke trenger mye av denne informasjonen. Dessverre er dette et kompromiss som må inngås i et distribuert system: vi kan ikke normalisere data som i et konvensjonelt enkeltserversystem,

Jeg prøvde å gruppere fordeler og ulemper ved begge tilnærmingene i en tabell: