it-swarm.com.de

Warum können relationale Datenbanken die Anforderungen von Big Data nicht erfüllen?

Es wird oft wiederholt, dass das Big-Data-Problem darin besteht, dass relationale Datenbanken nicht skaliert werden können, um die massiven Datenmengen zu verarbeiten, die jetzt erstellt werden.

Aber an welche Skalierbarkeitsbeschränkungen sind Big Data-Lösungen wie Hadoop nicht gebunden? Warum können Oracle RAC- oder MySQL-Sharding oder MPP-RDBMS wie Teradata (usw.) diese Leistungen nicht erbringen?

Ich interessiere mich für die technischen Einschränkungen - mir ist bewusst, dass die finanziellen Kosten für das Clustering von RDBMS unerschwinglich sein können.

17
Jeremy Beard

MS hatte gerade ein Tech Talk in den Niederlanden, wo sie einige dieser Sachen besprachen. Es beginnt langsam, geht aber um die 20-Minuten-Marke in das Fleisch von Hadoop über.

Der Kern davon ist, dass "es darauf ankommt". Wenn Sie einen vernünftig angeordneten (zumindest etwas) einfach zu partitionierenden Datensatz haben, der (zumindest etwas) homogen ist, sollte es relativ einfach sein, mit einem RDBMS auf diese hohen Datenmengen zu skalieren, je nachdem, was Sie tun .

Hadoop und MR scheinen eher auf Situationen ausgerichtet zu sein, in denen Sie zu großen verteilten Scans von Daten gezwungen sind, insbesondere wenn diese Daten nicht unbedingt so homogen oder strukturiert sind wie in der RDBMS-Welt.

An welche Einschränkungen sind Big Data-Lösungen nicht gebunden? Für mich besteht die größte Einschränkung, an die sie nicht gebunden sind, darin, vorab ein starres Schema zu erstellen. Mit Big Data-Lösungen schieben Sie jetzt riesige Datenmengen in die "Box" und fügen Ihren Abfragen später Logik hinzu, um die mangelnde Homogenität der Daten zu beheben. Aus Entwicklersicht ist der Kompromiss die einfache Implementierung und Flexibilität am Frontend des Projekts gegenüber der Komplexität bei der Abfrage und der weniger unmittelbaren Datenkonsistenz.

15
Dave Markle

Der Datenbankpionier und Forscher Michael Stonebraker hat gemeinsam ein Papier geschrieben, in dem die Einschränkungen traditioneller Datenbankarchitekturen erörtert werden. Im Allgemeinen skalieren sie mit teurerer Hardware, haben jedoch Schwierigkeiten, parallel mit mehr Standardhardware zu skalieren, und sind durch eine ältere Softwarearchitektur begrenzt, die für eine ältere Ära entwickelt wurde. Er behauptet, dass die BigData-Ära mehrere neue Datenbankarchitekturen erfordert, die die moderne Infrastruktur nutzen und für eine bestimmte Arbeitslast optimieren. Beispiele hierfür sind das C-Store-Projekt, das zur kommerziellen Datenbank Vertica Systems führte, und das H-Store-Projekt, das zu VoltDB führte, einer speicherinternen OLTP SQL-Datenbank, die für hohe Geschwindigkeit ausgelegt ist BigData-Workloads (vollständige Offenlegung, ich arbeite für VoltDB).

Vielleicht finden Sie dieses Webinar zu diesem Thema interessant. Es reagiert auf einige der Mythen, die mit dem Erfolg von NoSQL-Datenbanken entstanden sind. Grundsätzlich behauptet er, dass SQL nicht das Problem war, es sollte nicht notwendig sein, traditionelle Datenbankfunktionen wie Konsistenz aufzugeben, um Leistung zu erzielen.

6
BenjaminBallard

Es ist nicht ganz richtig, dass RDBMS nicht skaliert werden kann. Die teilweise Wahrheit in der Aussage hängt jedoch von der Architektur ab. In der von Ihnen angegebenen Liste unterscheidet sich Oracle RAC von den anderen (Sharded MySQL und Teradata). Der Hauptunterschied besteht zwischen Shared Disk- und Shared Nothing-Architekturen.

Freigegebene Festplattenarchitekturen wie Oracle RAC leiden unter Skalierung, da zu einem bestimmten Zeitpunkt alle ausgeführten Computer auf einem Teil der Daten synchronisiert werden sollten. Zum Beispiel Global Lock Manager ist ein Killer. Sie können die Feinabstimmung bis zu einem gewissen Grad fortsetzen, aber Sie werden letztendlich gegen eine Wand stoßen. Wenn Sie keine Maschinen hinzufügen können, sollten Sie weniger, aber sehr leistungsstarke Maschinen haben, die Ihre Tasche verbrennen können. Bei gemeinsam genutzten Nichts-Architekturen (oder Sharded-Daten) übernimmt jeder Computer das Eigentum an einigen Daten. Es muss nicht mit anderen Mahcines synchronisiert werden, wenn einige Daten aktualisiert werden sollen.

Dann kommt die Generation der NoSQL-Datenbanken. Ich würde ihnen eine Teilmenge traditioneller RDBMS-Datenbanken behandeln. Nicht alle Anwendungen auf dieser Welt benötigen alle von RDBMS angebotenen Funktionen. Wenn ich die Datenbank als Cache verwenden möchte, ist mir die Haltbarkeit egal. In einigen Fällen würde mir auch die Konsistenz egal sein. Wenn meine gesamte Datenrecherche auf einem Schlüssel basiert, benötige ich keine Unterstützung für Bereichsabfragen. Ich benötige möglicherweise keine Sekundärindizes. Ich brauche nicht die gesamte Ebene für die Abfrageverarbeitung/Abfrageoptimierung, die alle herkömmlichen Datenbanken haben.

5
sunil