Über die Speicherstrategie und das Speicherformat in der Hadoop-Ära

Datenspeicherstrategie

Der aktuelle Stand der Computertechnologie ist, dass nahezu endlose Datenmengen gespeichert werden können. Infolgedessen entfällt praktisch die Notwendigkeit, Daten zu löschen, um Speicherplatz für neue freizugeben.
Dies bietet viele Vorteile, beginnend mit der natürlichen Beziehung von Daten und Objekten, die sie beschreiben, da es Naturschutzgesetze in der Natur gibt, sollte dies auch für Daten gelten, die natürliche Objekte widerspiegeln, und endet mit Ausnahme rein technologischer Probleme im Zusammenhang mit der Datenintegrität in Zeit.

Daher sollte die Speicherstrategie auf dem „weichen“ Löschparadigma basieren, das darin besteht, die Daten ab einem bestimmten Zeitpunkt als relevant zu markieren.

Das gleiche gilt für Datenänderungen. Aktualisierungen sollten frühere Daten nicht überschreiben, sondern darauf hinweisen, dass die Daten ab einem bestimmten Zeitpunkt unterschiedliche Bedeutungen haben.

Wenn Sie wirklich Speicherplatz freigeben möchten, indem Sie die Speicher von nicht verwendeten Daten löschen, können Sie die Strategie der Komprimierung der Speicher anwenden, indem Sie eine Kopie davon erstellen und zu einem bestimmten Zeitpunkt in der Vergangenheit nur relevante Daten überschreiben.

Diese Überlegungen sind nicht neu, da sie bereits in Big Data Warehouses wie Hadoop implementiert sind.

Datenspeicherformat

Daten, die bestimmte Entitäten widerspiegeln, sind in der Regel eine Reihe von Attributen, deren Zusammensetzung die erforderlichen Merkmale der Entität widerspiegelt. Der Einfachheit halber nehmen wir an, dass es sich um ein relationales Modell handelt, das aus Tupeln besteht.

Somit werden Daten in Form von Tupeln eines bestimmten Typs gespeichert, die sich im Laufe der Zeit ändern und an Relevanz verlieren können.

Wir meinen auch, dass moderne Big Data-Speicher häufig eine Schlüsselwertstruktur mit einem Primärindex für Schlüssel und möglichen optionalen Indizes für andere Attribute haben.

Angesichts dieser Überlegungen wird das folgende Datenspeicherformat vorgeschlagen.

Ich möchte sofort darauf hinweisen, dass dieses Format nicht eindeutig ist, sondern von der Datenspeicherstruktur in 1C-Objekten unter dem Namen „Register“ inspiriert ist. Bei dieser Entwicklung wird jedoch vorgeschlagen, das Format universell zu gestalten und alle Daten darin zu speichern.

Daher schlagen wir ein Format zum Aufzeichnen von Daten über Entitäten und deren Attribute vor, das auf dem Konzept eines Workflows basiert und auf den folgenden Definitionen basiert:

• Eine Operation ist eine atomare Änderung in einer Dateneinheit.
• Eine Entität besteht aus Attributen.
• Eine Entität hat einen Typ, der die Zusammensetzung ihrer Attribute bestimmt.
• Entitäten desselben Typs werden in einem einzigen Thread gespeichert.
• Workflow - Ein Speicherobjekt der Typentabelle, in dem sich Operationen befinden, die sich auf Entitäten desselben Typs beziehen und deren Status ändern.

Dementsprechend besteht jede Operation aus einem Operationsheader und einer Reihe von Attributen, die vom Entitätstyp abhängen:

1. OpID - eindeutige Kennung der Operation
2. OpTS - Betriebszeitstempel
3. OpType - Art der Operation
4. OpClass - Streamname
5. OpUser - Benutzer des Systems, das den Befehl ausgegeben hat
6. OpDoc - Operationsdokument, d. H. Das Dokument, das es erstellt hat, wird möglicherweise nicht installiert
7. OpComment - Operationskommentar
8. ID - Kennung der Entität, auf die sich die Operation bezieht
9. Parameter - flussabhängige Betriebsattribute

OpIDs und IDs können alles sein, aber im Moment kann es sinnvoll sein, eine UID zu verwenden.
OpTS sollte höchstwahrscheinlich vom Typ Zeitstempel sein, aber durch einen Ordnungsindex ergänzt werden, wenn mehrere Operationen in den gleichen Zeitraum fallen, um eine eindeutige Reihenfolge der Operationen sicherzustellen.

OpType kann von einem beliebigen Typ sein, z. B. ein / mehrere Zeichen oder eine Zahl.
OpClass, OpUser und OpComment können entweder eine Zeichenfolge oder ein Verweis auf ein Verzeichnis sein.
OpDoc bietet einen Link zum Dokument, kann jedoch fehlen. Dies ist eine Verbindung mit der oberen Ebene.

Operationen sind in Basis und Service unterteilt.

Grundlegende Operationen

Grundlegende Operationen 3 - Hinzufügen, Aktualisieren, Löschen:

1. Operation "A" add - gibt die Instanziierung einer neuen Entität eines bestimmten Typs an und legt eine Reihe von Attributen fest.
2. Operation "U" -Update - Erkennt eine Änderung in einer Entität eines bestimmten Typs und legt neue Werte für einen bestimmten Satz von Attributen fest.
3. Operation "D" löschen - gibt das Ende der Realität einer Entität eines bestimmten Typs an.

Operation A und U können nicht alle Attribute festlegen, sondern nur einige. Die Attribute, die durch diese Operation nicht festgelegt werden, haben möglicherweise einen Wert vom Typ NULL oder einen anderen speziellen Wert, der derzeit noch nicht verfügbar ist, aber es wäre schön, ihn zu erstellen.

Infolgedessen erfordert der tatsächliche Wert der Attribute der Entität zu einem bestimmten Zeitpunkt ihre Berechnung durch Zurücksuchen, indem alle Attribute ausgewählt werden, die vom speziellen (nicht festgelegten) Wert abweichen.

Bei der Ausgabe von Operation U sollte das System prüfen, ob für diese Entität Operation A vorhanden ist, und, falls diese nicht vorhanden ist, die Art der Operation in A ändern.

Operation D schließt die Existenz einer bestimmten Entität, und wenn nach dieser Operation Attributwerte für diese Entität mit einem relevanten Punkt angefordert werden, sollten die Werte "nicht festgelegt" für alle Attribute dieser Entität zurückgegeben werden. Bei der Ausgabe von Operation D sollte das System prüfen, ob für diese Entität Operation A vorhanden ist, und, falls diese nicht vorhanden ist, das Speichern des Befehls D ablehnen.

Als zusätzliche Funktion können Sie mit dieser Operationsstruktur die Speicherung einer Entität mit derselben ID mit unterschiedlichen Attributen zu unterschiedlichen Zeitpunkten organisieren, nicht nur basierend auf Attributen, sondern auch auf der gesamten Entität. Das heißt, wir können mehrere AN * UD-Blöcke haben, in denen die Entität existiert, und zwischen D und A existiert sie nicht.

Service-Operationen

Servicevorgänge können vielfältig sein und ihre Zusammensetzung kann wieder aufgefüllt werden. Als Beispiel können verschiedene Überlegungen angestellt werden:

1. Operation "N" ist eine ungültige Operation - diese Operation muss vom System ignoriert werden. Sie können andere Arten von Vorgängen in N ändern, um sie von der Arbeit auszuschließen.
2. Operation "C" -Cache - Diese Operation kann mit einer bestimmten Häufigkeit erstellt werden und Attributwerte zu einem bestimmten Zeitpunkt speichern, um die Kosten für die eingehende Suche nach Attributwerten zu senken. Details der Betriebsparameter können beispielsweise in einem Kommentar oder im Operationscode selbst gespeichert werden. Natürlich sollten bei Anwendung grundlegender Operationen Operationen vom Typ C neu berechnet oder durch N ersetzt werden.
3. Operation "S" -Gruppenoperationen - Diese Operation kann mit einer bestimmten Häufigkeit erstellt werden und Gruppenwerte (z. B. Summen, Durchschnittswerte usw.) von Attributen numerischer Typen für einen bestimmten Zeitraum speichern. Details der Betriebsparameter können beispielsweise in einem Kommentar oder im Operationscode selbst gespeichert werden. Wenn grundlegende Operationen angewendet werden, sollten Operationen vom Typ S natürlich neu berechnet oder durch N ersetzt werden.
4. Operation "G" -Gruppenattribute - Diese Operation kann U ähnlich sein, aber gleichzeitig geben bestimmte Systembefehle nicht einen, sondern mehrere Attributwerte aus. Ein Attributwert pro Operation A / U, die verbleibenden Werte - bei Operation G, die sich zwischen benachbarten A / U befinden.

Servicevorgänge sind optional, können jedoch dem Speichersystem zusätzlichen Service bieten und dessen Leistung verbessern. Ihre Zusammensetzung kann für verschiedene Systeme unterschiedlich sein.