NoSQL-buzzwordet har været metastaseret i flere år. Spændingen omkring disse hurtige datalagre har været berusende, og vi er lige så skyldige som nogen for at se den banebrydende appel fra NoSQL. Alligevel nærmer bryllupsrejsen sig til en ende, og det er på tide at begynde at afbalancere vores entusiasme med nogle hårfine øjne.
Misforstå os ikke. Vi kører stadig for at prøve det seneste eksperiment med at opbygge en simpel mekanisme til lagring af data. Vi finder stadig dyb værdi i MongoDB, CouchDB, Cassandra, Riak og andre NoSQL-standouts. Vi planlægger stadig at kaste nogle af vores mest betroede data i disse stakke med kode, fordi de vokser bedre og mere kamptestet hver dag.
[Også på: NoSQL-standouts: Nye databaser til nye applikationer Første kig: Oracle NoSQL-database | Få en fordøjelse af nøglehistorierne hver dag i det daglige nyhedsbrev. ]
Men vi begynder at mærke chafing, da NoSQL-systemerne langt fra er en perfekt pasform og ofte gnider den forkerte vej. De smarteste udviklere vidste dette fra starten. De brændte ikke SQL-manualerne og sendte nastygrams til salgsstyrken hos deres engang hengivne SQL-leverandør. Nej, de smarte NoSQL-udviklere bemærkede simpelthen, at NoSQL stod for "Ikke kun SQL." Hvis masserne fejlagtigt fortalte akronymet, var det deres problem.
Denne liste over greb, store og små, er således et forsøg på at dokumentere denne kendsgerning og rydde luften. Det er meningen at sætte tingene lige nu, så vi kan gøre et bedre job med at forstå kompromiserne og kompromiserne.
NoSQL hård sandhed nr. 1: JOINs betyder konsistens
En af de første greb, som folk har om SQL-systemer, er beregningsomkostningerne ved at udføre en JOIN mellem to tabeller. Ideen er at gemme dataene ét og kun ét sted. Hvis du holder en liste over kunder, placerer du deres gadeadresser i en tabel og bruger deres kunde-id'er i hver anden tabel. Når du trækker dataene, forbinder JOIN ID'erne med adresserne, og alt forbliver konsekvent.
Problemet er, at JOINs kan være dyre, og nogle DBA'er har udtænkt komplekse JOIN-kommandoer, der svirrer sindet og gør selv den hurtigste hardware til slam. Det var ikke overraskende, at NoSQL-udviklerne forvandlede deres mangel på JOINs til en funktion: Lad os bare holde kundens adresse i samme tabel som alt andet! NoSQL-metoden er at gemme nøgleværdipar for hver person. Når tiden kommer, henter du dem alle.
Ak, folk, der ønsker, at deres borde skal være ensartede, har stadig brug for JOINs. Når du først har gemt kundernes adresser med alt andet om dem, ender du ofte med flere kopier af disse adresser i hver tabel. Og når du har flere kopier, skal du opdatere dem alle på samme tid. Nogle gange fungerer det, men når det ikke gør det, er NoSQL ikke klar til at hjælpe med transaktioner.
Vent, siger du, hvorfor ikke have en separat tabel med kundens oplysninger? På den måde vil der kun være én post at ændre. Det er en god idé, men nu skal du skrive JOIN selv i din egen logik.
NoSQL hård sandhed nr. 2: vanskelige transaktioner
Lad os sige, at det er OK for dig at leve uden at deltage i tabeller, fordi du vil have hastigheden. Det er en acceptabel kompromis, og nogle gange afviger SQL DBA'er tabeller af netop denne grund.
Problemet er, at NoSQL gør det svært at holde de forskellige poster konsistente. Der er ofte ingen transaktioner for at sikre, at ændringer til flere tabeller foretages sammen. Til det er du alene, og et nedbrud kan sikre, at tabeller bliver inkonsekvente.
De tidligste NoSQL-implementeringer pegede på næsen ved disse transaktioner. De ville tilbyde datalister, der var konsistente, undtagen når de ikke var det. Med andre ord gik de efter de laveste data, hvor fejl ikke ville gøre nogen væsentlig forskel.
Nu tilbyder nogle NoSQL-implementeringer noget, der nærmer sig en transaktion. Oracles NoSQL-produkt tilbyder for eksempel transaktionskontrol over data, der er skrevet til en node, og giver dig mulighed for at vælge en fleksibel mængde konsistens på tværs af flere noder. Hvis du vil have perfekt konsistens, skal du vente på, at hver skrivning når alle noder. Flere andre NoSQL-datalagre eksperimenterer med at tilføje mere struktur og beskyttelse som denne.
NoSQL hård sandhed nr. 3: Databaser kan være smarte
Mange NoSQL-programmører kan lide at prale af, hvordan deres lette kode og enkle mekanisme fungerer ekstremt hurtigt. De har normalt ret, når opgaverne er så enkle som indersiden af NoSQL, men det ændrer sig, når problemerne bliver sværere.
Overvej den gamle udfordring ved en JOIN. Når NoSQL-programmører begynder at generere deres egne JOIN-kommandoer i deres egen logik, begynder de at forsøge at gøre dette effektivt. SQL-udviklere har brugt årtier på at udvikle sofistikerede motorer til at håndtere JOIN-kommandoer så effektivt som muligt. En SQL-udvikler fortalte mig, at han forsøgte at synkronisere sin kode med den roterende harddisk, så han kun ville anmode om data, når hovedet var lige over det rette sted. Dette kan virke ekstremt, men SQL-udviklere har arbejdet på lignende hacks i årtier.
Der er ingen tvivl om, at programmører bruger dage på at trække håret ud og forsøge at strukturere deres SQL-forespørgsler for at drage fordel af al denne latente intelligens. Det er måske ikke let at trykke på, men når programmøren regner det ud, kan databaserne virkelig synge.
Et sofistikeret forespørgselssprog som SQL har altid potentialet til at overgå et usofistikeret forespørgselssprog som dem, der findes i NoSQL. Det betyder måske ikke noget med enkle resultater, men når handlingen bliver kompleks, udføres SQL på maskinen lige ved siden af dataene. Det har lidt overhead, der henter dataene og udfører arbejdet. En NoSQL-server skal normalt sende dataene, hvor de skal hen.
NoSQL hård sandhed nr. 4: For mange adgangsmodeller
I teorien formodes SQL at være et standardsprog. Hvis du bruger SQL til en database, skal du kunne køre den samme forespørgsel i en anden kompatibel version. Denne påstand fungerer muligvis med et par enkle forespørgsler, men hver DBA ved, at det kan tage år at lære SQL's idiosynkrasier til forskellige versioner af den samme database. Nøgleord omdefineres, og forespørgsler, der arbejdede på en version, fungerer ikke sammen med en anden.
NoSQL er endnu mere uklar. Det er som Babels tårn. Siden starten har NoSQL-udviklere hver forsøgt at forestille sig det bedst mulige sprog, men de har meget forskellige forestillinger. Dette hotbed for eksperimentering er godt - indtil du prøver at springe mellem værktøjer. En forespørgsel til CouchDB udtrykkes som et par JavaScript-funktioner til kortlægning og reduktion. Tidlige versioner af Cassandra brugte en rå API på lavt niveau kaldet Thrift; nyere versioner tilbyder CQL, et SQL-lignende forespørgselssprog, der skal analyseres og forstås af serveren. Hver enkelt er forskellig på sin egen måde.
Hvert værktøj har ikke bare sine egne idiosynkrasier, det har en helt anden filosofi og måde at udtrykke det på. Der er ingen nemme måder at skifte mellem datalagre, og du efterlader ofte at skrive masser af limkode bare for at give dig selv mulighed for at skifte i fremtiden. Dette er muligvis ikke for svært, når du fylder par nøgler og værdier ind i systemet, men det kan vokse i stigende grad, jo mere kompleksitet du introducerer.
NoSQL-hård sandhed nr. 5: Skema-fleksibilitet er problemer med at vente på at ske
En af de store ideer fra NoSQL-modellen kræver ikke et skema. Med andre ord behøver programmører ikke på forhånd at bestemme, hvilke kolonner der vil være tilgængelige for hver række i en tabel. En post kan have 20 strenge knyttet til sig, en anden kan have 12 heltal, og en anden kan være helt tom. Programmørerne kan træffe beslutningen, når de har brug for at gemme noget. De behøver ikke at spørge DBA om tilladelse, og de behøver ikke udfylde alt papirarbejde for at tilføje en ny kolonne.
Al den frihed lyder berusende, og i de rigtige hænder kan den fremskynde udviklingen. Men er det virkelig en god idé for en database, der muligvis lever gennem tre team af udviklere? Er det endda brugbart til en database, der kan vare længere end seks måneder?
Med andre ord vil udviklerne måske have friheden til at kaste ethvert gammelt par i en database, men vil du være den femte udvikler, der kommer efter at fire har valgt deres egne nøgler? Det er let at forestille sig en række repræsentationer af "fødselsdag", hvor hver udvikler vælger sin egen repræsentation som en nøgle, når han føjer en brugers fødselsdag til en post. Et team af udviklere kan forestille sig næsten alt: "bday", "b-day", "fødselsdag".
NoSQL-strukturen giver ingen understøttelse for at begrænse dette problem, fordi det ville betyde at man forestiller sig skemaet igen. Det ønsker ikke at skade den bløde af de helt seje udviklere. Et skema ville komme i vejen.
Faktum er, at det ikke er en stor ting at tilføje en kolonne til en tabel, og disciplinen kan faktisk være god for udvikleren. Ligesom det hjælper med at tvinge udviklere til at udpege variable typer, hjælper det også med at tvinge udviklere til at udpege den type data, der er knyttet til en kolonne. Ja, DBA kan tvinge udvikleren til at udfylde en formular i tre eksemplarer inden vedhæftning af den kolonne, men det er ikke så slemt som at beskæftige sig med et halvt dusin forskellige nøgler oprettet i farten af en programmør.
NoSQL hård sandhed nr. 6: Ingen ekstra
Lad os sige, at du ikke vil have alle dataene i alle rækkerne, og du vil have summen af en enkelt kolonne. SQL-brugere kan udføre en forespørgsel med SUM-operationen og sende et - kun et - nummer tilbage til dig.
NoSQL-brugere får alle data sendt tilbage til dem og kan derefter selv foretage tilføjelsen. Tilføjelsen er ikke problemet, fordi det tager omtrent samme tid at tilføje numrene på enhver maskine. Imidlertid er forsendelse af dataene langsom, og båndbredden, der kræves for at sende alle disse data, kan være dyr.
Der er få ekstra i NoSQL-databaser. Hvis du vil gøre andet end at gemme og hente data, vil du sandsynligvis gøre det selv. I mange tilfælde vil du gøre det på en anden maskine med en komplet kopi af dataene. Det virkelige problem er, at det ofte kan være nyttigt at udføre al beregning på maskinen, der indeholder dataene, fordi afsendelse af data tager tid. Men hårdt for dig.
NoSQL-løsninger dukker op. Map and Reduce-forespørgselsstrukturen fra MongoDB giver dig vilkårlig JavaScript-struktur til kogning af dataene. Hadoop er en kraftfuld mekanisme til distribution af beregning i hele stakken af maskiner, der også indeholder dataene. Det er en hurtigt udviklende struktur, der tilbyder hurtigt forbedrede værktøjer til opbygning af sofistikeret analyse. Det er meget sejt, men stadig nyt. Og teknisk set er Hadoop et helt andet buzzword end NoSQL, selvom forskellen mellem dem er ved at falme.
NoSQL hård sandhed nr. 7: Færre værktøjer
Sikker på, du kan få din NoSQL til at køre på din server. Sikker på, du kan skrive din egen brugerdefinerede kode for at skubbe og trække dine data fra stakken. Men hvad hvis du vil gøre mere? Hvad hvis du vil købe en af de smarte rapporteringspakker? Eller en tegningspakke? Eller for at downloade nogle open source-værktøjer til oprettelse af diagrammer?
Beklager, de fleste af værktøjerne er skrevet til SQL-databaser. Hvis du vil generere rapporter, oprette grafer eller gøre noget med alle dataene i din NoSQL-stak, skal du begynde at kode. Standardværktøjerne er klar til at snappe data fra Oracle, Microsoft SQL, MySQL og Postgres. Dine data er i NoSQL? De arbejder på det.
Og de vil arbejde på det lidt. Selvom de springer gennem alle bøjlerne for at komme i gang med en af NoSQL-databaser, bliver de nødt til at starte forfra fra starten for at håndtere det næste system. Der er mere end 20 forskellige NoSQL-valg, som alle har deres egen filosofi og deres egen måde at arbejde med dataene på. Det var svært nok for værktøjsfabrikanterne at understøtte idiosynkrasier og inkonsekvenser i SQL, men det er endnu mere kompliceret at få værktøjerne til at fungere med enhver NoSQL-tilgang.
Dette er et problem, der langsomt forsvinder. Udviklerne kan mærke spændingen i NoSQL, og de vil ændre deres værktøjer til at arbejde med disse systemer, men det vil tage tid. Måske starter de på MongoDB, hvilket ikke hjælper dig, fordi du kører Cassandra. Standarder hjælper i situationer som denne, og NoSQL er ikke stor på standarder.
NoSQL mangler i en nøddeskal
Alle disse NoSQL-mangler kan reduceres til en enkelt erklæring: NoSQL smider funktionalitet væk for hastighed. Hvis du ikke har brug for funktionaliteten, har du det godt, men hvis du har brug for det i fremtiden, vil du være ked af det.
Revolutioner er endemiske i teknologikulturen. En ny gruppe kommer og undrer sig over, hvorfor den sidste generation byggede noget så kompliceret, og de satte sig for at nedbryde de gamle institutioner. Efter lidt begynder de at indse, hvorfor alle de gamle institutioner var så komplekse, og de begynder at implementere funktionerne igen.
Vi ser dette i NoSQL-verdenen, da nogle af projekterne begynder at tilføje ting, der ligner transaktioner, skemaer og standarder. Dette er fremskridtets natur. Vi river kun tingene ned for at opbygge dem igen. NoSQL er færdig med den første fase af revolutionen, og nu er det tid til den anden. Kongen er død. Længe leve kongen.
Relaterede artikler
- NoSQL-standouts: Nye databaser til nye applikationer
- Første kig: Oracle NoSQL-database
- Fleksibel NoSQL: MongoDB i gennemgang
- 10 vigtige præstationstip til MySQL
- 10 vigtige MySQL-værktøjer til administratorer
- Master MySQL i Amazon skyen
- Tiden til NoSQL-standarder er nu
Denne historie, "7 hårde sandheder om NoSQL-revolutionen", blev oprindeligt offentliggjort på .com. Følg den seneste udvikling inden for datastyring på .com. For at få den nyeste udvikling inden for nyheder inden for forretningsteknologi, følg .com på Twitter.
