Den høflige fortolkning af "NoSQL" er blevet Not Only SQL . Hvis du har data, der virkelig er relationelle, eller hvis din funktionalitet afhænger af ting som joins og ACIDity, så bør du gemme disse data på en relationel måde. I dette indlæg vil jeg forklare, hvordan jeg bruger MySQL sammen med to NoSQL-datalagre. Moderne, web-skala datalagring handler om at forstå, hvordan man vælger det eller de bedste værktøj(er) til jobbet(erne).
Når det er sagt, er NoSQL virkelig en reaktion på, at den relationelle metode og måde at tænke på er blevet anvendt på problemer, hvor det faktisk ikke passer særlig godt (typisk enorme tabeller med titusinder af millioner rækker eller mere). Når tabeller bliver så store, har den typiske SQL "bedste praksis" været at manuelt shard dataene -- det vil sige at sætte post 1 til 10.000.000 i tabel A, 10.000.001 til 20.000.001 i tabel B og så videre. Derefter udføres opslagene typisk i applikationsmodellaget i henhold til dette skema. Det er det, der kaldes application-aware skalering. Det er tidskrævende og udsat for fejl, men for at skalere noget op og samtidig bevare MySQL til langbordsbutikken, er det blevet en mere eller mindre standard MO. NoSQL repræsenterer for mig den application-unaware alternativ.
Nøgle-værdi
Da jeg fik en MySQL-prototype begynde at blive for stor til dets eget bedste, flyttede jeg personligt så meget data som muligt til den lynhurtige membase , som overgår Memcached og tilføjer vedholdenhed. Membase er et distribueret nøgleværdilager, der skaleres mere eller mindre lineært (Zynga bruger det til at håndtere en halv million operationer pr. sekund, for eksempel) ved at tilføje flere råvareservere til en klynge -- det er derfor en god em> egnet til cloud-alderen Amazon EC2 , Joyent osv.
Det er velkendt, at distribuerede nøgleværdibutikker er den bedste måde at få enorm, lineær skala på. Svagheden ved nøgleværdi er forespørgsel og indeksering. Men selv i den relationelle verden er den bedste praksis for skalerbarhed at aflaste så meget indsats på applikationsserverne som muligt ved at lave joins i hukommelsen på råvareappservere i stedet for at bede den centrale RDB-klynge om at håndtere al den logik. Siden simple select plus application logic er virkelig den bedste måde at opnå massiv skala selv på MySQL, overgangen til noget som Membase (eller dets konkurrenter som Riak
) er egentlig ikke så dårligt.
Dokumentbutikker
Nogle gange – selvom jeg vil hævde sjældnere end mange tror – kræver et programs design i sagens natur sekundære indekser, intervalforespørgsel osv. NoSQL-tilgangen til dette er gennem et document store synes godt om MongoDB
. Ligesom Membase er Mongo meget god på nogle områder, hvor relationsdatabaser er særligt svage, såsom application-unaware skalering, auto-sharding , og maintaining flat response times even as dataset size balloons . Det er betydeligt langsommere end Membase og en smule vanskeligere at lave ren horisontal skala, men fordelen er, at det er meget forespørgselsvenligt. Du kan forespørge på parametre og områder i realtid, eller du kan bruge Kort/Reducer til at udføre komplekse batch-operationer på virkelig enorme datasæt.
På det samme projekt, som jeg nævnte ovenfor, som bruger Membase til at servere tonsvis af live spillerdata, bruger vi MongoDB til at gemme analytics/metrics-data, hvilket virkelig er der, hvor MongoDB skinner.
Hvorfor beholde tingene i SQL
Jeg kom kort ind på, at 'virkelig relationel' information bør forblive i relationelle databaser. Som kommentator Dan K. påpeger, gik jeg glip af den del, hvor jeg diskuterer ulemperne ved at forlade RDBMS, eller i det mindste ved at forlade det helt.
For det første er der SQL selv. SQL er velkendt og har været en industristandard i lang tid. Nogle "NoSQL"-databaser som Googles App Engine
Datastore (bygget på Big Table) implementerer deres eget SQL-lignende sprog (Googles kaldes, sødt, GQL for Google Query Language ). MongoDB tager en ny tilgang til forespørgselsproblemet med dets dejlige JSON-forespørgselsobjekter
. Alligevel er SQL i sig selv et kraftfuldt værktøj til at få information ud af data, hvilket ofte er hele pointen med databaser til at begynde med.
Den vigtigste grund til at blive hos RDBMS er ACID
, eller Atomicity, Consistency, Isolation, Durability . Jeg vil ikke genhash tilstanden af Acid-NoSQL, da den er veladresseret i dette indlæg
på SO. Det er tilstrækkeligt at sige, at der er en rationel grund til Oracles RDBMS
har et så stort marked, der ikke kommer nogen vegne:nogle data kræver ren ACID-overholdelse . Hvis dine data gør det (og hvis det gør, er du sikkert godt klar over det faktum), så gør din database det også. Behold den pH
lav!
Rediger: Se Aaronaughts indlæg her. Han repræsenterer business-to-business-perspektivet langt bedre, end jeg kunne, til dels fordi jeg har brugt hele min karriere i forbrugerområdet.