SQL Azure als Datawarehouse? Am liebsten serverless!
Wir sind große Fans der Möglichkeit, den SQL Server in Azure „serverless“ zu betreiben! Diese Variante hat gegenüber den traditionellen Versionen Basic, Standard, oder Premium, die über eine konstante Menge von DTUs abgerechnet werden, den Vorteil, dass sie dynamisch hoch- und herunterskaliert, je nachdem, wie intensiv sie benutzt werden, und dass dann auch nur über sogenannte „vCores“ genau das an Rechenzeit abgerechnet wird, was man auch genutzt hat. Super!
Wenn man die Azure SQL-Datenbank als Datawarehouse benutzt, ist das natürlich besonders charmant: während der Beladung mit Quelldaten läuft es auf Hochtouren und daher etwas teurer, danach aber ruht es sich den Rest der Nacht kostenlos aus. Dann muss es vielleicht noch mal dynamisch Hochskalieren, wenn die Power BI-Modelle aktualisiert werden, aber ansonsten kostet das DWH nur Geld, wenn der Data Scientist oder der engagierte Power-User selbst direkt mit Power BI die Daten erforscht!
SQL Server automatisches Backup: praktisch, aber kann teuer werden…
Auch diese „Serverless“-Datenbanken sind aber der „normalen“ Backup-Verwaltung von SQL Azure unterworfen; sie werden also permanent gesichert, und diese Backups werden minimal 7 Tage lang aufbewahrt. So sieht das im Azure-Portal aus (Achtung: Man muss beim „SQL Server“ gucken, nicht bei der Datenbank):
Und nun kommt die Herausforderung: Dieses Standard-Backup ist optimiert für OLTP-Datenbanken, denn es ist ein so genanntes „PiTR-Backup“. Das steht für „point-in-time-recovery“, und das heißt wiederum, dass ich die Datenbank jederzeit auf den Stand, wie er zu jedem beliebigen Zeitpunkt in den letzten 7 Tagen (oder länger) bestanden hat, wiederherstellen kann. Ein tolles Angebot, aber dafür ist auch einiges erforderlich: Es wird wöchentlich eine Gesamtsicherung gemacht, alle 12 Stunden ein differenzielles Backup (wo nur alle Änderungen seit dem letzten differenziellen Backup enthalten sind), und alle 5-10 Minuten ein Transaktionslog-Backup (Quelle: https://docs.microsoft.com/en-us/azure/sql-database/sql-database-automated-backups?tabs=single-database). Und damit die Sicherungs-Dateien auch selbst bei Ausfall eines gesamten Azure-Rechenzentrums noch wiederhergestellt werden können, werden sie auf dem recht teuren, geo-redundanten Speicher (RA-GRS) abgelegt!
Normalerweise ist das kein Problem, denn die durchaus merklichen Kosten für diese Backup-Storage sind in einer provisionierten Datenbank, also vom Typ Basic, Standard oder Premium, in den Datenbank-Kosten enthalten! Aber wenn die Datenbank „serverless“ ist, dann muss ich dafür extra zahlen, und die Storage taucht auch unter der Überschrift „RA-GRS“ in meiner Azure-Abrechnung auf.
Dass der benötigte Speicherplatz überraschend groß ist, ist vor allem dann offensichtlich, wenn man die Datenbank als sogenanntes „One-shot DWH“ betreibt, also jede Nacht alle Tabellen leert und dann mit dem neuen Stand komplett wieder befüllt. Natürlich müssen dann sowohl der gelöschte Stand als auch die neu eingefügten Dateien im Backup abgelegt werden, das dadurch sehr schnell um ein Vielfaches größer wird als die Datenbank selbst.
Wie komme ich aus der Kostenfalle? So jedenfalls nicht…
Nun wenn die Datenbank ein „One-shot-DWH“ ist, oder wenn man sie mit verschiedenen Laderoutinen jederzeit komplett aus den Quelldaten wieder befüllen könnte, dann muss man sie eigentlich überhaupt nicht sichern, oder? Dann kann ich eigentlich den oben im Bild zu sehenden Knopf „Remove settings“ drücken, ich warte schlappe 7 Tage ab, bis die letzten Backups „veraltet“ sind, und schwups zahle ich nichts mehr! Die Datenbank verschwindet dann auch einfach aus der Liste unter „Configure policies“.
Aber halt, so einfach ist die Sache nicht! Nach wenigen Minuten startet Microsoft die Instanz wieder und führt ein Backup durch, und danach ist die Datenbank wie der in der Liste und verbraucht Backup-Speicher wie vorher. Ärgerlich, weil uneindeutig und überraschend! Wer sich – wie wir – wünscht, dass man dieses Verhalten auch abschalten können sollte, kann hier seine Stimme dafür abgeben:
Was man nicht gebrauchen kann, sollte wenigstens auch nichts kosten!
Man kann also diese „tausendprozentige“, aufwändige Form der Datensicherung derzeit nicht loswerden. Dann kann man den Preis für etwas, was man (manchmal) gar nicht braucht, ganz einfach drücken: bei fest konfigurierten, „provisionierten“ Azure SQL-Datenbanken sind die Speicherkosten für die Datensicherung inklusive! Dafür sind diese Datenbanken allerdings nicht ganz so flexibel, weil sie sich nicht automatisch hoch- und herunterskalieren. Man muss sich also im Azure-Portal irgendeine Anzahl von „DTU“-Einheiten reservieren lassen, wie hier gezeigt:
Um hier Kosten zu sparen, sollte man natürlich dann permanent die Verwendung von „DTUs“ überwachen und dann die Datenbank auf eine andere, entsprechende Leistungsebene hoch- oder runterskalieren. Mit der PowerShell ist dies zum Beispiel einfach möglich, und es gibt nur eine ganz kurze Unterbrechung dabei (ca. 4 Sekunden)! Anders als bei der super-flexiblen „vCore“-Variante wird man aber eher so vorgehen, dass die Datenbanz z.B. zum Import auf die Stufe S3 skaliert wird, dort vielleicht verbleibt, bis die Power BI-Modelle aktualisiert sind, und dann auf S0 reduziert wird für gelegentliche direkte Abfragen auf den Daten.
Letztendlich ist das eine Rechenaufgabe und abhängig von den Aktionen, die man auf der Datenbank ausführt: ist ein vCore-basiertes Modell sparsamer, aber man zahlt den teuren Backup-Speicherplatz, oder zahlt man mehr für eine provisionierte Datenbank, aber nichts mehr für die Datensicherung. Gottseidank kann man das relativ einfach umschalten, also vielleicht einfach mal ausprobieren!