Softwarentwicklung
Agile Softwareentwicklung
Klassische Softwareentwicklungsmethoden wie das Wasserfallmodell setzen darauf, zu Anfang eines Projekts genau die Anforderungen etwa in einem Pflichtenheft festzuhalten, nach denen die Software entwickelt wird. Dies ist eine nicht ganz unerhebliche Aufgabe, da sich genaue Anforderungen für den Einsatz am Markt mitunter zu Projektstart noch nicht bis ins letzte Detail definieren lassen.Agile Softwareentwicklung hingegen setzt darauf, so früh wie möglich ein laufendes System auszuliefern. das dann in Iterationen und basierend auf dem Feedback des Nutzers immer weiter entwickelt wird.
Manifest für Agile Softwareentwicklung
Ausgangslage
Eine immer wieder gewünschte Funktion unserer Kunden war die Möglichkeit beim Betrieb eines ERP-Systems,
aktuelle und oder historische Daten aus der Datenbank in eine Testumgebung zu überspielen.
Natürlich gibt es dazu auch Datenbank interne Mechanischem welche die Daten von DB-A nach DB-B synchronisieren.
Der Einsatz solcher Funktionen ist immer mit Definitionsaufwand und Pflege der Installation verbunden.
Hauptproblem bei der ganzen Thematik war und ist, die Performance! Also mit welcher Geschwindigkeit werden Daten von A nach B Transferiert.
Es musste möglich sein, mindestens einen Insert (MS-SQL) von ca. 1000 Records p/Sekunde zu erreichen.
Ausserdem sollte es möglich sein einfache INSERT, UPDATE und DELETE Operationen auf einer Tabelle auszuführen,
damit kleinere manuelle Datenmanipulationen möglich sind, ohne grosse SQL-Scripts und Prozeduren zu Erstellen und Auszuführen.
Ziel
Es sollte also eine Funktion oder besser eine Applikation geschaffen werden,
mit welcher einzelne und/oder alle Tabellen einer Datenbank von einem System zum anderen transferiert werden können.
Auch die Basis der Datenbank-Plattform soll möglichst variabel bleiben, wie AS/400 DB2, MS-SQL, Oracle oder My-SQL.
Die gesamten Operationen im Data-Base Clone-Tool sollen auf den vorhandenen Meta-Daten der Herkunfts,
sowie der Zieldatenbank basieren. Also keine aufwendigen Definitionsarbeiten und keine Programmierkenntnisse sind von Nöten.
Eigentlich muss es möglich sein per Drag & Drop die gewünschten Objekte (Tabellen) von der Herkunft zum Ziel zu Klonen.
Der primäre Fokus muss auf das Thema Performance gelegt werden. Wie können möglichst schnell grosse Datenmenge von A nach B transferiert werden.
Ausgehend von Analysen und Prototypen muss zwingend Parallel-Processing eingesetzt werden,
nur so kann eine Leistungssteigerung erzielt werden welche durch den Einsatz der Hardware beeinflusst werden kann.
Als Zusatz muss es möglich sein einfache manuelle Datenbankoperation per Dialog ausführen zu können.
Realisierung
Hauptdialog der Applikation ist in zwei Hälften aufgeteilt, eine Herkunft und eine Ziel – Instanz.
Natürlich können auch Tabellen von der selben Instanz verglichen werden. Klone-Operation in der gleichen Instanz sind nicht möglich.
Die Hauptaufgabe der Anwendung, das Klonen von Tabellen und Daten steht auf der Stufe Instanz und Tabelle zur Verfügung.
Auf Stufe Instanz können einzelne Tabellen für die verschiedenen Funktionen selektiert werden.
Damit in einer grossen Menge von Tabellen nicht bei jedem Lauf die Selektion neu gemacht werden muss,
können die Einstellungen jeweils gespeichert werden.
Zudem ist das Dialog auch direkt ein LOG-Protokoll welches einzelne Resultate aus der Verarbeitung speichert.
Messungen während der Prototypenphase haben gezeigt, dass es ohne Parallel-Processing nicht gehen kann.
Je nach Ausstattung des Systems (Prozessoren / Kerne) kann die Transferleistung stark vergrössert werden.
Für das Kopieren der Daten vom Herkunft zum Zielsystem stehen 4 Varianten zur Verfügung:
| Methode | Beschreibung |
|---|---|
| Copy Data (Standard / Sequentiell) | Es werden alle selektierten Tabellen nacheinander Verarbeitet. |
| Copy Data V.-1.0 (Parallel) | Die Logik für DataReader (FROM) und der BulkInsert (TO) ist getrennt. Der Data-Reader wird direkt im Parallel-Process Start ausgeführt, und als Referenz an den BulkInsert-Process übergeben. MS-SQL Schema-Struktur ist verfügbar. (Implementierung in DataBaseParallel-Klasse) |
| Copy Data V.-2.0 (Parallel) | Der DataReader (FROM) und der BulkInsert (TO) in einer Methode implementiert, welche durch den Parallel-Process (TASK) gestartet wird. Pro Task sind also alle Operation gekapselt und Threadsicher implementiert. MS-SQL Schema-Struktur ist verfügbar. (Implementierung in DataBaseParallel-Klasse) |
| Copy Data V.-3.0 (Parallel) | Der DataReader (FROM) und der BulkInsert (TO) in einer Methode implementiert, welche durch den Parallel-Process (TASK) gestartet wird. Pro Task sind also alle Operation gekapselt und Threadsicher implementiert. MS-SQL Schema-Struktur ist verfügbar. Absoluter Vorteil dieser Methode ist, dass sogar einzelne Tabellen durch mehrere WHERE-Bedingungen auf einzelne Task aufgeteilt werden. Dadurch werden auch grosse Datenmengen in einzelnen Tabellen auf mehrere Task aufgeteilt. (IDataBase-Interface / DataBase-Klasse) |
Bei einer Menge n Tabellen mit wenig Datensätzen und einer oder mehreren Tabellen mit grossen Mengen an Datensätzen
ist der Parallel-Prozess pro Tabelle nicht wirklich schnell,
daher wurde in der V.-3.0 Version die Möglichkeit implementiert dass pro Tabelle mehrere WHERE-Klauseln definiert
werden können die dann ebenfalls in einem eigenen Task ausgeführt werden.
Das Beispiel zeigt die Detail WHERE-Schlaufen für die Tabelle EB1600. Ist keine solche Definition vorhanden, wird die Tabelle als Ganzes an einen Task übergeben.
Das Dialog-Bild welches die Optionen und Varianten bei der Klone-Operation zeigen.
Schnellster je gemessener Datentransfer von AS/400 DB2 nach Microsoft SQL brachte eine INSERT-Rate auf dem SQL-Server von ca. 7800 Datensätzen pro Sekunde. Hardware-Basis 1 Prozessor mit 4 Kernen und 16 GB Memory.