2.1 Fremkomsten af udtrykket NoSQL
For nylig er udtrykket "NoSQL" blevet meget moderigtigt og populært, alle former for softwareløsninger bliver aktivt udviklet og promoveret under dette tegn. NoSQL er blevet synonymt med enorme mængder data, lineær skalerbarhed, klynger, fejltolerance, ikke-relationalitet. Det er dog de færreste, der har en klar forståelse af, hvad NoSQL-lagring er, hvordan udtrykket opstod, og hvilke fælles karakteristika de har. Lad os prøve at udfylde dette hul.
Det mest interessante ved begrebet er, at på trods af, at det først blev brugt i slutningen af 90'erne, fik det først reel betydning i den form, det bruges i nu i midten af 2009. I starten var dette navnet på en åben -kildedatabase oprettet af Carlo Strozzi, som lagrede alle data som ASCII-filer og brugte shell-scripts i stedet for SQL for at få adgang til dataene. Det havde intet at gøre med "NoSQL" i sin nuværende form.
I juni 2009 arrangerede Johan Oskarsson et møde i San Francisco for at diskutere nye tendenser på markedet for it-lagring og -behandling. Den vigtigste drivkraft for mødet var nye open source-produkter som BigTable og Dynamo. For et lyst tegn til et møde var det nødvendigt at finde et rummeligt og kortfattet udtryk, der ville passe perfekt ind i Twitter-hashtagget. Et af disse udtryk blev foreslået af Eric Evans fra RackSpace - "NoSQL". Udtrykket var planlagt til kun et møde og havde ikke en dyb semantisk belastning, men det skete, at det spredte sig over hele det globale netværk som en viral reklame og blev de facto navnet på en hel retning i it-branchen. Forresten talte Voldemort (Amazon Dynamo-klon), Cassandra, Hbase (analoger af Google BigTable), Hypertable, CouchDB, MongoDB på konferencen.
Det er værd at understrege endnu en gang, at begrebet "NoSQL" er fuldstændig spontant og ikke har en almindeligt accepteret definition eller videnskabelig institution bag sig. Dette navn karakteriserer snarere vektoren for IT-udvikling væk fra relationelle databaser. Det står for Not Only SQL, selvom der er tilhængere af den direkte definition af No SQL. Pramod Sadalaj og Martin Fowler forsøgte at gruppere og systematisere viden om NoSQL-verdenen i deres nylige bog "NoSQL Distillered".
2.2 Grundlæggende egenskaber ved NoSQL-databaser
Der er få fælles karakteristika for alle NoSQL, da mange heterogene systemer nu er skjult under NoSQL-etiketten (den måske mest komplette liste kan findes på http://nosql-database.org/). Mange karakteristika er kun ejendommelige for visse NoSQL-databaser, jeg vil helt sikkert nævne dette, når jeg noterer dem.
1. Der bruges ingen SQL
Jeg mener ANSI SQL DML, da mange databaser forsøger at bruge forespørgselssprog svarende til den velkendte yndlingssyntaks, men ingen har formået at implementere det fuldt ud, og det er usandsynligt, at det lykkes. Selvom der er rygter om startups, der forsøger at implementere SQL, for eksempel i hadup ( http://www.drawntoscalehq.com/ og http://www.hadapt.com/ ).
2. Ustruktureret (skemaløs)
Meningen er, at i NoSQL-databaser, i modsætning til relationsdatabaser, er datastrukturen ikke reguleret (eller svagt indtastet, hvis vi drager analogier med programmeringssprog) - du kan tilføje et vilkårligt felt i en separat linje eller dokument uden først at ændre strukturen deklarativt. af hele bordet. Så hvis der er behov for at ændre datamodellen, så er den eneste tilstrækkelige handling at afspejle ændringen i applikationskoden.
For eksempel, når du omdøber 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 ændrer applikationslogikken, så forventer vi et nyt felt også ved læsning. Men på grund af manglen på et dataskema mangler totalSum-feltet fra andre allerede eksisterende Order-objekter. I denne situation er der to muligheder for yderligere handling.
Den første er at gennemgå alle dokumenter og opdatere dette felt i alle eksisterende dokumenter. På grund af mængden af data foregår denne proces uden nogen låse (sammenlignelig med kommandoen alter table rename column), så under opdateringen kan allerede eksisterende data læses af andre processer. Derfor er den anden mulighed - at tjekke applikationskoden - uundgå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 modelOg allerede når vi optager igen, vil vi skrive dette felt til databasen i et nyt format.
En behagelig konsekvens af fraværet af et skema er effektiviteten af at arbejde med sparsomme data. Hvis et dokument har et date_published-felt, og det andet ikke har, vil der ikke blive oprettet et tomt date_published-felt for det andet. Dette er i princippet logisk, men et mindre oplagt eksempel er NoSQL-databaser i kolonnefamilien, som bruger de velkendte begreber tabeller/kolonner. Men på grund af manglen på et skema er kolonner ikke erklæret deklarativt og kan ændres/tilføjes under en brugers databasesession. Dette tillader især brugen af dynamiske kolonner til implementering af lister.
Det ustrukturerede skema har sine ulemper - ud over de ovennævnte overhead i applikationskoden ved ændring af datamodellen - fraværet af alle slags restriktioner fra basen (ikke null, unik, check constraint osv.), plus der er yderligere vanskeligheder med at forstå og kontrollere strukturdataene, når man arbejder med databasen for forskellige projekter parallelt (der er ingen ordbøger på siden af databasen). Men i en moderne verden i hastig forandring er en sådan fleksibilitet stadig en fordel. Et eksempel er Twitter, som for fem år siden, sammen med tweetet, kun gemte lidt ekstra information (tid, Twitter-håndtag og et par flere bytes meta-information), men nu, udover selve beskeden, nogle flere kilobytes metadata er gemt i databasen.
(Herefter taler vi hovedsageligt om nøgleværdi-, dokument- og kolonnefamiliedatabaser, grafdatabaser har muligvis ikke disse egenskaber)
2.3. Repræsentation af data i form af aggregater (aggregater)
I modsætning til den relationelle model, som gemmer applikationens logiske forretningsenhed i forskellige fysiske tabeller til normaliseringsformål, opererer NoSQL-butikker på disse entiteter som holistiske objekter:
Dette eksempel viser sammenlægninger for en standard e-handels konceptuel relationsmodel "Ordre - Ordrevarer - Betalinger - Produkt". I begge tilfælde kombineres ordren med positioner til ét logisk objekt, mens hver position gemmer et link til produktet og nogle af dets attributter, for eksempel navnet (en sådan denormalisering er nødvendig for ikke at anmode om et produktobjekt ved hentning en ordre - hovedreglen for distribuerede systemer er "joins" mellem objekter). I det ene aggregat kombineres betalinger med ordren og er en integreret del af objektet, i det andet placeres de i et separat objekt. Dette demonstrerer hovedreglen for at designe en datastruktur i NoSQL-databaser - den skal overholde kravene i applikationen og optimeres så meget som muligt til de hyppigste anmodninger.
Mange vil protestere og bemærke, at arbejdet med store, ofte denormaliserede objekter er fyldt med adskillige problemer, når man prøver vilkårlige forespørgsler på data, når forespørgsler ikke passer ind i strukturen af aggregater. Hvad hvis vi bruger ordrer sammen med ordrelinjeposter og betalinger (det er sådan, appen fungerer), men virksomheden beder os om at tælle, hvor mange enheder af et bestemt produkt, der blev solgt i sidste måned? I dette tilfælde, i stedet for at scanne OrderItem-tabellen (i tilfælde af en relationel model), bliver vi nødt til at hente hele ordrerne i NoSQL-lager, selvom vi ikke har brug for meget af denne information. Desværre er dette et kompromis, der skal indgås i et distribueret system: vi kan ikke normalisere data som i et konventionelt enkeltserversystem,
Jeg forsøgte at gruppere fordele og ulemper ved begge tilgange i en tabel:
