AWS Blu Age Blush

Auf Mainframe-Systemen (im Folgenden als „Legacy“ bezeichnet) werden Geschäftsdaten häufig mithilfe von VSAM (Virtual Storage Access Method) gespeichert. Die Daten werden in „Datensätzen“ (Byte-Arrays) gespeichert, die zu einem „Datensatz“ gehören.

Es gibt vier Datensatzorganisationen:

• KSDS: Datensätze mit Schlüsselsequenz — Datensätze werden anhand eines Primärschlüssels (keine doppelten Schlüssel zulässig) und optional durch zusätzliche „alternative“ Schlüssel indexiert. Alle Schlüsselwerte sind Teilmengen des Datensatz-Byte-Arrays, wobei jeder Schlüssel wie folgt definiert ist:

  • ein Offset (0-basiert, 0 ist der Anfang des Inhalts des Datensatz-Byte-Arrays, gemessen in Byte)

  • eine Länge (ausgedrückt in Byte)

  • ob es doppelte Werte toleriert oder nicht

• ESDS: Datensätze mit Eingangssequenz — auf Datensätze wird meistens sequentiell zugegriffen (basierend auf ihrer Einfügungsreihenfolge im Datensatz), es können jedoch zusätzliche alternative Schlüssel verwendet werden;

• RRDS: Relative Datensätze — der Zugriff auf Datensätze erfolgt über „Sprünge“, d. h. unter Verwendung relativer Datensatznummern; die Sprünge können entweder vorwärts oder rückwärts erfolgen;

• LDS: Lineare Datensätze — da gibt es keine Datensätze, sondern lediglich einen Bytestrom, der in Seiten organisiert ist. Wird hauptsächlich für interne Zwecke auf älteren Plattformen verwendet.

Bei der Modernisierung älterer Anwendungen mithilfe des AWS Blu Age-Refactoring-Ansatzes sind modernisierte Anwendungen nicht mehr für den Zugriff auf VSAM-gespeicherte Daten vorgesehen, wobei die Datenzugriffslogik beibehalten wird. Die Blusam-Komponente ist die Antwort: Sie ermöglicht den Import von Daten aus veralteten VSAM-Datensätzen, bietet eine API für die modernisierte Anwendung, um sie zu bearbeiten, sowie eine spezielle Verwaltungs-Webanwendung. Siehe AWS Blu Age Blusam Verwaltungskonsole.

Anmerkung

Blusam unterstützt nur KSDS, ESDS und RRDS.

Die Blusam-API ermöglicht die Beibehaltung der Datenzugriffslogik (sequentielle, zufällige und relative Lesevorgänge; Datensätze einfügen, aktualisieren und löschen), wohingegen die Komponentenarchitektur, die auf einer Mischung aus Caching-Strategien und RDBMS-basiertem Speicher basiert, I/O-Operationen mit hohem Durchsatz und begrenzten Ressourcen ermöglicht.

Blusam-Infrastruktur

Blusam verwendet PostgreSQL RDBMS für die Speicherung von Datensätzen, sowohl für Rohdaten als auch für Schlüsselindizes (falls zutreffend). Die bevorzugte Option ist die Verwendung der Amazon Aurora PostgreSQL-kompatiblen Engine. Die Beispiele und Abbildungen in diesem Thema basieren auf dieser Engine.

Anmerkung

Beim Serverstart prüft die Blusam-Laufzeit, ob einige obligatorische technische Tabellen vorhanden sind, und erstellt sie, falls sie nicht gefunden werden können. Folglich müssen der Rolle, die in der Konfiguration für den Zugriff auf die Blusam-Datenbank verwendet wurde, die Rechte zum Erstellen, Aktualisieren und Löschen der Datenbanktabellen (sowohl der Zeilen als auch der Tabellendefinitionen selbst) gewährt werden. Hinweise zur Deaktivierung von Blusam finden Sie unter. Blusam-Konfiguration

Caching

Zusätzlich zum Speicher selbst arbeitet Blusam schneller, wenn es an eine Cache-Implementierung gekoppelt ist.

Derzeit werden zwei Cache-Engines EhCache und Redis unterstützt, von denen jede ihren eigenen Anwendungsfall hat:

• EhCache : Eigenständiger eingebetteter flüchtiger lokaler Cache

  • NICHT für die Bereitstellung einer verwalteten Umgebung mit AWS Mainframe-Modernisierung geeignet.

  • Wird in der Regel verwendet, wenn ein einzelner Knoten, z. B. ein einzelner Apache Tomcat-Server, für die Ausführung der modernisierten Anwendungen verwendet wird. Beispielsweise kann der Knoten für das Hosten von Batch-Job-Aufgaben vorgesehen sein.

  • Flüchtig: Die EhCache Cache-Instanz ist flüchtig; ihr Inhalt geht verloren, wenn der Server heruntergefahren wird.

  • Eingebettet: Der EhCache und der Server teilen sich denselben JVM-Speicherplatz (muss bei der Definition der Spezifikationen für den Hostcomputer berücksichtigt werden).

• Redis: Gemeinsamer persistenter Cache

  • Geeignet für die Bereitstellung einer verwalteten Umgebung im AWS Rahmen der Mainframe-Modernisierung.

  • Wird in der Regel in Situationen mit mehreren Knoten verwendet, insbesondere wenn sich mehrere Server hinter einem Load-Balancer befinden. Der Cache-Inhalt wird von allen Knoten gemeinsam genutzt.

  • Redis ist persistent und nicht an die Lebenszyklen der Knoten gebunden. Es läuft auf einem eigenen Computer oder Dienst (z. B. Amazon ElastiCache). Der Cache ist von allen Knoten aus erreichbar.

Sperren

Um den gleichzeitigen Zugriff auf Datensätze und Aufzeichnungen zu bewältigen, setzt Blusam auf ein konfigurierbares Schließsystem. Das Sperren kann auf beide Ebenen angewendet werden: auf Datensätze und Datensätze:

• Das Sperren eines Datensatzes für Schreibzwecke verhindert, dass alle anderen Clients Schreiboperationen auf dieser Ebene (Datensatz oder Datensatz) ausführen.

• Das Sperren auf Datensatzebene für Schreibvorgänge verhindert, dass andere Clients Schreiboperationen nur für den angegebenen Datensatz ausführen.

Die Konfiguration des Blusam-Sperrsystems sollte entsprechend der Cache-Konfiguration erfolgen:

• Wenn diese EhCache Option als Cache-Implementierung ausgewählt wird, ist keine weitere Sperrkonfiguration erforderlich, da das standardmäßige In-Memory-Sperrsystem verwendet werden sollte.

• Wenn Redis als Cache-Implementierung ausgewählt wird, ist eine Redis-basierte Sperrkonfiguration erforderlich, um den gleichzeitigen Zugriff von mehreren Knoten aus zu ermöglichen. Der für Sperren verwendete Redis-Cache muss nicht derselbe sein wie der, der für Datensätze verwendet wird. Hinweise zur Konfiguration eines Redis-basierten Schließsystems finden Sie unter. Blusam-Konfiguration

Intrinsics von Blusam und Datenmigration aus älteren Versionen

Speichern von Datensätzen: Datensätze und Indizes

Jeder Legacy-Datensatz wird, wenn er in Blusam importiert wird, in einer speziellen Tabelle gespeichert. Jede Zeile der Tabelle steht für einen Datensatz mit zwei Spalten:

• Die numerische ID-Spalte vom Typ Big Integer, das ist der Primärschlüssel der Tabelle und wird verwendet, um die Relative Byte-Adresse (RBA) des Datensatzes zu speichern. Die RBA stellt den Offset in Byte vom Anfang des Datensatzes dar und beginnt bei 0.

• Die Byte-Array-Datensatzspalte, in der der Inhalt des Rohdatensatzes gespeichert wird.

Sehen Sie sich zum Beispiel den Inhalt eines KSDS-Datensatzes an, der in der CardDemo Anwendung verwendet wird:

• Dieser spezielle Datensatz hat Datensätze mit fester Länge, deren Länge 300 Byte beträgt (daher ist die Sammlung von IDs ein Vielfaches von 300).

• Standardmäßig zeigt das pgAdmin-Tool, das zur Abfrage von PostgreSQL-Datenbanken verwendet wird, keine Byte-Array-Spalteninhalte an, sondern gibt stattdessen ein [Binärdaten] -Label aus.

• Der Inhalt des Rohdatensatzes entspricht dem Rohdatensatz-Export aus der Legacy-Version, ohne dass eine Konvertierung erforderlich ist. Insbesondere findet keine Zeichensatzkonvertierung statt. Das bedeutet, dass alphanumerische Teile des Datensatzes von modernisierten Anwendungen unter Verwendung des alten Zeichensatzes, höchstwahrscheinlich einer EBCDIC-Variante, dekodiert werden müssen.

Was die Metadaten des Datensatzes und die Schlüsselindizes angeht: Jeder Datensatz ist mit zwei Zeilen in der genannten Tabelle verknüpft. metadata Dies ist die Standardbenennungskonvention. Informationen zur Anpassung finden Sie unterBlusam-Konfiguration.

• Die erste Zeile hat den Datensatznamen als Wert der Namensspalte. Die Metadatenspalte ist eine binäre Spalte, die eine binäre Serialisierung der allgemeinen Metadaten des angegebenen Datensatzes enthält. Details hierzu finden Sie unter Allgemeine Metadatenattribute von Datensätzen.

• Die zweite Zeile enthält den Datensatznamen mit dem Suffix __internal' als Wert der Namensspalte. Der binäre Inhalt der Metadatenspalte hängt vom „Gewicht“ des Datensatzes ab.

  • Bei kleinen/mittleren Datensätzen ist der Inhalt eine komprimierte Serialisierung von:

    • Definition der vom Datensatz verwendeten Schlüssel; die Primärschlüsseldefinition (für KSDS) und gegebenenfalls alternative Schlüsseldefinitionen (für KSDS/ESDS)

    • gegebenenfalls die Schlüsselindizes (KSDS/ESDS mit alternativen Schlüsseldefinitionen): werden für das indizierte Durchsuchen von Datensätzen verwendet; der Schlüsselindex ordnet der RBA eines Datensatzes einen Schlüsselwert zu;

    • Längenübersicht der Datensätze: wird für das sequentielle bzw. relative Durchsuchen von Datensätzen verwendet;

  • Bei großen/sehr großen Datensätzen handelt es sich bei dem Inhalt um eine komprimierte Serialisierung von:

    • Definition der vom Datensatz verwendeten Schlüssel; die Primärschlüsseldefinition (für KSDS) und gegebenenfalls alternative Schlüsseldefinitionen (für KSDS/ESDS)

Darüber hinaus werden Indizes für große/sehr große Datensätze (falls zutreffend) mithilfe eines Paginierungsmechanismus gespeichert; binäre Serialisierungen von Indexseiten werden als Zeilen einer eigenen Tabelle gespeichert (eine Tabelle pro Datensatzschlüssel). Jede Indexseite wird in einer Zeile mit den folgenden Spalten gespeichert:

• id: technische Kennung der Indexseite (numerischer Primärschlüssel);

• firstkey: Binärwert des ersten (niedrigsten) Schlüsselwerts, der auf der Indexseite gespeichert ist;

• lastkey: Binärwert des letzten (höchsten) Schlüsselwerts, der auf der Indexseite gespeichert ist;

• Metadaten: binär komprimierte Serialisierung der Indexseite (Zuordnung von Schlüsselwerten zu Datensätzen). RBAs

Der Tabellenname ist eine Verkettung des Datensatznamens und des internen Schlüsselnamens. Er enthält Informationen über den Schlüssel, z. B. den Schlüsselversatz, ob der Schlüssel Duplikate akzeptiert (auf true gesetzt, um Duplikate zuzulassen) und die Schlüssellänge. Stellen Sie sich zum Beispiel einen Datensatz mit dem Namen "AWS_LARGE_KSDS“ vor, der die folgenden zwei definierten Schlüssel hat:

• Primärschlüssel [Offset: 0, Duplikate: falsch, Länge:18]

• Alternativschlüssel [Offset: 3, Duplikate: wahr, Länge: 6]

In diesem Fall speichern die folgenden Tabellen die Indizes, die sich auf die beiden Schlüssel beziehen.

Optimierung des I/O-Durchsatzes mithilfe des Write-Behind-Mechanismus

Um die Leistung von Einfüge-/Aktualisierungs- und Löschvorgängen zu optimieren, stützt sich die Blusam-Engine auf einen konfigurierbaren Write-Behind-Mechanismus. Der Mechanismus basiert auf einem Pool von dedizierten Threads, die Persistenzoperationen mithilfe von Abfragen für Massenaktualisierungen durchführen, um den I/O-Durchsatz für den Blusam-Speicher zu maximieren.

Die Blusam-Engine sammelt alle Aktualisierungsvorgänge, die von Anwendungen an Datensätzen ausgeführt werden, und erstellt Chargen von Datensätzen, die zur Bearbeitung an die dedizierten Threads weitergeleitet werden. Die Lose werden dann mithilfe von Massenaktualisierungsabfragen dauerhaft im Blusam-Speicher gespeichert, wodurch die Verwendung atomarer Persistenzoperationen vermieden wird und die bestmögliche Nutzung der Netzwerkbandbreite gewährleistet wird.

Der Mechanismus verwendet eine konfigurierbare Verzögerung (standardmäßig eine Sekunde) und eine konfigurierbare Losgröße (standardmäßig 10.000 Datensätze). Die Build-Persistenzabfragen werden ausgeführt, sobald die erste der beiden folgenden Bedingungen erfüllt ist:

• Die konfigurierte Verzögerung ist abgelaufen und das Los ist nicht leer

• Die Anzahl der Datensätze in dem zu behandelnden Los erreicht den konfigurierten Grenzwert

Informationen zur Konfiguration des Write-Behind-Mechanismus finden Sie unter. Optionale Eigenschaften

Das richtige Speicherschema auswählen

Wie im vorherigen Abschnitt gezeigt, hängt die Art und Weise, wie Datensätze gespeichert werden, von ihrem „Gewicht“ ab. Aber was wird für einen Datensatz als klein, mittel oder groß angesehen? Wann sollte man sich für die paginierte Speicherstrategie entscheiden und nicht für die reguläre?

Die Antwort auf diese Frage hängt von den folgenden Faktoren ab.

• Die Menge des verfügbaren Speichers auf jedem der Server, auf denen die modernisierten Anwendungen gehostet werden, die diese Datensätze verwenden werden.

• Die Menge des verfügbaren Speichers in der Cache-Infrastruktur (falls vorhanden).

Bei Verwendung eines Speicherschemas für nicht paginierte Indizes werden beim Öffnen des Datensatzes die vollständigen Sammlungen mit Schlüsselindizes und Datensatzgrößen für jeden Datensatz in den Serverspeicher geladen. Wenn Caching erforderlich ist, können außerdem alle Datensatzdatensätze beim regulären Verfahren vorab in den Cache geladen werden, was zu einer Erschöpfung der Speicherressourcen auf der Seite der Cache-Infrastruktur führen kann.

Abhängig von der Anzahl der definierten Schlüssel, der Länge der Schlüsselwerte, der Anzahl der Datensätze und der Anzahl der gleichzeitig geöffneten Datensätze kann die Menge des verbrauchten Speichers für die gegebenen bekannten Anwendungsfälle grob berechnet werden.

Weitere Informationen hierzu finden Sie unter Schätzung des Speicherbedarfs für einen bestimmten Datensatz.

Blusam-Migration

Sobald das richtige Speicherschema für einen bestimmten Datensatz ausgewählt wurde, muss der Blusam-Speicher durch die Migration älterer Datensätze aufgefüllt werden.

Um dies zu erreichen, muss man rohe Binärexporte der älteren Datensätze verwenden, ohne dass während des Exportvorgangs eine Zeichensatzkonvertierung verwendet wird. Achten Sie bei der Übertragung von Datensatz-Exporten aus dem Altsystem darauf, dass das Binärformat nicht beschädigt wird. Erzwingen Sie beispielsweise den Binärmodus, wenn Sie FTP verwenden.

Die rohen Binärexporte enthalten nur die Datensätze. Für den Importmechanismus ist es nicht erforderlich, keys/indexes exports as all keys/indexes dass sie im laufenden Betrieb durch den Importmechanismus neu berechnet werden.

Sobald ein binärer Export eines Datensatzes verfügbar ist, gibt es mehrere Optionen, ihn nach Blusam zu migrieren:

In der verwalteten AWS Umgebung von Mainframe Modernization:

• Importieren Sie Datensätze mithilfe der speziellen Funktion. Siehe Importieren Sie Datensätze für AWS Mainframe Modernization Anwendungen.

or

• Verwenden Sie die Funktion zum Massenimport von Datensätzen. Siehe AWS Referenz zur Definition von Datensätzen zur Mainframe-Modernisierung und Beispiel für ein Datensatz-Anforderungsformat für VSAM.

or

• Verwenden Sie ein Groovy-Skript, um Datensätze mithilfe spezieller Ladedienste zu importieren.

Anmerkung

Das Importieren von LargeKSDS und LargeESDS in verwalteten Umgebungen mit Mainframe Modernization ist derzeit nur mit Groovy-Skripten möglich.

Auf AWS Blu Age Runtime bei Amazon EC2:

• Importieren Sie den Datensatz mit demAWS Blu Age Blusam Verwaltungskonsole.

or

• Verwenden Sie ein Groovy-Skript, um Datensätze mithilfe spezieller Ladedienste zu importieren.

Importieren Sie Datensätze mithilfe von Groovy-Skripten

In diesem Abschnitt erfahren Sie, wie Sie Groovy-Skripte schreiben, um ältere Datensätze in Blusam zu importieren.

Es beginnt mit einigen obligatorischen Importen:

import com.netfective.bluage.gapwalk.bluesam.BluesamManager
import com.netfective.bluage.gapwalk.bluesam.metadata.Key;
import com.netfective.bluage.gapwalk.rt.provider.ServiceRegistry
import java.util.ArrayList; //used for alternate keys if any

Danach baut der Code für jeden zu importierenden Datensatz auf dem angegebenen Muster auf:

1. ein Kartenobjekt erstellen oder löschen

2. füllen Sie die Karte mit den erforderlichen Eigenschaften (dies variiert je nach Art des Datensatzes — Einzelheiten siehe unten)

3. ruft den richtigen Ladedienst ab, der für die Datensatzart in der Dienstregistrierung verwendet werden soll

4. führe den Dienst aus und verwende dabei die Map als Argument

Es gibt 5 Dienstimplementierungen, die mithilfe der folgenden Bezeichner aus der Dienstregistrierung abgerufen werden können:

• "BluesamKSDSFileLoader": für kleine/mittelgroße KSDS

• "BluesamESDSFileLoader"für kleine/mittelgroße ESDS

• "BluesamRRDSFileLoader": für RRDS

• "BluesamLargeKSDSFileLoader": für große KSDS

• "BluesamLargeESDSFileLoader": für große ESDS

Ob Sie die reguläre oder die große Version des Dienstes für KSDS/ESDS wählen, hängt von der Größe der Datensätze und der Speicherstrategie ab, die Sie dafür anwenden möchten. Informationen zur Auswahl der richtigen Speicherstrategie finden Sie unter. Das richtige Speicherschema auswählen

Um den Datensatz erfolgreich in Blusam importieren zu können, müssen dem Ladedienst die richtigen Eigenschaften zur Verfügung gestellt werden.

Allgemeine Eigenschaften:

• Obligatorisch (für alle Arten von Datensätzen)

  • „BlueSamManager“: Der erwartete Wert ist applicationContext.getBean(BluesamManager.class)

  • „DatasetName“: Name des Datensatzes als Zeichenfolge

  • "inFilePath": Pfad zum Export des Legacy-Datensatzes als Zeichenfolge

  • „RecordLength“: Die feste Datensatzlänge oder 0 für einen Datensatz mit variabler Datensatzlänge als Ganzzahl

• Optional

  • Wird für große Datensätze nicht unterstützt:

    • „isAppend“: ein boolesches Flag, das angibt, dass der Import im Anfügemodus erfolgt (Datensätze werden an einen vorhandenen Blusam-Datensatz angehängt).

    • „useCompression“: ein boolesches Flag, das angibt, dass die Komprimierung zum Speichern von Metadaten verwendet wird.

  • Nur für große Datensätze:

    • "indexingPageSizeInMb": die Größe jeder Indexseite in Megabyte für jeden der Schlüssel des Datensatzes als strikt positive Ganzzahl

Eigenschaften, die von der Art des Datensatzes abhängen:

• KSDS/großes KSDS:

  • mandatory

    • „PrimaryKey“: Die Primärschlüsseldefinition, die einen Konstruktoraufruf verwendet. com.netfective.bluage.gapwalk.bluesam.metadata.Key

  • fakultativ:

    • „alternateKeys“: eine Liste (java.util.List) von alternativen Schlüsseldefinitionen, die mithilfe von com.netfective.bluage.gapwalk.bluesam.metadata.Key Konstruktoraufrufen erstellt wurde.

• ESDS/Große ESDS:

  • fakultativ:

    • „alternateKeys“: eine Liste (java.util.List) von alternativen Schlüsseldefinitionen, die mithilfe von com.netfective.bluage.gapwalk.bluesam.metadata.Key Konstruktoraufrufen erstellt wurde.

• ROTE ZAHLEN:

  • keiner.

Wichtige Konstruktoraufrufe:

• new Key(int offset, int length): erstellt ein Key-Objekt mit bestimmten Schlüsselattributen (Offset und Länge) und erlaubt keine Duplikate. Diese Variante sollte verwendet werden, um einen Primärschlüssel zu definieren.

• new Key(boolean allowDuplicates, int offset, int length): erstellt ein Key-Objekt mit bestimmten Schlüsselattributen (Offset und Länge) und Duplikaten, die ein Flag zulassen.

Die folgenden Groovy-Beispiele veranschaulichen verschiedene Ladeszenarien.

Es wird ein großes KSDS mit zwei alternativen Schlüsseln geladen:

import com.netfective.bluage.gapwalk.bluesam.BluesamManager
import com.netfective.bluage.gapwalk.bluesam.metadata.Key;
import com.netfective.bluage.gapwalk.rt.provider.ServiceRegistry
import java.util.ArrayList;

// Loading a large KSDS into Blusam
def map = [:]
map.put("bluesamManager", applicationContext.getBean(BluesamManager.class));
map.put("datasetName", "largeKsdsSample");
map.put("inFilePath", "/work/samples/largeKsdsSampleExport");
map.put("recordLength", 49);
map.put("primaryKey", new Key(0, 18));
ArrayList altKeys = [new Key(true, 10, 8), new Key(false, 0, 9)]
map.put("alternateKeys", altKeys);
map.put("indexingPageSizeInMb", 25);
def service = ServiceRegistry.getService("BluesamLargeKSDSFileLoader");
service.runService(map);

Laden eines ESDS mit variabler Datensatzlänge ohne alternative Schlüssel:

import com.netfective.bluage.gapwalk.bluesam.BluesamManager
import com.netfective.bluage.gapwalk.bluesam.metadata.Key;
import com.netfective.bluage.gapwalk.rt.provider.ServiceRegistry

// Loading an ESDS into Blusam
def map = [:]
map.put("bluesamManager", applicationContext.getBean(BluesamManager.class));
map.put("datasetName", "esdsSample");
map.put("inFilePath", "/work/samples/esdsSampleExport");
map.put("recordLength", 0);
def service = ServiceRegistry.getService("BluesamESDSFileLoader");
service.runService(map);

Exporte von Datensätzen mit variabler Datensatzlänge enthalten die obligatorischen RDW-Informationen (Record Decriptor Word), damit Datensätze beim Lesen aufgeteilt werden können.

Laden eines RRDS mit fester Datensatzlänge:

import com.netfective.bluage.gapwalk.bluesam.BluesamManager
import com.netfective.bluage.gapwalk.bluesam.metadata.Key;
import com.netfective.bluage.gapwalk.rt.provider.ServiceRegistry

// Loading a RRDS into Blusam
def map = [:]
map.put("bluesamManager", applicationContext.getBean(BluesamManager.class));
map.put("datasetName", "rrdsSample");
map.put("inFilePath", "/work/samples/rrdsSampleExport");
map.put("recordLength", 180);
def service = ServiceRegistry.getService("BluesamRRDSFileLoader");
service.runService(map);

Laden von Datensätzen im Multischema-Modus:

Multischemamodus: In einigen älteren Systemen sind VSAM-Dateien in Dateisätzen organisiert, sodass Programme auf Daten innerhalb bestimmter Partitionen zugreifen und diese ändern können. Moderne Systeme behandeln jeden Dateisatz als Schema und ermöglichen so eine ähnliche Datenpartitionierung und Zugriffskontrolle.

Informationen zum Aktivieren des Multischemamodus in der application-main.yml Datei finden Sie unter. Blusam-Konfiguration In diesem Modus können Datensätze mithilfe eines Shared Contexts, einer speicherinternen Registrierung für Laufzeitinformationen, in ein bestimmtes Schema geladen werden. Um einen Datensatz in ein bestimmtes Schema zu laden, stellen Sie dem Datensatznamen den entsprechenden Schemanamen voran.

Laden einer KSDS-Datei in ein bestimmtes Schema für den Multischemamodus:

import com.netfective.bluage.gapwalk.bluesam.BluesamManager
import com.netfective.bluage.gapwalk.bluesam.metadata.Key;
import com.netfective.bluage.gapwalk.rt.provider.ServiceRegistry
import java.util.ArrayList;
import com.netfective.bluage.gapwalk.rt.shared.SharedContext;

// Loading a KSDS into Blusam
def map = [:]
String schema = "schema1";
String datasetName = schema+"|"+"ksdsSample";
SharedContext.get().setCurrentBlusamSchema(schema);
schema = SharedContext.get().getCurrentBlusamSchema();
map.put("bluesamManager", applicationContext.getBean(BluesamManager.class));
map.put("datasetName", datasetName);
map.put("inFilePath", "/work/samples/ksdsSampleExport");
map.put("recordLength", 49);
map.put("primaryKey", new Key(0, 18));
map.put("indexingPageSizeInMb", 25);
def service = ServiceRegistry.getService("BluesamKSDSFileLoader");
service.runService(map);

Laden einer großen KSDS-Datei in ein bestimmtes Schema für den Multischemamodus:

import com.netfective.bluage.gapwalk.bluesam.BluesamManager
import com.netfective.bluage.gapwalk.bluesam.metadata.Key;
import com.netfective.bluage.gapwalk.rt.provider.ServiceRegistry
import java.util.ArrayList;
import com.netfective.bluage.gapwalk.rt.shared.SharedContext;

// Loading a Large KSDS into Blusam
def map = [:]
String schema = "schema1";
String datasetName = schema+"|"+"largeKsdsSample";
SharedContext.get().setCurrentBlusamSchema(schema);
schema = SharedContext.get().getCurrentBlusamSchema();
map.put("bluesamManager", applicationContext.getBean(BluesamManager.class));
map.put("datasetName", datasetName);
map.put("inFilePath", "/work/samples/LargeKsdsSampleExport");
map.put("recordLength", 49);
map.put("primaryKey", new Key(0, 18));
map.put("indexingPageSizeInMb", 25);
def service = ServiceRegistry.getService("BluesamLargeKSDSFileLoader");
service.runService(map);

Darüber hinaus kann ein Konfigurationseintrag (der in der application-main.yml Konfigurationsdatei festgelegt werden muss) zur Feinabstimmung des Importvorgangs verwendet werden:

• bluesam.fileLoading.commitInterval: eine strikt positive Ganzzahl, die das Commit-Intervall für den regulären ESDS/KSDS/RRDS Importmechanismus definiert. Gilt nicht für Importe großer Datensätze. Der Standardwert ist 100000.

Blusam-Konfiguration

Die Konfiguration von Blusam erfolgt in der application-main.yml Konfigurationsdatei (oder in der application-bac.yml Konfigurationsdatei für die eigenständige Bereitstellung der Blusam Administration Console — BAC — Anwendung).

Blusam muss in zweierlei Hinsicht konfiguriert werden:

• Konfiguration des Blusam-Speichers und des Zugriffs auf Caches

• Konfiguration der Blusam-Engine

Konfiguration des Blusam-Speichers und des Cache-Zugriffs

Informationen zur Konfiguration des Zugriffs auf Blusam-Speicher und -Caches mithilfe von Secrets-Managern oder Datenquellen finden Sie unter. Konfiguration für AWS Blu Age Runtime einrichten

Anmerkung

In Bezug auf den Zugriff auf den Blusam-Speicher verweisen die verwendeten Anmeldeinformationen auf eine Verbindungsrolle mit den entsprechenden Rechten. Damit die Blusam-Engine wie erwartet funktionieren kann, muss die Verbindungsrolle über die folgenden Rechte verfügen:

• stellen Sie eine Verbindung zur Datenbank her

• Tabellen und Ansichten erstellen/löschen/ändern/kürzen

• Zeilen in Tabellen und Ansichten auswählen/einfügen/löschen/aktualisieren

• Funktionen oder Prozeduren ausführen

Konfiguration der Blusam-Engine

Blusam-Unterstützung wird deaktiviert

Lassen Sie uns zunächst erwähnen, dass es möglich ist, die Blusam-Unterstützung vollständig zu deaktivieren, indem Sie die Eigenschaft auf setzen. bluesam.disabled true Beim Start der Anwendung wird in den Serverprotokollen eine Informationsmeldung angezeigt, die an die Deaktivierung von Blusam erinnert:

BLUESAM is disabled. No operations allowed.

In diesem Fall ist keine weitere Konfiguration von Blusam erforderlich, und jeder Versuch, Blusam-bezogene Funktionen zu verwenden (entweder programmgesteuert oder über REST-Aufrufe), führt bei der Ausführung des Java-Codes zu einer Meldung mit einer entsprechenden UnsupportedOperationException Erklärung, dass Blusam deaktiviert wurde.

Eigenschaften der Blusam-Engine

Die Konfigurationseigenschaften der Blusam-Engine sind unter dem Bluesam-Schlüsselpräfix neu gruppiert:

Obligatorische Eigenschaften

• cache: muss mit der ausgewählten Cache-Implementierung bewertet werden. Gültige Werte für sind:

  • ehcache: Für die lokale Verwendung von eingebettetem Ehcache. Die entsprechenden Einschränkungen für Anwendungsfälle finden Sie weiter oben.

  • redis: Für die gemeinsame Remote-Nutzung des Redis-Caches. Dies ist die bevorzugte Option für den verwalteten AWS Anwendungsfall Mainframe-Modernisierung.

  • none: Um das Speicher-Caching zu deaktivieren

• persistence: mit pgsql zu bewerten (PostgreSQL-Engine: Minimalversion 10.0 — empfohlene Version >=14.0

• Datenquellenreferenz: verweist auf <persistence engine>.dataSource die DataSource-Definition für die Verbindung zum Blusam-Speicher, die an anderer Stelle in der Konfigurationsdatei definiert ist. Üblicherweise wird es benannt. bluesamDs

Anmerkung

Immer wenn Redis als Cache-Mechanismus verwendet wird, entweder für Daten oder für Sperren (siehe unten), muss der Zugriff auf die Redis-Instanzen konfiguriert werden. Details hierzu finden Sie unter Verfügbare Redis-Cache-Eigenschaften in AWS Blu Age Runtime.

Optionale Eigenschaften

Blusam Locks: Den Eigenschaften wird das Präfix vorangestellt locks

• cache: Der einzig verwendbare Wert ist die Angaberedis, dass der Redis-basierte Sperrmechanismus verwendet wird (der auch verwendet werden sollte, wenn der Blusam-Storage-Cache auf Redis basiert). Wenn die Eigenschaft fehlt oder nicht auf gesetzt istredis, wird stattdessen der standardmäßige In-Memory-Sperrmechanismus verwendet.

• lockTimeOut: ein positiver Wert vom Typ Long Integer, der die Zeitüberschreitung in Millisekunden angibt, bevor ein Versuch, ein bereits gesperrtes Element zu sperren, als fehlgeschlagen markiert wird. Die Standardeinstellung ist. 500

• locksDeadTime: Ein positiver langer Integer-Wert, der die maximale Zeit, ausgedrückt in Millisekunden, darstellt, für die eine Anwendung gesperrt werden kann. Sperren werden automatisch als abgelaufen markiert und nach Ablauf dieser Zeit wieder freigegeben. Die Standardeinstellung ist; 1000

• locksCheck: eine Zeichenfolge, die verwendet wird, um die vom aktuellen Blusam Lock Manager verwendete Strategie zur Sperrüberprüfung zu definieren, die sich mit dem Entfernen abgelaufener Sperren befasst. Soll aus den folgenden Werten ausgewählt werden:

  • off: Es werden keine Prüfungen durchgeführt. Wir raten davon ab, da tote Sperren auftreten können.

  • reboot: Die Prüfungen werden beim Neustart oder beim Start der Anwendung durchgeführt. Alle abgelaufenen Sperren werden zu diesem Zeitpunkt freigegeben. Dies ist die Standardeinstellung.

  • timeout: Prüfungen werden beim Neustart oder beim Start der Anwendung durchgeführt oder wenn beim Versuch, einen Datensatz zu sperren, ein Timeout abläuft. Abgelaufene Sperren werden sofort aufgehoben.

Write-Behind-Mechanismus: Den Eigenschaften wird ein Schlüssel vorangestellt: write-behind

• enabled: true (Standard- und empfohlener Wert) oderfalse, um den Write-Behind-Mechanismus zu aktivieren oder zu deaktivieren. Die Deaktivierung des Mechanismus beeinträchtigt die Schreibleistung erheblich und es wird davon abgeraten.

• maxDelay: eine maximale Dauer, für die die Threads ausgelöst werden sollen. Der Standardwert ist "1s" (eine Sekunde). Es ist generell eine gute Idee, den Standardwert beizubehalten, es sei denn, dieser Wert muss unter bestimmten Bedingungen angepasst werden. In jedem Fall sollte der Wert niedrig gehalten werden (unter 3 Sekunden). Das Format für die Verzögerungszeichenfolge <time unit> ist: <integer value><optional whitespace><time unit> wobei aus den folgenden Werten ausgewählt werden soll:

  • "ns": Nanosekunden

  • "µs": Mikrosekunden

  • "ms": Millisekunden

  • "s": Sekunden

• threads: die Anzahl der dedizierten Write-Behind-Threads. Die Standardeinstellung ist. 5 Sie müssen diesen Wert an die Rechenleistung des Hosts anpassen, auf dem die Blusam-Engine ausgeführt wird. Es ist nicht relevant, einen viel höheren Wert zu verwenden, in der Hoffnung auf eine Leistungssteigerung, da der limitierende Faktor die Fähigkeit des Speicher-RDBMS sein wird, zahlreiche gleichzeitige Batch-Abfragen zu verarbeiten. Die empfohlenen Werte liegen normalerweise im Bereich von 4 bis 8.

• batchSize: eine positive Ganzzahl, die die maximale Anzahl von Datensätzen in einem Los angibt, die zur Sammelverarbeitung an einen Thread versandt werden. Ihr Wert muss zwischen 1 und 32767 liegen. Die Standardeinstellung ist. 10000 Die Verwendung 1 als Wert macht den Zweck des Mechanismus zunichte, der darin besteht, die Verwendung atomarer Aktualisierungsabfragen zu vermeiden. Der geeignete Mindestwert, den man verwenden kann, ist ungefähr. 1000

Integrierte EhCache Feinabstimmung: Den Eigenschaften wird ein Schlüssel vorangestellt: ehcache

• resource-pool:

  • size: Größe des zugewiesenen Speichers für den eingebetteten Cache, ausgedrückt als Zeichenfolge. Der Standardwert ist "1024MB" (1 Gigabyte). Muss im Hinblick auf den verfügbaren Speicher des Rechners, der die Blusam-Engine hostet, und die Größe der von der Anwendung verwendeten Datensätze angepasst werden. Das Format der Größenzeichenfolge ist: <integer value><optional whitespace><memory unit> wobei <memory-unit> aus den folgenden Werten ausgewählt werden soll:

    • B:Byte

    • KB: Kilobyte

    • MB: Megabyte

    • GB: Gigabyte

    • TB: Terabyte

  • heap: true oderfalse, um anzugeben, ob der Cache JVM-Heap-Speicher verbraucht oder nicht. Der Standardwert ist true (schnellste Option für die Cache-Leistung, aber der Cache-Speicher verbraucht Speicher aus dem JVM-On-Heap-RAM-Speicher). Wenn Sie diese Eigenschaft auf setzen, false wird zum Off-Heap-Speicher gewechselt, der aufgrund des erforderlichen Austauschs mit dem JVM-Heap langsamer ist.

• timeToLiveMillis: Die Dauer (in Millisekunden), für die ein Cache-Eintrag im Cache verbleibt, bevor er als abgelaufen betrachtet und entfernt wird. Wenn diese Eigenschaft nicht angegeben ist, laufen Cache-Einträge standardmäßig nicht automatisch ab.

Eigenschaften der Konfiguration mehrerer Schemas

• multiSchema: false (Standardwert) oder true, um den Multischemamodus für Blusam zu deaktivieren oder zu aktivieren — verfügbar ab Version 4.4.0.

• pgsql:

  • schemas: Eine Liste von Schemanamen, die die Anwendung im Multischema-Modus für Blusam verwenden wird.

  • fallbackSchema: Der Name des Fallback-Schemas für die Verwendung im Multischemamodus. Wenn ein Datensatz im aktuellen Schemakontext nicht gefunden wird, wird dieses Schema für BLUSAM-bezogene Operationen an diesem Datensatz verwendet.

Beispiel für einen Konfigurationsausschnitt:

dataSource:
  bluesamDs:
    driver-class-name: org.postgresql.Driver
    ...
    ...
bluesam:
  locks:
    lockTimeOut: 700
  cache: ehcache
  persistence: pgsql
  ehcache:
    resource-pool:
      size: 8GB
  write-behind:
    enabled: true
    threads: 8
    batchsize: 5000  
  pgsql:
    dataSource : bluesamDs 

Beispiel für einen Konfigurationsausschnitt (mit aktiviertem Multi-Schema-Modus für Blusam):

dataSource:
  bluesamDs:
    driver-class-name: org.postgresql.Driver
    ...
    ...
bluesam:
  locks:
    lockTimeOut: 700
  cache: ehcache
  persistence: pgsql
  ehcache:
    resource-pool:
      size: 8GB
  write-behind:
    enabled: true
    threads: 8
    batchsize: 5000 
  multiSchema: true 
  pgsql:
    dataSource : bluesamDs
    schemas: 
      - "schema1"
      - "schema2" 
      - "schema3"
    fallbackSchema: schema3

Anmerkung

Blusam-Metadatenschemas, einschließlich der in der application-main.yml Datei für den Multischemamodus aufgelisteten Schemas, werden in der Blusam-Datenbank erstellt, wenn sie nicht existieren und der Benutzer über ausreichende Rechte verfügt.

Blusam Administrationskonsole

Die Blusam Administration Console (BAC) ist eine Webanwendung, die zur Verwaltung des Blusam-Speichers verwendet wird. Informationen zum BAC finden Sie unter. AWS Blu Age Blusam Verwaltungskonsole

Anhang

Allgemeine Metadatenattribute von Datensätzen

Liste der allgemeinen Attribute für die Serialisierung von Datensatz-Metadaten:

• Name (des Datensatzes)

• Typ (KSDS, LargeKSDS, ESDS, LargeESDS oder RRDS)

• Cache-Aufwärmkennzeichen (ob der Datensatz beim Serverstart vorab in den Cache geladen werden soll oder nicht)

• Kennzeichen für die Verwendung der Komprimierung (ob Datensätze in einem komprimierten oder unformatierten Format gespeichert werden sollen)

• Erstellungsdatum

• Datum der letzten Änderung

• Datensatzkennzeichnung mit fester Länge (ob die Datensätze alle dieselbe Länge haben oder nicht)

• Datensatzlänge — nur sinnvoll für eine feste Datensatzlänge

• Seitengröße (wird verwendet, um die paginierten SQL-Abfragen anzupassen, die bei Bedarf zum Vorladen des Caches verwendet werden)

• Größe (Größe des Datensatzes — kumulierte Länge der Datensätze)

• letzter Offset (Offset, d. h. RBA des zuletzt zum Datensatz hinzugefügten Datensatzes)

• nächster Offset (nächster verfügbarer Offset zum Hinzufügen eines neuen Datensatzes zum Datensatz)

• falls sinnvoll, Definition der vom Datensatz verwendeten Schlüssel; jeder Schlüssel wird durch seine Art (primär oder Teil der alternativen Schlüsselsammlung) und durch drei Attribute definiert:

  • Offset: Position des Startbytes des Schlüsselwerts im Datensatz;

  • Länge: Länge des Schlüsselwerts in Byte. Somit ist der Schlüsselwert das Byte-Array, das die Teilmenge des Datensatzes darstellt, der an der Position beginnt key offset und an dieser key offset + length - 1 endet;

  • Markierung für erlaubte Duplikate: ob der Schlüssel Duplikate akzeptiert oder nicht (auf true gesetzt, um Duplikate zuzulassen).

Schätzung des Speicherbedarfs für einen bestimmten Datensatz

Bei kleinen bis mittelgroßen Datensätzen werden die Metadaten (Größen und Indizes für verschiedene Schlüssel) vollständig in den Speicher geladen. Um die richtigen Ressourcen für die Maschine zuzuweisen, auf der der Server gehostet wird, auf dem modernisierte Anwendungen ausgeführt werden, muss der Speicherverbrauch ermittelt werden, der durch die Blusam-Datensätze verursacht wird, insbesondere in Bezug auf Metadaten. In diesem Abschnitt werden den betroffenen Betreibern praktische Antworten gegeben.

Die angegebenen Formeln gelten nur für kleine bis mittlere Blusam-Datensätze, nicht für die Speicherstrategie „Large“.

Metadaten von Blusam-Datensätzen

Bei einem Blusam-Datensatz werden die Metadaten in zwei Teile aufgeteilt:

• Kernmetadaten: enthalten globale Informationen über den Datensatz. Der damit verbundene Speicherbedarf kann im Vergleich zu den internen Metadaten als vernachlässigbar angesehen werden.

• interne Metadaten: enthalten Informationen über die Größe der Datensätze und die wichtigsten Indizes. Wenn ein Datensatz nicht leer ist, verbraucht dieser Speicherplatz, wenn er auf den Anwendungsserver geladen wird, der modernisierte Anwendungen hostet. In den folgenden Abschnitten wird detailliert beschrieben, wie der verbrauchte Speicher mit der Anzahl der Datensätze zunimmt.

Berechnung des internen Metadaten-Footprints

Karte mit den Größen der Datensätze

Zunächst speichern die internen Metadaten eine Map, die die Größe jedes Datensatzes (als Ganzzahl) anhand seiner RBA (relative Byte-Adresse — gespeichert als lange Zahl) enthält.

Der Speicherbedarf dieser Datenstruktur beträgt in Byte: 80 * number of records

Dies gilt für alle Arten von Datensätzen.

Indizes

Was die Indizes für den Primärschlüssel von KSDS oder die alternativen Schlüssel sowohl für ESDS als auch für KSDS angeht, hängt die Berechnung des Footprints von zwei Faktoren ab:

• die Anzahl der Datensätze im Datensatz;

• die Größe des Schlüssels in Byte.

Die folgende Grafik zeigt die Größe des Schlüsselindexes pro Datensatz (Y-Achse) basierend auf der Größe des Schlüssels (X-Achse).

Die entsprechende Formel zur Berechnung des Footprints für einen bestimmten Schlüsselindex eines Datensatzes lautet:

index footprint = number of records * ( 83 + 8 (key length / 8))

wobei '/' für die Ganzzahldivision steht.

Beispiele:

• Datensatz 1:

  • Anzahl der Datensätze = 459 996

  • Schlüssellänge = 15 also (Schlüssellänge/8) = 1

  • Index-Footprint = 459 996 * (83 + (8*1)) = 41 859 636 Byte (= ca. 39 MB)

• Datensatz 2:

  • Anzahl der Datensätze = 13 095 783

  • Schlüssellänge = 18 also (Schlüssellänge/8) = 2

  • Index-Footprint = 13 095 783 * (83 + (8*2)) = 1 296 482 517 Byte (= ca. 1,2 GB)

Der gesamte Footprint für einen bestimmten Datensatz ist die Summe aller Footprints für alle Schlüsselindizes und des Footprints für die Größentabelle der Datensätze.

Nehmen wir zum Beispiel den Beispieldatensatz 2, der nur einen einzigen Schlüssel enthält, so lautet der globale Footprint:

• Karte mit den Größen der Datensätze: 13 095 783 * 80 = 1 047 662 640 Byte

• Wichtige Indizes: 1 296 482 517 Byte (siehe oben)

• Gesamtspeicherplatz = 2 344 145 157 Byte (= ca. 2,18 GB)