Den artiga tolkningen av "NoSQL" har blivit Not Only SQL . Om du har data som verkligen är relationella, eller om din funktionalitet beror på saker som joins och ACIDity, bör du lagra dessa data på ett relationellt sätt. I det här inlägget kommer jag att förklara hur jag använder MySQL tillsammans med två NoSQL-datalager. Modern datalagring i webbskala handlar om att förstå hur man väljer de bästa verktygen för jobbet/jobben.
Som sagt, NoSQL är verkligen en reaktion på att den relationella metoden och sättet att tänka har tillämpats på problem där det faktiskt inte passar särskilt bra (typiskt enorma tabeller med tiotals miljoner rader eller mer). När tabellerna väl blir så stora har den typiska SQL "bästa praxis" varit att manuellt skära data -- det vill säga att sätta posterna 1 till 10 000 000 i tabell A, 10 000 001 till 20 000 001 i tabell B, och så vidare. Sedan, vanligtvis i applikationsmodelllagret, utförs uppslagningarna enligt detta schema. Det här är vad som kallas application-aware skalning. Det är tidskrävande och felbenäget, men för att skala upp något och samtidigt behålla MySQL för långbordsbutiken har det blivit en mer eller mindre standard MO. NoSQL representerar, för mig, den application-unaware alternativ.
Nyckel-värde
När jag fick en MySQL-prototyp att börja bli för stor för sitt eget bästa flyttade jag personligen så mycket data som möjligt till den blixtsnabba membase , som överträffar Memcached och ger uthållighet. Membase är ett distribuerat nyckel-värdelager som skalas mer eller mindre linjärt (Zynga använder det för att hantera en halv miljon operationer per sekund, till exempel) genom att lägga till fler råvaruservrar i ett kluster -- det är därför bra em> passar molnåldern Amazon EC2 , Joyent , etc.
Det är välkänt att distribuerade nyckelvärdebutiker är det bästa sättet att få enorm, linjär skala. Svagheten med nyckel-värde är frågebarhet och indexering. Men även i relationsvärlden är den bästa praxisen för skalbarhet att lägga så mycket ansträngning på applikationsservrarna som möjligt, göra anslutningar i minnet på varuappservrar istället för att be det centrala RDB-klustret att hantera all den logiken. Eftersom simple select plus application logic är verkligen det bästa sättet att uppnå massiv skala även på MySQL, övergången till något som Membase (eller dess konkurrenter som Riak
) är egentligen inte så illa.
Dokumentbutiker
Ibland – även om jag skulle hävda mer sällan än många tror – kräver en applikations design i sig sekundära index, frågebarhet i intervall, etc. NoSQL-metoden för detta är genom ett document store gillar MongoDB
. Liksom Membase är Mongo mycket bra i vissa områden där relationsdatabaser är särskilt svaga, som application-unaware skalning, auto-sharding , och maintaining flat response times even as dataset size balloons . Det är betydligt långsammare än Membase och lite knepigare att göra ren horisontell skala, men fördelen är att det är mycket frågetecken. Du kan fråga efter parametrar och intervall i realtid, eller så kan du använda Map/Reduce för att utföra komplexa batchoperationer på verkligt enorma datamängder.
I samma projekt som jag nämnde ovan, som använder Membase för att servera massor av live spelardata, använder vi MongoDB för att lagra analytics/metrics-data, vilket verkligen är där MongoDB lyser.
Varför ska man behålla saker i SQL
Jag berörde kort det faktum att "verkligt relationell" information bör finnas i relationsdatabaser. Som kommentatorn Dan K. påpekar missade jag delen där jag diskuterade nackdelarna med att lämna RDBMS, eller åtminstone att lämna det helt.
För det första finns SQL i sig. SQL är välkänt och har varit en industristandard under lång tid. Vissa "NoSQL"-databaser som Googles App Engine
Datastore (byggd på Big Table) implementerar sitt eget SQL-liknande språk (Googles kallas, sött, GQL för Google Query Language ). MongoDB tar ett nytt förhållningssätt till frågeproblemet med sina förtjusande JSON-frågeobjekt
. Ändå är SQL i sig ett kraftfullt verktyg för att få ut information ur data, vilket ofta är hela poängen med databaser till att börja med.
Den viktigaste anledningen till att stanna kvar med RDBMS är ACID
, eller Atomicity, Consistency, Isolation, Durability . Jag kommer inte att omhasha tillståndet för Acid-NoSQL, eftersom det är väl adresserat i det här inlägget
på SO. Det räcker med att säga att det finns en rationell anledning till Oracles RDBMS
har en så enorm marknad som inte är på väg någonstans:vissa data behöver ren ACID-kompatibilitet . Om din data gör det (och om den gör det, är du förmodligen väl medveten om det), så gör din databas det också. Behåll den pH
låg!
Redigera: Kolla in Aaronaughts inlägg här. Han representerar business-to-business-perspektivet mycket bättre än jag kunde, delvis för att jag har tillbringat hela min karriär inom konsumentområdet.