Welche DB-Engine sollte für eine Petabyte-Datenbank verwendet werden?

Gegeben:

  • Das Datenvolumen wird voraussichtlich in einigen Jahren in den Petabyte-Bereich gehen.

  • Der vollständige Satz von Datensatztypen, Anwendungen und Abfragen ist nicht im Voraus bekannt. Es wird erwartet, dass die Interessengruppen immer wieder neue Verwendungen für die Daten finden werden, wie dies normalerweise bei einer großen Datenbank der Fall ist.

  • Das System wird auf handelsüblicher Hardware laufen, die über mehrere Rechenzentren verteilt ist.

  • Aus pragmatischen Gründen, den Code bei Bedarf ändern zu können und nicht in eine schwache Verhandlungsposition gegenüber einem Anbieter zu geraten, werden nach Möglichkeit Open-Source-Lösungen stark bevorzugt.

Was ist die beste Datenbank-Engine?

Wenn wir nur über Terabyte reden würden, würde ich einfach Postgres angeben und fertig, aber ich verstehe, dass von einer Standard-SQL-Datenbank nicht erwartet werden kann, dass sie auf Petabyte skaliert.

Mir wurde zu verstehen gegeben, dass Yahoo Postgres in diesem Umfang modifiziert hat. Mir scheint, dass dies im Grunde bedeuten würde, dass die Programmierer, die Anwendungscode schreiben, Last übertragen müssen (die jetzt die üblichen Vorteile haben, dass sie sich nicht so sehr darum kümmern müssen, niemals Fehler durchzulassen, da eine relationale Datenbank viel zur Durchsetzung beiträgt Konsistenz) für diejenigen, die die Datenbank-Engine warten (das transparente Bereitstellen dieser Garantien zusammen mit schnellen SQL-Abfragen in einem solchen Umfang ist ein schwieriges Problem).

Eine Alternative wäre, eine gute NoSQL-Datenbank-Engine zu nehmen und nach Bedarf zu optimieren. Dies erlegt den Anwendungsprogrammierern eine größere Pflicht auf, niemals einen Fehler zu machen, macht es jedoch einfacher, sich darauf zu verlassen, dass jede gegebene Anwendung mit genügend Aufwand schnell genug erstellt werden kann.

Gilt die erste Option heute als verlässlich praktikabel?

Ist die zweite Option eine typische Praxis? Wenn ja, welche NoSQL-Engine ist die beste für dieses Szenario?

Gibt es eine dritte Option, die ich vermisse?

Eine tolle Frage! Ich habe keine Antwort, aber ich denke, dass "verteilt auf mehrere Rechenzentren" dort der Schlüssel ist. Persönlich würde ich instinktiv bei einer relationalen Datenbank bleiben, da Indizierung und Effizienz beim Skalieren sehr wichtig sein werden, und ich glaube einfach nicht, dass NoSql damit umgehen kann (aber ich würde mich freuen, als falsch bewiesen zu werden). . Persönlich würde ich für MySQL über Postgres greifen, aber für Postgres über NoSql. Dies ist die richtige Seite für Softwareempfehlungen, aber wenn Sie keine erhalten, versuchen Sie es mit dba.stackexchange.com
Sprechen Sie von OLTP (hohe Rate an Einfügungen/Aktualisierungen für einzelne Zeilen) oder analytischen (wenige, schwere, meist schreibgeschützte) Workloads? „Petabytes“ impliziert historische Daten, während „Programmierer, die Anwendungscode schreiben“ und „keine Fehler durchgehen lassen“ darauf hindeuten, dass Sie an OLTP denken (das normalerweise in Bezug auf die Anzahl gleichzeitiger Anforderungen bemessen wird). Die Verwendung der gleichen Instanz (ich würde sagen sogar Werkzeug) für beide ist eine schlechte Idee.
@Nickolay Beide sind erforderlich, aber es ist möglicherweise möglich, zwei verschiedene Datenbanken einzurichten. Welches Tool würden Sie in diesem Fall jeweils empfehlen?

Antworten (2)

Ich halte es für unverantwortlich, etwas auf der Grundlage der bereitgestellten kleinen Details zu empfehlen, aber da meine Gedanken nicht in einen Kommentar passten, werde ich es hier posten.

Für den OLTP-Anwendungsfall: Wenn Sie der Meinung sind, dass Postgres in Bezug auf die Funktionen und für Ihr Entwicklungsteam gut geeignet ist und Sie sich nur um die Skalierung kümmern, sollten Sie die Betriebsdatengröße (die Menge der abgefragten Daten) berücksichtigen die OLTP-Anforderungen) und die Anzahl der TPS (Transaktionen pro Sekunde) und deren Lese-/Schreibrate) und nicht die Gesamtdatenmenge, die das System ansammelt.

Ich habe keine Erfahrung aus erster Hand mit der Skalierung von Postgres, aber 1.000.000 Leseabfragen / s sollen erreichbar sein, wenn die Daten in den Speicher passen, ebenso wie 10.000 Schreibvorgänge / s . Sie können Caches vor der DB platzieren, um die Leseleistung zu verbessern, und Sharding (über Erweiterungen) implementieren, um Schreibvorgänge zu skalieren.

Ich versuche, die Debatten zwischen NoSQL und RDBMS zu vermeiden, aber für diejenigen, deren Hauptanliegen die Skalierbarkeit ist, könnte Ersteres als typische Praxis angesehen werden ...

Für Data-Warehouse-/Reporting-Anwendungsfälle (führen Sie dieses SQL in einer Minute auf Terabytes an Daten aus) gibt es eine Klasse von Lösungen namens „MPP-Datenbanken“ (wenn Sie sich für Postgres interessieren, haben Sie vielleicht schon von Greenplum gehört). Sie fragmentieren die Daten und führen die Abfrage parallel auf mehreren (relativ leistungsstarken) Knoten aus, sind jedoch nicht für die Verarbeitung einer großen Anzahl einfacher Abfragen optimiert.

Wenn Sie eine kostengünstige Möglichkeit zum Speichern der Daten für Analysen benötigen und/oder nicht bereit sind, an ein einziges Tool gebunden zu sein, könnte das Hadoop-Ökosystem interessant sein. Sie verlieren etwas an Effizienz (und investieren Ressourcen in den Aufbau des Fachwissens), erhalten jedoch die Möglichkeit, beliebige „Big Data“-Lösungen (ML, Streaming, eine Vielzahl von DB-Engines) oder benutzerdefinierten Code auf Ihrem Cluster auszuführen.

Schauen Sie sich KakerlakenDB an. Sie sprechen von Big Data und die Plattform muss eine ernsthafte Skalierung unterstützen.

https://www.cockroachlabs.com/

Es ist wahrscheinlich sofort einsatzbereit und hat eine gute Open-Source-Community.

Welche DB-Engine sollte für eine Petabyte-Datenbank verwendet werden?
AntwortenHierDatenschutz-Bestimmungen1y, 0v