Das Prinzip von NoSQL („Not only SQL“) kam zum ersten Mal Ende der 2000er Jahre auf und bezeichnet ganz allgemein alle Datenbanken, die Daten nicht in relationalen Tabellen speichern und deren Abfragesprache nicht SQL ist. NoSQL-Datenbanken ermöglichen eine flexiblere und skalierbarere Datenverwaltung, indem sie andere Speicherstrukturen und Abfrageformate verwenden. Die bekanntesten Beispiele von NoSQL-Datenbanken, neben MongoDB, sind Apache Cassandra, Redis oder Neo4j.

Im Gegensatz zu traditionellen relationalen Datenbanken, die auf feste Tabellenstrukturen und SQL als Abfragesprache setzen, ermöglichen NoSQL-Datenbanken eine höhere Skalierbarkeit, da sie auch über verschiedene Systeme und Rechner verteilt werden können.

Sie sind auch in der Lage, unstrukturierte und semi-strukturierte Daten effizient zu speichern und abzufragen, was für moderne Anwendungen, die oft mit großen Mengen an unstrukturierten Daten zu tun haben, von Vorteil ist. Darüber hinaus sind die meisten Lösungen Open-Source verfügbar und ermöglichen Datenbankabfragen, die relationale Systeme nicht abdecken könnten.

Definiton:

Unter NoSQL wird eine neue Generation von Datenbanksystemen verstanden, die meistens einige der nachfolgenden Punkte berücksichtigen:

1. Das zugrundeliegende Datenmodell ist nicht relational.
2. Die Systeme sind von Anbeginn an auf eine verteilte und horizontale Skalierbarkeit ausgerichtet.
3. Das NoSQL-System ist Open Source.
4. Das System ist schemafrei oder hat nur schwächere Schemarestriktionen.
5. Aufgrund der verteilten Architektur unterstützt das System eine einfache Datenreplikation.
6. Das System bietet eine einfache API.
7. Dem System liegt meistens auch ein anderes Konsistenzmodell zugrunde: Eventually Consistent und BASE, aber nicht ACID.

Historie

NoSQL-Systeme sind Datenbanken, die sich von der relationalen SQL-Philosophie der leistungsstarken RDBMS-Systeme unterscheiden. Sie haben ihre Wurzeln in den frühen 1980er Jahren mit Systemen wie DBM, Lotus Notes und BerkeleyDB. Der Begriff “NoSQL” wurde erstmals 1998 verwendet, aber der eigentliche Aufschwung begann mit dem Web 2.0 und dem Versuch, große Datenmengen zu verarbeiten. Google hat mit seinen Ansätzen wie Map/Reduce und BigTable-Datenbanksystem eine führende Rolle bei der Entwicklung von NoSQL gespielt. Von 2006 bis 2009 entstanden dann die heutigen klassischen NoSQL-Systeme wie HBase/Hypertable, CouchDB, Cassandra, Voldemort, Dynamo/Dynomite, MongoDB, Redis und Riak. Der Begriff “NoSQL” selbst tauchte erstmals in einem Weblog von Eric Evans im Mai 2009 auf.

Kategorien von NoSQL-Datenbanksystemen

Die NoSQL-Systeme sind eine Gruppe von Datenbanken, die sich gegen die Dominanz von relationalen (SQL) Datenbanksystemen richtet. Es gibt über 100 verschiedene Arten von NoSQL-Systemen, die in die Kategorien Kern-NoSQL-Systeme (Core) und nachgelagerte (Soft-)NoSQL-Systeme unterteilt sind.

Die Kern-NoSQL-Systeme umfassen Column Stores (wie HBase, Cassandra), Document Stores (wie MongoDB, CouchDB und Riak) und Key/Value-Stores (wie Dynamo, Voldemort, Riak etc.) und Graphdatenbanken.

Die nachgelagerten oder auch soft-NoSQL genannten Systeme umfassen Objektdatenbanken, XML-Datenbanken und weitere Datenbanken und Lösungen, die fast alle Kriterien der NoSQL-Definition erfüllen.

Key/Value-Systeme

Key/Value-Systeme gehören zur Gruppe der NoSQL-Systeme und bieten mindestens ein einfaches Schema aus Schlüssel und Wert. Schlüssel können in Namensräume und Datenbanken aufgeteilt werden, während die Values oft Hashes, Sets oder Listen sein können. Das einfache Datenmodell ermöglicht eine schnellere und effizientere Datenverwaltung, aber die Abfragemöglichkeiten sind beschränkt und komplexe Queries können oft nicht selbst geschrieben werden.

Klassiker in diesem Bereich sind Amazon Dynamo und S3, sowie Redis, Voldemort und Scalaris.

Column-Family-Systeme

Column Family-Systeme sind eine Untergruppe der NoSQL-Systeme, die Datenstrukturen ähneln Excel-Tabellen, aber die Schlüssel und Key/Value-Paare flexibel erweitern können. Typische Vertreter dieser Familie sind HBase, Cassandra und Hypertable. Sie ermöglichen die Organisation von Keys und Values in Form von Keyspaces oder Clustern und bieten oft auch Super-Columns in Form von Sub-Listen an. Sie sind eine Mischung aus Key/Value-Systemen und spaltenorientierten Datenbanken oder ähneln manchmal auch relationalen Datenbanken.

Document Stores

Document Stores sind eine Untergruppe der NoSQL-Systeme, die strukturierte Datensammlungen wie JSON, YAML oder RDF-Dokumente speichern. Der Begriff stammt ursprünglich von Lotus Notes, wo tatsächlich Anwenderdokumente gespeichert wurden. Die wichtigsten Systeme in diesem Bereich sind CouchDB, MongoDB und Riak. CouchDB und Riak speichern JSON und MongoDB speichert BSON, das binäre Format von JSON.

Bsp.

YAML:

SurName="Doe"
FirstName="John"
	Age="42"

JSON:

{
	"SurName" : "Doe"
	"FirstName" : "John"
	"Age" : 42
}

Graphendatenbanken

Graphdatenbanken sind eine Untergruppe der NoSQL-Systeme, die sich auf die Verwaltung von Graph- oder Baumstrukturen spezialisiert haben, in denen die Elemente miteinander verknüpft sind. Sie haben ihre Wurzeln in den 80er und 90er Jahren und wurden hauptsächlich zur Modellierung und Verwaltung von Netzen eingesetzt. Seit 2008 erfahren sie aufgrund der Location Based Services immer mehr Aufmerksamkeit. Die meisten Graphdatenbanken sind native Graphdatenbanken, die Property-Graphen modellieren, d.h. Knoten und Kanten des Graphen können mit Eigenschaften (Properties) versehen werden. Der Vorteil von Graphdatenbanken ist die Möglichkeit, die Beziehungen (Relationen) schneller zu traversieren als es auf einer relationalen Datenbankstruktur möglich wäre.

Vergleich der Systeme (SQL/No-SQL)

Ausserdem lassen sich die Datenbanken unterscheiden ob sie Verteilt sind oder nicht. Ausserdem können die Datenbanksysteme Disk- oder RAM-basiert arbeiten

Theoretische Grundlagen

Map/Reduce

Map/Reduce ist ein parallelisiertes Verarbeitungsverfahren, das ursprünglich von Google entwickelt wurde, um große Datenmengen (in der Größenordnung von Terabytes bis hin zu Petabytes) effizient zu verarbeiten. Es besteht aus zwei Schritten: dem Map-Schritt und dem Reduce-Schritt. Im Map-Schritt werden die Daten in kleinere, unabhängige Teile (Key-Value-Paare) aufgeteilt, die dann auf verschiedene Knoten im Cluster verteilt werden. Im Reduce-Schritt werden die Ergebnisse der Map-Schritte aggregiert und zusammengeführt.

Das Map/Reduce-Verfahren wurde von Google in vielen Produktionsumgebungen eingesetzt und hat sich als sehr effektiv erwiesen, insbesondere für Anwendungen wie die Verarbeitung von Web-Logs, die Erstellung von Indizes und die Durchführung von statistischen Analysen. Es gibt viele Open-Source-Implementierungen von Map/Reduce, wie z.B. Apache Hadoop und Apache Spark, die es Entwicklern ermöglichen, dieses Verfahren in ihren Anwendungen zu nutzen.

CAP und Eventually Consistent

Das CAP-Theorem besagt, dass es in einem verteilten Computersystem nicht möglich ist, gleichzeitig die Eigenschaften Consistency (Konsistenz), Availability (Verfügbarkeit) und Partition Tolerance (Partitionsfehler-Toleranz) zu gewährleisten. Ein System kann höchstens zwei dieser Eigenschaften gleichzeitig erfüllen.

Eine kurze Erklärung dieser begriffe:

• Consistency bedeutet, dass alle Knoten im System die gleiche Datenansicht haben.
• Availability bedeutet, dass jederzeit auf die Daten zugegriffen werden kann.
• Partition Tolerance bedeutet, dass das System auch dann noch funktioniert, wenn die Kommunikation zwischen einigen Knoten unterbrochen ist.

Eventually Consistent bedeutet, dass das System auf lange Sicht konsistent sein wird, obwohl es in kurzfristigen Zuständen inkonsistent sein kann. Dies wird oft in Systemen verwendet, die Partition Tolerance und Verfügbarkeit priorisieren und Konsistenz in gewisser Weise opfern.

Consistent-Hashing

Das Multi-Version Concurrency Control (MVCC) ist ein Protokoll zur Verwaltung von Concurrency-Problemen in Datenbanken. Es ermöglicht es mehreren Benutzern, gleichzeitig auf die gleiche Tabelle zuzugreifen und Änderungen vorzunehmen, ohne dass es zu Konflikten oder Inkonsistenzen kommt.

Das MVCC-Protokoll erstellt für jeden Eintrag in der Tabelle eine neue Version, wenn ein Benutzer eine Änderung vornimmt. Jede Version hat eine eindeutige Versionsnummer und ein Zeitstempel. Wenn ein Benutzer auf die Tabelle zugreift, sieht er die Version, die zum Zeitpunkt des Zugriffs gültig war. Wenn zwei Benutzer gleichzeitig die gleiche Version eines Eintrags ändern, wird die zuletzt gespeicherte Version verwendet.

Ein wichtiger Vorteil des MVCC-Protokolls ist, dass es die Möglichkeit bietet, Transaktionen parallel auszuführen, ohne dass es zu Konflikten kommt. Wenn eine Transaktion einen Eintrag ändert, wird die alte Version des Eintrags nicht gelöscht, sondern bleibt erhalten, so dass andere Transaktionen weiterhin Zugriff darauf haben.

Ein Nachteil des MVCC-Protokolls ist, dass es den Speicherbedarf erhöht, da für jede Änderung eine neue Version des Eintrags erstellt wird. Auch die Verwaltung der Versionsnummern und Zeitstempel kann zusätzlichen Overhead verursachen.

Das MVCC-Protokoll wird in vielen relationalen und NoSQL-Datenbanken verwendet, darunter PostgreSQL, Oracle, MySQL und MongoDB. Es ist besonders nützlich in Umgebungen mit hoher Concurrency und in Anwendungen, die Snapshot-Isolation benötigen.

Vector Clocks

Vector Clocks sind eine Technik zur Verwaltung von Concurrency-Problemen in verteilten Systemen. Sie dienen dazu, den Zustand von Objekten in einem verteilten System zu verfolgen und zu bestimmen, welche Version die aktuellste ist. Vector Clocks werden häufig verwendet, um inkonsistente Daten in einem Eventually Consistent-System zu erkennen und zu lösen.

Ein Vector Clock besteht aus einem Vektor von Zählern, die für jeden Prozess im System einen Eintrag haben. Jeder Zähler repräsentiert die Anzahl der Ereignisse, die von dem Prozess ausgeführt wurden. Wenn ein Prozess ein Ereignis ausführt, wird der Zähler für diesen Prozess um 1 erhöht.

Wenn ein Objekt von einem Prozess zu einem anderen repliziert wird, wird dessen Vector Clock mit dem Vector Clock des Objekts kombiniert. Dies ermöglicht es dem Empfänger, die relative Reihenfolge der Ereignisse zu bestimmen. Wenn der Empfänger einen Vector Clock erhält, der einen höheren Wert für einen bestimmten Prozess aufweist, weiß er, dass das Objekt von diesem Prozess später bearbeitet wurde als die Version, die er bereits hat.

Vector Clocks können auch verwendet werden, um inkonsistente Daten zu erkennen. Wenn ein Prozess einen Vector Clock erhält, der keine höheren Werte aufweist als sein eigener, weiß er, dass die Daten inkonsistent sind und dass er die Daten manuell prüfen muss, um die aktuellste Version zu erhalten.

Ein Nachteil von Vector Clocks ist, dass sie einen höheren Overhead verursachen können, da jeder Prozess einen Vector Clock speichern und aktualisieren muss. Auch die Verwaltung von inkonsistenten Daten kann zusätzlichen Aufwand erforden.

Vector Clocks werden häufig in verteilten Datenbanken, Cloud-Computing-Umgebungen und anderen verteilten Systemen verwendet, die Eventually Consistent-Modelle verwenden.

Paxos

Paxos ist ein verteiltes Konsensprotokoll, das entwickelt wurde, um sicherzustellen, dass alle Knoten in einem verteilten System übereinstimmende Daten haben. Es wurde ursprünglich von Leslie Lamport im Jahr 1989 entwickelt und ist eines der ältesten und am weitesten verbreiteten Konsensprotokolle.

Das Paxos-Protokoll besteht aus drei Rollen: Proposer, Acceptor und Learner.

Proposer sind die Knoten, die einen Vorschlag für eine Änderung machen. Sie senden einen Vorschlag an eine Gruppe von Acceptors und warten auf eine Mehrheit der Zustimmungen, bevor sie die Änderung durchführen.

Acceptors sind die Knoten, die die Vorschläge der Proposer entgegennehmen und entscheiden, ob sie den Vorschlag akzeptieren oder ablehnen. Sie antworten dem Proposer mit einer Zustimmung oder Ablehnung, je nachdem, ob der Vorschlag bereits von einem anderen Proposer akzeptiert wurde oder nicht.

Learner sind die Knoten, die die endgültige Entscheidung der Acceptors erhalten und die Änderungen durchführen.

Das Paxos-Protokoll besteht aus mehreren Phasen, die sicherstellen, dass nur gültige Änderungen durchgeführt werden und dass alle Knoten im System die gleiche Ansicht haben. In der ersten Phase, der Propose-Phase, schlägt ein Proposer eine Änderung vor und sendet sie an eine Gruppe von Acceptors. In der zweiten Phase, der Accept-Phase, stimmen die Acceptors dem Vorschlag zu oder lehnen ihn ab. Wenn eine Mehrheit der Acceptors dem Vorschlag zustimmt, wird die Änderung durchgeführt und an die Learner weitergegeben.

Ein Vorteil von Paxos ist, dass es toleriert bis zu eine bestimmte Anzahl von ausfallenden Knoten und trotzdem weiterhin funktioniert. Es ist also sehr robust. Ein Nachteil ist, dass es relativ komplex ist und eine gewisse Zeit benötigt, um die Konsensentscheidung zu treffen.

Paxos-Protokoll wird in vielen verteilten Systemen, wie z.B Datenbanken, Cloud-Computing-Systemen und anderen Anwendungen verwendet, die sicherstellen müssen, dass alle Knoten im System übereinstimmende Daten haben.

REST

REST (Representational State Transfer) ist ein Architekturstil für die Entwicklung von Webanwendungen. Es legt fest, wie Ressourcen im Web dargestellt werden und wie darauf zugegriffen werden kann. RESTful-Webanwendungen verwenden standardmäßig HTTP-Methoden wie GET, POST, PUT und DELETE, um Ressourcen zu erstellen, abzurufen, zu aktualisieren und zu löschen.

Ein wichtiger Aspekt von REST ist die Verwendung von URIs (Uniform Resource Identifiers), um Ressourcen im Web zu identifizieren. Jede Ressource hat eine eindeutige URI, die es ermöglicht, sie mit einem HTTP-Request abzurufen. RESTful-Webanwendungen verwenden auch standardmäßig HTTP-Statuscodes, um die Ergebnisse von Anfragen anzuzeigen.

REST legt auch fest, dass Ressourcen durch Representations dargestellt werden sollen, die in einem standardisierten Format wie JSON oder XML vorliegen. Dadurch können Clients und Server die Ressourcen verstehen und verarbeiten, unabhängig von der Implementierung.

Ein weiterer wichtiger Aspekt von REST ist die Trennung von Client und Server. Der Client sendet Anfragen an den Server und erhält Antworten, aber er hat keine Kenntnis darüber, wie die Ressourcen auf dem Server verwaltet werden. Der Server ist für die Verwaltung der Ressourcen und die Bereitstellung von Antworten auf Anfragen verantwortlich.

Ein Vorteil von REST ist, dass es ein offenes und standardisiertes Protokoll ist, das von vielen verschiedenen Plattformen und Programmiersprachen unterstützt wird. Es ermöglicht es Entwicklern, Webanwendungen zu erstellen, die einfach zu verstehen und zu warten sind und die leicht skalierbar sind. Ein Nachteil von REST ist, dass es keine standardisierten Mechanismen zur Verwaltung von Concurrency und Zustandsproblemen bereitstellt, die in verteilten Systemen häufig auftreten.

MongoDB (Document Stores)

MongoDB ist eine Open-Source verfügbare, nichtrelationale Datenbanklösung, die zu den NoSQL Datenbanken gezählt wird und für Big Data Anwendungen genutzt werden kann. Es wurde zum ersten Mal 2009 vorgestellt und arbeitet mit sogenannten Sammlungen und Dokumenten, welche wiederum verschiedene Schlüssel-Werte Paare beinhalten, die die Daten speichern.

MongoDB ermöglicht eine flexible und skalierbare Datenverwaltung, indem es Dokumente anstelle von Tabellen verwendet und eine horizontal skalierbare Architektur unterstützt. Es bietet auch erweiterte Funktionen wie Datensuche, Aggregation und Indexierung, die es für Anwendungen wie Content Management, E-Commerce und Analytik besonders geeignet machen. MongoDB wird auch oft in Verbindung mit Cloud-basierten Diensten eingesetzt und ermöglicht so eine einfache Verwaltung und Nutzung von großen Datenmengen.

Aufbau

MongoDB ist eine NoSQL-Datenbank, die auf Sammlungen statt Tabellen und Dokumente statt Datensätze setzt. Dokumente enthalten Key-Value Paare, die die eigentlichen Daten speichern und unterschiedliche Datentypen enthalten können. MongoDB nutzt BSON, ein binäres Datenformat, das auf JSON aufbaut und dadurch speicherfreundlicher ist als textbasierte Dateiformate. Der Speicherplatz pro Dokument ist auf 8MB begrenzt.

BigData Anwendungen

MongoDB ist ein geeignetes System für Big Data Anwendungen, da es horizontale Skalierbarkeit, ein flexibles Datenschema und eine effiziente Speicherengine bietet.

Der größte Vorteil von MongoDB ist jedoch die Unterstützung von Dynamic Querying, was ermöglicht, dass die Abfragestatements erst erstellt werden, wenn die Abfrage gestartet wird, was Flexibilität in Programmierung ermöglicht und es besonders gut für Anwendungen geeignet macht, bei denen die Daten zwischen Speicherung und Abfrage verändert werden müssen.

Vorteile

• Load Balancing: Diese Datenbanken können über verschiedene Virtual Machines verteilt werden und bleiben somit auch bei einer grossen Anzahl gleichzeitiger Abfragen oder bei grossen Datenmengen noch relativ performant. Relationale Datenbanken hingegen können aufgrund ihrer grundlegenden Eigenschaften (ACID) nicht auf mehrere Rechner aufgeteilt werden. Dadurch muss eine Maschine leistungsfähiger gemacht werden, wenn sie viele Anfragen verarbeiten muss. Dies ist in den meisten Fällen teurer und aufwändiger als die Last über mehrere Rechner zu verteilen.
• Flexible Datenformate: Wie wir bereits beleuchtet haben, können in MongoDB deutlich flexiblere Datenschemata gespeichert werden als in relationalen Datenbanken. Jeder Key kann theoretisch ein eigenes Datenformat haben.
• Unterstützung in vielen Programmiersprachen: MongoDB wurde mittlerweile für viele Programmiersprachen, wie beispielsweise Python, PHP, Ruby, Node.js, C++, Scala, JavaScript und viele mehr, entwickelt und unterstützt. Dadurch kann die Datenbank für verschiedenste Anwendungsprojekte und in deren Programmiersprache einfach eingebunden werden, ohne dass in eine andere Sprache gewechselt werden muss.
• Hohe Skalierbarkeit: MongoDB ermöglicht es, Daten horizontal zu skalieren, indem sie auf mehrere Server aufgeteilt werden können. Dadurch kann die Leistung und die Kapazität der Datenbank erhöht werden, ohne dass die Verfügbarkeit beeinträchtigt wird.
• Automatische Failover: MongoDB hat ein integriertes Replikations- und Failover-System, das sicherstellt, dass die Daten im Falle eines Ausfalls eines Servers automatisch auf einen anderen Server übertragen werden und somit die Verfügbarkeit der Datenbank gewährleistet bleibt.
• Einfache Indexierung: MongoDB unterstützt eine Vielzahl von Indizes, die es ermöglichen, schnell auf Daten zuzugreifen und Abfragen zu optimieren. Dies erleichtert die Verwaltung und die Leistung von großen Datenmengen.

Querries

Zeige alle Datenbanken (ausgeschlossen leere)

show dbs

Datenbank auswählen

Falls eine Datenbank angezeigt wird, können sie diese folgendermassen auswählen. Der Befehl wechselt in die Datenbank. Falls noch keine Datenbank mit dem folgenden Namen vorhanden ist, wird diese erstellt:

use blog

Collection erstellen

Dieser Befehl erstellt eine Collection.

db.createCollection("posts");

Einen Datensatz in der Datenbank abspeichern

db.posts.insertOne({
    title: "MongoDB & NoSQL",
    author: "Lukas",
    date: new Date(),
    tags: ["mongodb", "blogging", "tutorial"]
});

Update einen Datensatz

db.posts.updateMany(
  { title: "MongoDB & NoSQL" },
  { $set: { tags: ["NoSQL", "MongoDB", "Database"] } }
);

Mehrere Datensätze löschen:

db.posts.deleteMany({ tags: "blogging" });

Eine Abfrage für alle Datensätze in einer Collection

db.posts.find()

…und mit Parametern:

db.posts.find({ title: "My first blog post" });
//
db.posts.find({ title: "My first blog post", author: "John Doe"});

Queries können mit REGEX mehr Resultate liefern wenn diese Ähnlichkeiten aufweisen:

Zudem können Vergleichsoperatoren genutzt werden um Werte zu vergleichen in Abfragen:

Transactions

session.startTransaction();

try {
    // Execute your queries here
    db.blog.updateOne(
        { _id: "12345" },
        { $set: { title: "New Title" } }
    );

    // Commit the transaction
    session.commitTransaction();
    console.log("Transaction committed.");
} catch (err) {
    // If an error occurs, abort the transaction
    session.abortTransaction();
    console.error("Transaction aborted: ", err);
} finally {
    // End the session
    session.endSession();
}

Datentypen

BSON

MongoDB speichert die Daten in einem BSON-Format ab. BSON ist ein binäres Dateiformat, das auf JSON aufbaut und es in einigen Punkten optimiert. Im Vergleich zu textbasierten Formaten wie CSV, XML oder JSON, benötigt BSON weniger Speicherplatz und Abfragen können performanter sein. BSON speichert die Schlüssel als binäre Werte und die Werte als Text. Zusätzlich speichert BSON Metadaten ab zu dem Datentyp.

Diese Optimierungen helfen die Lesegeschwindigkeit zu verbessert, insbesondere bei sehr großen Datenmengen.

BSON Beispiel:

[{
  "_id": {
    "$oid": "63c1367a7ea2961677d35654"
  },
  "FIRSTNAME": "Rose",
  "LASTNAME": "Bush",
  "STREET": "6110 Westchester Ave",
  "CITY": "Phoenix",
  "STATE": "AZ",
  "ZIP": "89974",
  "COMMENTS": "Horticulture expert"
},{
  "_id": {
    "$oid": "63c1367a7ea2961677d35655"
  },
  "FIRSTNAME": "Harry",
  "LASTNAME": "Eastman",
  "STREET": "12 North Freeson St",
  "CITY": "Clarkston",
  "STATE": "ID",
  "ZIP": "88520",
  "COMMENTS": "Contact for chemical industry networking."
}]

JSON- Syntax

In JSON müssen die Werte einem der folgenden Datentypen entsprechen:

Strings

{"name":"John"}

Numbers

{"age":30}

Objects

{  
"employee":{"name":"John", "age":30, "city":"New York"}  
}

Arrays

{  
"employees":["John", "Anna", "Peter"]  
}

Bool

{"sale":true}

null

{"middlename":null}

Web Scale? Deez Nuts!

MongoDB Is Web Scale - YouTube