Was ist eigentlich SQL Server Performance? Und überhaupt?
Neulich wurde ich gefragt, was ich denn die letzten Monate so gemacht hätte. Es wäre ja recht ruhig um mich herum geworden.Keine Sorge! Natürlich bin ich dem Microsoft SQL Server und der Data Platform treu geblieben, auch wenn ich wieder öfters über den Tellerrand blicken durfte.
Womit habe ich mich also die letzten Monate so beschäftigt?
Zum einen bin ich in letzter Zeit immer wieder jenseits der reinen Vermittlung von technischen Features unterwegs. Vielmehr zeigt sich, dass unsere Kunden davon profitieren, dass wir unsere Technologie- und Projekt-Erfahrung in vermittelbare Konzepte und Prinzipien überführt haben. Also neben dem “Was gibt es?” kommen wir im Rahmen unserer Methoden Schulungen immer häufiger auf das “Warum?” und “Wie im Team?” zu sprechen.
Zum anderen führen wir immer mehr Microsoft Kunden an die “neuen” Themen heran. Wir konzentrieren uns dabei zurzeit auf Azure IaaS und In-Memory OLTP. Wesentlich für uns ist dabei wiederum die Einsicht, dass die reine Vermittlung von Features wenig Wirkung in den Abteilungen (DEV/DBA) zeigt. Daher haben wir diese Technologien in unsere Methoden Welt integriert, um eine möglichst hohe Wirtschaftlichkeit für Microsoft Kunden zu erreichen.
Performance?
Konkret ging das dabei häufig um Fragestellungen rund um die Performance von SQL Server Applikationen. Im Rahmen dieser Tätigkeiten zeigte sich, dass der Begriff Performance oft nur sehr schwammig definiert ist.
Es soll halt schneller werden! Nur mit so einer Aussage bzw. so einem Ziel lässt sich in einem Projekt (agil oder nicht) wenig erreichen.
Vielmehr zeigte sich, dass es diverse Sichtweisen auf die Verfügbarkeit und Performance von Lösungen gibt, welche einen oder mehrere SQL Server nutzen.
Unteranderem distanziere ich mich immer mehr von dem Begriff des häufig bemühten “Tunings”, da es sowohl Entwicklern als auch Budget Verantwortlichen suggeriert, dass ein schlechtes Design später noch durch “ein paar zusätzliche Indizes” zu retten sei.
Mittlerweile offerieren wir hier eine Methode, welche wir als “PSG Performance Driven Development” (PSG PDD) bezeichnen.
Neben der Vermittlung von grundlegenden Fakten über die Funktionsweise der relationalen Datenbank Engine, setzen wir auch einen deutlichen Schwerpunkt auf die Planbarkeit der Verfügbarkeit einer Lösung im späteren Betrieb. Innerhalb von Entwicklungsteams benennen wir Rollen, welche u.a. für die kontinuierliche Durchführung von realistischen Lasttests der Lösung verantwortlich sind.
Ein wenig dazu habe ich bereits in meinen Vorträgen zu dem Thema “7 wichtige Fakten, die jeder Entwickler über den SQL Server wissen sollte” in den Usergroups gezeigt.
Neben Technologie Knowhow und Methoden Kompetenz spielen auch weitere Entwicklungswerkzeuge eine Rolle bei PSG PDD. Dazu gleich noch mehr.
Komplexität?
Da die Nutzung von immer mehr Möglichkeiten im SQL Server und den verwandten Microsoft Diensten auch zu einer deutlichen Steigerung der Komplexität von Lösungen und Umgebungen führen, haben wir uns über die letzten Jahrzehnte auch immer wieder dieses Themas annehmen müssen. Der Reduzierung von Komplexität bei gleichzeitiger Steigerung der Wirksamkeit innerhalb der Prozesse und Wirtschaftlichkeit in der Betreuung.
Als Beispiel sei ein Projekt kurz beschrieben, welches wir schon vor gut einem Jahrzehnt durchführten. Damals sprach uns die Microsoft an, ob wir bei einem internationalem Konzernkunden unterstützen können, welcher eine komplexe Data Management Lösung auf über 1000 SQL Servern weltweit betrieben hat. Es stellte sich schnell heraus, dass die existierende Lösung quasi nicht mehr zu kontrollieren war. Dennoch musste der Betrieb aufrecht erhalten werden, da ein Neudesign auf Basis anderer Technologien und Konzepte nicht möglich war.
Ein klassischer Fall.
Wir haben damals einen Lösungsansatz zum Einsatz gebracht, welchen wir bereits in anderen Projekten erfolgreich eingesetzt haben. Wir nahmen die Umgebung und überführten diese in ein mehrstufiges Repository. Damit nahmen wir sehr viel Komplexität aus dem eigentlichen Betrieb und schufen Werkzeuge, welche die Umgebung zum Teil auch selbständig überwachten und Probleme sofort von sich aus löste.
Diese Methoden haben wir über die Jahre hinweg weiter entwickelt und vielfach eingesetzt. Mittlerweile nennen wir die Muster und Methoden “PSG Repository Driven Design” (PSG RDD).
Zum Teil zeigte ich bereits vor einigen Jahren Muster aus dieser Methode in meinem Vortrag “The Developer Side of the Microsoft Business Intelligence stack”. Wobei die RDD Methode bei weitem nicht nur in Business Intelligence Projekten zum Einsatz gekommen ist.
In letzter Zeit konnten wir damit u.a. komplexe ELT Strecken für Kunden realisieren. Des Weiteren kam die Methoden bei einem umfangreichen Banken Projekt zum Einsatz, um eine über Jahrzehnte gewachsene SQL Server Umgebung wieder unter Kontrolle zu bekommen.
Häufig nutzen wir RDD auch, um umfangreichen Replikationstopologien zu verwalten oder auch, um ebenso große Change Data Capture (CDC) Implementierungen wieder verwaltbar zu gestalten.
Für uns ist dieser deskriptive Ansatz zur Verwaltung von Datenbanken und Servern mittlerweile alltäglich geworden.
Deskriptive IT mit Azure
Damit kommen wir zu einem weiteren Thema mit dem wir uns in letzter Zeit immer intensiver beschäftigt haben: Der Cloud. Speziell natürlich Microsoft Azure.
Gerade das Thema Azure IaaS ist für uns zurzeit sehr interessant. Sowohl für PSG PDD als auch für PSG RDD nutzen wir immer häufiger auch Komponenten in Azure, um temporär notwendige Ressourcen kostengünstig und schnell zu allokieren.
Azure IaaS ist für uns deskriptive IT in Reinform und lässt sich damit ganz hervorragend in unsere Methoden Welt integrieren.
Als ein Beispiel sei die automatische Provisionierung und Deprovisionierung von Umgebungen in Azure für automatische Lasttests genannt, um kontinuierlich die Belastbarkeit von Lösungen zu prüfen und zu dokumentieren. Damit passt Azure auch sehr gut zu unserem Performance Driven Development Ansatz. Selbst wenn die eigentliche Entwicklung und auch der Betrieb der Lösung zurzeit noch on-prem stattfindet.
Dokumentation vs. Inventarisierung
Als ein letztes Thema, welches mich die letzten Monate stark in Beschlag genommen hat, sei noch Dokumentation von SQL Server Umgebung und Applikationen genannt.
Häufig werden wir aufgefordert, um im Auftrag eines Kunden eine Software Entwicklung zu auditieren (extern oder auch intern). Dabei geht es u.a.um die Skalierbarkeit der Lösung hinsichtlich Performance und Ausfallsicherheit.
Einer häufigsten Gründe für eine Einbeziehung unseres Hauses ist der kontinuierliche Wunsch des Software Lieferanten nach immer größerer Hardware, da ja auch die Datenmenge stetig wächst.
Dem muss ich entgegensetzen, dass meiner Meinung nach die Größe einer Datenbank keinen Einfluss auf die Performance einer Lösungen haben sollte. Falls dem so ist, dann lässt dieses meist auf technische Schulden im Design der Lösung schließen.
Ähnlich steht es um die Anzahl von gleichzeitigen Anwendern, wobei ich dieses Argument noch ein klein wenig mehr nachvollziehen kann, da die wenigsten Entwicklungsteams bisher die Möglichkeiten hatten, um echte Lasttests zu fahren.
Bei diesen Audits stellen wir immer wieder fest, dass das Thema Dokumentation und Nachvollziehbarkeit stiefmütterlich betrieben wird. Herausforderungen wie die Planbarkeit von Verfügbarkeit oder gar DevOps rücken damit oft in weite Ferne.
Daher wurden wir aufgefordert Vorschläge zu unterbreiten, wie diesem Mängeln zu begegnen sei. Die daraus entstandenen Dokumentationskonzepte sind wiederum aufgegangen in PSG PDD als auch im PSG RDD.
Eigene Werkezuge
Wie bereits angedeutet, haben wir uns auch mit interner Software Entwicklung beschäftigt.
Dabei haben wir einen Tool Stack entwickelt, welcher sowohl die Performance als auch die Repository Konzepte unterstützt.
Es handelt sich hier um eine Sammlung von Monitoring Werkzeugen, welche unseren PDD Ansatz nahtlos unterstützen. Dazu kommen Werkzeuge für Lasttests, welche sich auch ganz hervorragend in Azure betreiben lassen, um wirklich realistische Last regelmäßig auf einer in der Entwicklung befindlichen Lösung zu erzeugen.
Diese Tools kamen bereits erfolgreich bei einigen unserer größeren Kunden bzw. komplexeren Projekte zum Einsatz.
Wie geht es weiter?
In den nächsten Wochen möchte ich die ruhige Sommerzeit nutzen, um das eine oder andere Thema mal wieder im Detail zu erläutern und der SQL Server Community damit auch wieder Anregungen aus meinem Alltag zu geben.