Hochbegleitendes Speichersystem

Stellen Sie sich vor, Sie benötigen 3 große Tabellen (strukturierte Daten) mit jeweils 30 Milliarden Zeilen (Gesamtgröße von 4 TB), von denen Ihre vielen gleichzeitigen Benutzer (die parallele Betriebssystem-Threads auf Remote-LAN-Computern sind) einen Teil lesen müssen die Daten durch ihre SELELCT WHERE GROUPBY-Abfragen und hochgradig gleichzeitige Abfragen, z. B. 10.000 gleichzeitige Lesevorgänge, und Benutzer müssen auch hochgradig gleichzeitige Daten in diese Tabellen einfügen (keine Aktualisierung), wie bei 2000 gleichzeitigen Schreibvorgängen (im gesamten LAN-Netzwerk des Rechenzentrums). . Die Benutzer möchten so schnell wie möglich aus diesem Speicher lesen und einfügen, wobei jedes Lesen und Schreiben im Bereich von ms bis 1 Sekunde erfolgt.

Welche Technologien empfehlen Sie, um diese Anforderungen zu erfüllen? Gibt es einen Datenspeicher oder einen Schlüsselwertspeicher, der dies ermöglicht? Cloud ist keine Option.

Einige Erläuterungen:

Die Benutzer müssen die Daten NICHT sofort sehen und eine eventuelle Konsistenz ist akzeptabel. Der Zugriff auf die Daten erfolgt über jeden Treiber, den der Speicher bereitstellen kann, und Benutzer sind wiederum nur Threads, die auf Remotecomputern des Rechenzentrums ausgeführt werden. Die Abfragen sind meistens wie SELECT WHERE GROUPBY.

Die Daten sind tabellarisch und jede Zeile ist ungefähr 60 Bytes groß.

Keine Cloud-Option, bei der ich DynamoDB oder ähnliche Lösungen nicht verwenden kann. Ich muss es intern im Rechenzentrum hosten können.

Alle Daten der Tabellen können jederzeit gelesen werden, und das Verwendungsmuster ist nicht vorhersehbar. Es gibt keine Join- oder Super-Long-Abfrage. Kein DR erforderlich, aber ein angemessener HA ist erforderlich, muss aber nicht ausgefallen sein. Jeder Leser erhält eine Reihe von Zeilen basierend auf der where-Klausel und den Zeilen, die nicht wirklich zusammenhängen. Wir können wahrscheinlich eine feste Länge für jede Reihe haben, aber ich hoffe, dass die Speicherschicht sich darum kümmern wird.

Meine größte Sorge sind auch all die gleichzeitigen Schreibvorgänge, die bei gleichzeitigen Lesevorgängen stattfinden.

Ihre Einsichten in diese wird sehr geschätzt.

Außerdem habe ich drei dieser Tabellen mit jeweils 30 Milliarden Zeilen, die unterschiedliche Objekttypen enthalten

Wenn eine eventuelle Konsistenz akzeptabel ist und alle Ihre Abfragen aggregiert sind, funktioniert möglicherweise ein OLAP-System mit niedriger Latenz für Sie. Ihre Anforderung klingt ein bisschen wie eine algorithmische Handelsplattform. Diese Art von Architektur wird häufig in Parkettsystemen verwendet, bei denen aggregierte statistische Analyseberechnungen für aktuelle Daten erforderlich sind.

Wenn Sie Ihre Daten nach Datum partitionieren können und alte Zeilen nicht aktualisiert werden, können Sie ein hybrides OLAP-System mit einem herkömmlichen OLAP-Server wie Microsoft Analysis Services erstellen, der von einer normalen RDBMS-Plattform unterstützt wird. Es sollte möglich sein, mit ~ 4 TB Daten fertig zu werden, und sowohl SQL Server als auch SSAS führen Cluster mit gemeinsam genutzten Datenträgern aus. Ähnliche OLAP-Systeme (z. B. Oracle / Hyperion Essbase) sind von anderen Anbietern erhältlich.

OLAP-Server arbeiten mit persistenten Daten in einem systemeigenen Speicher zusammen mit Aggregaten. Die meisten unterstützen partitionierte Daten. Darüber hinaus funktionieren die meisten auch in einem ROLAP-Modus, in dem Abfragen für die zugrunde liegende Datenbank ausgeführt werden. Wichtig ist, dass die Speicherstrategie auf Partitionsbasis verwaltet werden kann und Sie eine Partition programmgesteuert von einer zur anderen wechseln können.

In diesem Modell werden Verlaufsdaten in MOLAP-Partitionen gespeichert, wobei auch Aggregate der Daten erhalten bleiben. Wenn eine Abfrage von den Aggregaten erfüllt werden kann, verwendet der Server sie. Aggregate können an die Abfragen angepasst werden, und durch korrekte Aggregate wird der für die Auflösung der Abfrage erforderliche Rechenaufwand drastisch reduziert. Bei diesem Systemtyp sind sehr reaktionsschnelle Gesamtabfragen möglich.

Echtzeitdaten können implementiert werden, indem eine kleine führende Partition verwaltet wird - bei Bedarf für den aktuellen Monat, den aktuellen Tag oder sogar die aktuelle Stunde. Der OLAP-Server gibt Abfragen für die Datenbank aus. Wenn diese Partition klein genug ist, kann das DBMS schnell reagieren. Ein regelmäßiger Prozess erstellt neue führende Partitionen und konvertiert geschlossene historische Perioden nach MOLAP. Ältere Partitionen können zusammengeführt werden, sodass die Verlaufsdaten nach Belieben verwaltet werden können.

Die Clients, die in die Datenbank schreiben, schreiben einfach das zugrunde liegende RDBMS heraus. Wenn historische Daten statisch bleiben, werden sie nur auf die führende Partition geschrieben. 4 TB sind ein praktisches Volume für die Verwendung von SSDs, wenn Sie zusätzliche DBMS-Leistung benötigen. Selbst Mainstream-Anbieter bieten SSD-basierte Angebote mit optionalen schnelleren SLC-Einheiten an.