GrumpyCat schrieb:
Man gibt der Applikation quasi einfach eine eigene Partition. Ist ein alter Hut, macht z.B. Oracle seit Ewigkeiten:
https://de.m.wikipedia.org/wiki/Raw_Device
...mit zweifelhaften Geschwindigkeitsgewinnen, das Netz ist voll mit Anekdoten dazu.
Das ist schlecht zu vergleichen, vor allem wenn du von einer Partition auf dem gleichen Datenträger oder Raid Verbund ausgehst. Was gewinnst du dadurch? Im schlimmsten Fall gar nichts, weil du dadurch nur eine mögliche Fragmentierung des Dateisystems umgehst, die aber heutzutage kaum noch ein Problem ist.
Anders sieht es dann schon aus, wenn du den Datenbanken eigene LUNs, Speicheradapter und auf die Anforderungen optimierte Datenträger zuweist.
Nur ist die Konfiguration der Raids, Datenträger, Blockgrößen, und Stripe Größen letztlich ein Faktor, der den Aufbau der eigentlichen Datenträger nicht berücksichtigt. Das Problem was man bei einer QLC SSD bekommt, ist ähnlich dem Partition Alignment Problem, was man schon seit Jahren kennt.
Was man mit ZNS nun macht, ist den eigentlichen Aufbau der Datenträger an das System und die Applikationen zu melden, statt mit irgendwelchen festen Blockgrößen zu arbeiten, die dann von dem Datenträger irgendwie bestmöglich auf den physikalischen Aufbau übersetzt werden müssen. Nun erfährt die Applikation, dass sie zum Beispiel die Protokolle möglichst in 64KB Blöcken schreiben und ändern soll, weil auch der Datenträger immer nur in 64KB Blöcken schreibt.
Der Controller im Datenträger muss nun nicht mehr irgendwelche Teilstücke erst im DRAM zwischenspeichern, neu sortieren und die Lese und Schreibvorgänge an die physikalischen Gegebenheiten optimieren. Er bekommt die Daten so serviert, wie sie optimalerweise am Stück verarbeitet werden können.
Aber es geht natürlich auch noch weiter und entspricht dem was wir teilweise von Grafikkarten schon kennen, Multiple Queues. Während aktuell gleichzeitige Anfragen von mehreren Applikationen zwischengespeichert werden und die Reihenfolge der Verarbeitung dann vom Controller im Rahmen der Möglichkeiten optimiert werden muss, wofür man eben Speicher und Rechenleistung in dem Datenträger benötigt. Können in der Zukunft mehrere Applikationen auf unterschiedlichen Kanälen einen Teil des Datenträgers ansprechen. Die Anfragen müssen dann nicht neu sortiert und optimiert werden. Am einfachsten kann man sich dann so einen Datenträger vorstellen, wie aktuell ein ganzes Storage System mit mehreren LUNs, die auf verschiedenen Volumes liegen.
Stelle dir einfach mal ein Lager vor, was zwar mehrere Türen hat, aber bei dem letztlich alle angelieferten Waren erst in einem Zwischenlager gespeichert werden und dann von Lageristen umgepackt und möglichst optimiert gelagert werden müssen. Das ist der Zustand den wir aktuell haben.
In der Zukunft bekommt jeder LKW die Lagerfläche und die optimale Palettengröße schon vorab mitgeteilt, kann direkt anliefern und eigenhändig die Daten einlagern ohne andere Lieferanten zu beeinträchtigen und ohne auf die Lageristen warten zu müssen.
