Riesige Datenmengen verwischen absichtlich die Grenze zwischen Speicher und Datenbank

Je nachdem, wie man es betrachtet, ist eine Datenbank eine Art hochentwickeltes Speichersystem oder Speicher ist eine Art Reduktion einer Datenbank. In der realen Welt, in der Datenbanken und Speicher getrennt sind, gibt es mit Sicherheit ein Kontinuum der Zusammenarbeit zwischen beiden. Es steht außer Frage, dass relationale Datenbanken die Entwicklung von Speichersystemen genauso stark vorangetrieben haben – und sie in ganz unterschiedliche Richtungen trieben – wie es die File-Serving- und dann die Object-Serving-Workloads getan haben.

Was wäre, wenn Sie solche Entscheidungen nicht treffen müssten? Was wäre, wenn Ihr Speicher eine echte, echte und ehrliche Datenbank wäre? Was wäre, wenn Vast Data, der aufstrebende Hersteller von All-Flash-Speicherclustern, die das Network File System besser und mit weitaus größerer Skalierbarkeit als komplexere (und weniger nützliche) NoSQL- oder Objektspeicher beherrschen, vom ersten Moment seiner Gründung an darüber nachgedacht hätte? dass die Schaffung einer neuen Art von Speicher zur Steuerung einer neuen Art eingebetteter Datenbank schon immer der Plan war? Was wäre, wenn KI immer der Plan wäre und HPC-Simulation und -Modellierung mitkommen könnten?

Nun, die Vast Data Platform, wie dieser Speicher-Datenbank-Hybrid heute genannt wird, war schon immer der Plan. Und dieser Plan war immer mehr als der Universal Storage, der Anfang 2016 von den Mitbegründern Renen Hallak, dem Vorstandsvorsitzenden des Unternehmens, Shachar Fienblit, Vizepräsident für Forschung und Entwicklung, und Jeff Denworth, Vizepräsident für Produkte und Entwicklung, erdacht wurde Chief Marketing Officer, und im Februar 2019 gestartet. Dies ist eine eigenständige nächste Plattform, was bedeutet, dass sie auch mit der Rechenleistung clevere Dinge tun muss. Vielleicht wird es am Ende also einfach die Vast-Plattform heißen? Aber lassen wir uns nicht überstürzen.

Andererseits: Warum nicht? Die Mitbegründer von Vast Data haben das schon vor langer Zeit getan.

„Damals im Jahr 2015 gab es in meinem Pitch-Deck eine Folie zum Thema Lagerung in diesem gesamten Deck, das vielleicht fünfzehn Folien enthielt“, erzählt Hallak gegenüber The Next Platform. „Einer von ihnen hatte Speicher, der Rest hatte andere Teile, die gebaut werden mussten, damit diese KI-Revolution wirklich so stattfinden konnte, wie sie sollte.“ Vor acht Jahren wurden Katzen in YouTube-Videos als KI identifiziert. Es war nicht annähernd das, was es heute ist. Aber es war ganz klar: Wenn in den nächsten zwanzig Jahren etwas Großes in der IT-Branche passieren würde, dann wäre es KI, und wir wollten ein Teil davon sein. Wir wollten es anführen. Wir wollten es anderen ermöglichen, an dieser Revolution teilzuhaben, die scheinbar auf einige wenige sehr große Organisationen beschränkt war. Und das hat uns nicht gefallen. Wir wollen diese Technologie demokratisieren.“

Und das bedeutet mehr als nur die Schaffung eines massiv skalierbaren NFS-Dateisystems und Objektspeichersystems der nächsten Generation auf Basis von Flash. Es bedeutet, auf immer höheren Ebenen im Stapel zu denken und die Konzepte der Datenspeicherung und einer Datenbank mit den großen Datensätzen aus der natürlichen Welt zusammenzuführen, die KI-Anwendungen zunehmend zugrunde liegen.

Daten sind nicht mehr auf begrenzte Textmengen und Zahlen in Zeilen oder Spalten in einer Datenbank beschränkt, sondern auf hochauflösende Daten – Video, Ton, Genomik, was auch immer –, die eine normale relationale Datenbank sprengen würden. KI-Workloads erfordern enorme Datenmengen zum Erstellen von Modellen und viel Leistung, um das Training von Modellen voranzutreiben, und manchmal enorme Rechenmengen, um Rückschlüsse auf neue Daten zu ziehen, wenn diese in das Modell eintreten. All dies übt einen enormen Druck auf das Speichersystem aus, Informationen bereitzustellen – etwas, das der Universal Storage von Vast Data bewältigen kann, eine disaggregierte Shared-Everything-Implementierung von NFS, die über einen sehr feinkörnigen Quasi-Objektspeicher verfügt.

„Daten haben eine viel größere Bedeutung als Computer“, fügt Hallack hinzu. „Es ist größer und es ist schwieriger, sich zu bewegen. Damit wir in diesem KI-Bereich spielen können, dürfen wir uns nicht nur auf den Datenteil beschränken. Wir müssen etwas wissen und eine Meinung darüber haben, wie die Daten organisiert sind. Es geht darum, Kompromisse zu überwinden, und es geht nicht nur um die Speicherung. Wenn Sie diesen Wortspeicher herausnehmen und in die Wortdatenbank einfügen, treten dieselben Herausforderungen auf. Kosten, Leistung, Skalierbarkeit, Belastbarkeit, Benutzerfreundlichkeit – das sind keine Speicherbegriffe. Es handelt sich um sehr allgemeine Informatikbegriffe.“

Die ersten Ansätze der Vast Data Platform wurden im Vast Catalogue vorgestellt, der im Februar dieses Jahres eingeführt wurde und im Wesentlichen ein SQL-Frontend und ein semantisches System auf das NFS-Dateisystem und den Objektspeicher setzt, die dem Universal Storage zugrunde liegen. Dies war der erste Hinweis darauf, dass sich unter der Hülle des Universal Storage eine neue Engine befand, die SQL-Abfragen unterstützte. Jetzt lüftet Vast Data die Hüllen komplett und enthüllt, wie Datenspeicher und Datenbank auf einer einzigen Plattform zusammengeführt wurden und wie diese schließlich über eine Rechenschicht verfügen wird.

Daher werden wir die Ankündigung der Vast Data Platform genauso behandeln wie eine Ankündigung einer Server-Computing-Engine, indem wir zunächst einen Überblick geben (das wäre die Geschichte, die Sie gerade lesen) und dann einen tiefen Einblick geben, nachdem wir etwas recherchiert haben in die Architektur. Technisch gesehen machen wir Urlaub am Strand von Hilton Head Island, South Carolina, und haben Kinder, mit denen wir am Strand spielen können. . . .

Wie Jensen Huang, Mitbegründer von Nvidia, gerne sagt: KI ist ein Full-Stack-Problem und Vast Data hat wie Nvidia vom ersten Tag an über den Full-Stack nachgedacht. Soweit wir das beurteilen können, hat Vast Data kein Interesse daran, Hardware für Computer, Speicher oder Netzwerke herzustellen und überlässt dies gerne anderen. Denn ehrlich gesagt gibt es dort Besseres zu tun.

Als würde man Exascale-Klassenspeicher mit einer nativen Datenbank kombinieren, um KI-Workflows wie diesen von Amazon Web Services loszuwerden:

Aber es ist mehr als das. Es geht darum, wirklich riesige Datenmengen zu verstehen.

„GPT-3 wurde mit etwa 45 Terabyte an Daten trainiert, was meiner Meinung nach im Großen und Ganzen nicht viele Daten sind“, sagt Denworth gegenüber The Next Platform. „Wir arbeiten jetzt mit einer Reihe von Leuten zusammen, die Grundmodelle erstellen – also Organisationen vom Typ Inflection AI – und wir beginnen, Pläne für einzelne Datenspeicher mit mehreren Exabyte zu sehen. Einige der größten Geschäfte, die ich je in meinem Leben gesehen habe, finden innerhalb von etwa acht Wochen statt. Und eine der Überlegungen ist, dass der Korpus um Größenordnungen wächst, wenn man über den Text hinaus zu den Daten der natürlichen Welt übergeht. Im Moment gibt es nur wenige Organisationen auf der Welt, die so viele einzigartige Informationen erfassen und daraus einen Sinn machen können, und die Frage ist: Warum?“

Die Antwort ist, dass das alles zu schwierig und zu teuer ist und dass es einen Weg geben muss, es einfacher, schneller und billiger zu machen. Etwas, das eher so aussieht:

Das erste Mal, dass wir wissen, wo jemand versucht hat, eine solche Datenplattform zu schaffen, ist sehr, sehr lange her – zumindest im Vergleich zu den Zeitrahmen der Computerindustrie – und sie funktionierte bis zu einem gewissen Grad innerhalb ihres eigenen Kontexts und ihrer eigenen Grenzen. Das zweite uns bekannte Beispiel war ein kläglicher Misserfolg, und das dritte Beispiel hatte eine so schlechte Leistung, dass niemand mehr darüber spricht.

Als IBM 1978 die relationale Datenbank entwickelte, kam sie zunächst nicht auf den ehrwürdigen System/370-Großrechnern der damaligen Zeit kommerzialisiert, sondern auf einer wenig genutzten, aber architektonisch bedeutsamen Maschine namens System/38. Das Tolle an dieser Maschine ist, dass in das Betriebssystem eine relationale Datenbank eingebettet war und der Zugriff wie auf einen Flatfile-Datenspeicher funktionierte, sie jedoch über all diese SQL-Erweiterungen verfügte, die es den Benutzern ermöglichten, die Daten auf eine Weise abzufragen, die eigentlich nicht möglich wäre ein Flatfile-Datenspeicher. Tatsächlich war die relationale Datenbank das Dateisystem, und es gab nie eine Möglichkeit, Daten zu speichern, die nicht abgefragt werden konnten. Das einzige Problem bei diesem Ansatz besteht darin, dass er viel Rechenaufwand erforderte und MIPS für MIPS, das System/38 mit einem relationalen Datenbankstapel, zwei- bis dreimal teurer war als ein damaliger System/370-Mainframe. Erst mit der Ankündigung des AS/400 durch IBM im Jahr 1988 sanken die Rechenkosten so weit, dass dies praktischer wurde, aber es war immer noch ein langsames Dateisystem. Und in den späten 1990er Jahren hat IBM das parallele Dateisystem OS/2 auf das Betriebssystem OS/400 übertragen, damit es über ein richtiges Internet-Dateisystem verfügen konnte und die Datenbank zu einer reinen Datenbank degradiert wurde.

Big Blue hatte die richtige Idee, aber sie überstieg das damalige Rechenbudget. Genauso wie die in den 1980er Jahren entwickelten KI-Algorithmen mehr oder weniger funktionierten, aber sie benötigten um Größenordnungen mehr Daten und um Größenordnungen mehr Rechenleistung, um das neuronale Netzwerk tatsächlich funktionieren zu lassen.

Die richtige Idee hatte Microsoft auch mit dem Object File System, das in den 1990er Jahren Teil des Windows- und Windows Server-Kernels „Cairo“ war und Anfang der 2000er Jahre mit der Windows- und Windows Server-Version „Longhorn“ als WinFS wiedergeboren wurde. Auch Microsoft hat verstanden, dass wir alle strukturierte, halbstrukturierte und unstrukturierte Daten in derselben Datenbank/im selben Datenspeicher speichern und die Abfrage mithilfe von SQL ermöglichen müssen.

Und schließlich gab es noch Hadoop, den Klon des Datenabfragealgorithmus Google MapReduce und einen massiv verteilten, unstrukturierten Datenspeicher. Schließlich wurden Haoop verschiedene SQL-Overlays hinzugefügt, darunter Hive, HBase, Impala und Hawq, und obwohl diese funktionierten, war die Leistung miserabel. Relationale Datenbanken ließen sich nicht so weit skalieren wie Hadoop, und Hadoop war beim Abfragen von Daten um Größenordnungen langsamer als eine relationale Datenbank – und das ist im Großen und Ganzen nicht besonders schnell.

Das bringt uns zum heutigen Tag und zur Vast Data Platform. Das Team von Vast Data nimmt die Idee erneut in Angriff und verfügt über eine einzigartige Speicherarchitektur, die diese uralte Vision möglicherweise Wirklichkeit werden lässt.

Wir freuen uns darauf, uns mit dem Unkraut auseinanderzusetzen und herauszufinden, wie und warum.

Mit Highlights, Analysen und Geschichten der Woche direkt von uns in Ihren Posteingang, ohne dass etwas dazwischen liegt. Jetzt abonnieren