none
Daten generieren für ext. gehosteten Server -> Welches Prinzip? RRS feed

  • Frage

  • Hi,

    wir generieren immer wieder neu ca. 20mio Datensätze für eine Tabelle in einem extern gehosteten Server.

    Die Frage die sich uns stellt ist die, was schneller und konstruktiver ist:

    Szenario A:

    1. Daten werden direkt im ext. Server geladen

    Szenario B:

    1. Daten werden lokal geladen
    2. BACKUP der DB
    3. Transfer der BAK-Datei zu ext. Server
    4. RESTORE der DB auf ext. Server


    Gruß Hipp


    • Bearbeitet Hipp1010 Mittwoch, 9. Oktober 2019 13:37
    Mittwoch, 9. Oktober 2019 13:34

Alle Antworten

  • Hi,

    da ergeben sich einige weitere Fragen:

    In welcher Frequenz sollen die Daten aktualisiert werden? Stündlich? Täglich? Wöchentlich? ...?

    Besteht die Datenbank nur aus dieser einen Tabelle? Falls nicht: Müssen die restlichen Tabellen erhalten bleiben?

    Wenn ihr die Daten eh erst in die Datenbank laden müsst, könnt ihr das auch gleich auf dem Server machen. Stellt sich die Frage, warum ihr auf die Idee kommt, das lokal zu machen, dann Backup, hochladen, zurückspielen, ...?

    Sind die SQL Server Versionen auf beiden Systemen identisch bzw. hat der externe Server eine höhere SQL Version? (Wenn niedriger, geht es nämlich nicht mit Variante B)


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
    https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport

    Mittwoch, 9. Oktober 2019 13:56
    Moderator
  • Lokal existiert die gleiche DB mit der gleichen Version, geplant wenn nicht identisch, dann höchstens extern. höhere Version.

    Die DB besteht aus einigen Tabellen, doch nur 1 soll täglich in der Nacht aktualisiert werden. Von den Dbs gibt es aber je Kunde eine (ist leider eine Restriktion und unumgängliche Anfoderung der Kunden aktuell), zur Zeit 6 Stück. Soll alles dann einmal in Azure geändert werden, ist aber noch for Future.

    20mio Datensätze über eine die ganze Zeit offene Leitung zu jagen, halte ich für kritischer als 1x eine BAK Datei upzuloaden die volumentechnisch deutlich kleiner ist. Auf dem Server wird dann automatisch diese restored.


    Gruß Hipp

    Mittwoch, 9. Oktober 2019 14:04
  • Hi,

    eine Datenbank ist aber nunmal keine Tabelle. Du kannst auch nicht eine bestimmte Tabelle wiederherstellen, das würde nur gehen, indem Du die Sicherung auf dem Server in eine andere, temporäre Datenbank wiederherstellst und dann die betreffende Tabelle synchronisierst. Ob das nun sinnvoller ist oder nicht, sei dahingestellt.

    Ich ging auch nicht davon aus, dass Du die Datensätze von lokal einzeln zum Server schicken willst. Das macht man dann eher so, dass man die Datenquelle (was auch immer das ist) komprimiert, hochlädt, entpackt und dann auf dem Server importiert. Ginge zwar auch anders, mangels detaillierter Kenntnisse eurer genauen Anforderungen und eurer Umgebung kann ich dazu aber nicht soviel sagen.

    Wenn die 20 Mio. Datensätze in jeder der sechs Online Datenbanken identisch sein sollen, würde ich die Variante mit einer temporären Datenbank auf dem Server und anschließender Übertragung der Daten in die Zieldatenbanken bevorzugen. Ob ich das nun mit einer Sicherung oder einer Importdatei machen würde, hängt davon ab, wie ich das in der betreffenden Infrastruktur am besten automatisieren könnte.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
    https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport

    Mittwoch, 9. Oktober 2019 14:11
    Moderator
  • Mein 1. Vorschlag:
    Als CSV ausgeben, zippen, übertragen, unzippen, Table Truncate, Delete Indexes, Bulk insert, Create Indexes.

    Mein 2. Vorschlag:
    Tabelle mit Änderungstimestamp-Spalte versehen und nur die Sätze, die sich seit letzter Übertragung geändert haben übertragen (Csv,Zip). Im Ziel in neue Tabelle per Bulk insert und dann per Merge in Original einmischen.
    Deletes per Trigger in eine 2. Tabelle kopieren und auf dem Ziel wiederholen.

    Es gibt sicherlich noch mehr Vorschläge, aber 20Mio Sätze, Tendenz ggf. steigend, würde ich nie komplett ersetzen. Zumal das Zielsystem während des Ladens dann wohl kaum zu gebrauchen ist.
    Je nach Umfang (Anzahl Felder, Satzlänge) und Serverleistung kann das schon mal ein paar Stunden benötigen.

    Mittwoch, 9. Oktober 2019 16:07
  • Kurz noch ein paar Infos. Pro Kunde existiert die gleiche DB-Struktur. Je Kunde werden zw. 2 und 20 mio Sätze generiert. Diese werden immer neu generiert, bedingt durch Output von Mutterfirma. Die anderen Tabellen in der DB werden nach dem Import der Hauptdaten alle neu aufgebaut.

    Die lokale DB hat gleiche Struktur, aber nur die Mastertabelle wird neu geladen. Alle anderen Tabellen bleiben leer.

    Deswegen die Idee

    A: lokal laden, dann Komprimieren, Upload, und extern wieder Restore.

    Die Idee nach Erstellung der Rows diese

    B: in CSV zu exportieren, Komprimieren, Upload un dann per Bulk-Insert zu importieren

    Ist evtl. sogar noch schneller und besser.

    Werde wohl alle Varianten versuchen und zeitlich einordnen.


    Gruß Hipp


    • Bearbeitet Hipp1010 Freitag, 11. Oktober 2019 08:53
    • Als Antwort vorgeschlagen Evgenij Smirnov Freitag, 11. Oktober 2019 13:35
    • Nicht als Antwort vorgeschlagen Evgenij Smirnov Freitag, 11. Oktober 2019 14:51
    Freitag, 11. Oktober 2019 08:53
  • Der Save/Restore einer DB ist immer schneller als das Exportieren/Importieren von Millionen von Zeilen.
    Beispiel:
    Der Save/Restore einer 40GB Datenbank dauert bei mir ca. 1,5 Stunden (Save 30 Minuten, Restore 60).
    Der direkte Import per SQL aller Tabellen und Datenzeilen über parallel 4 Tasks dauert ca. 16 Stunden.
    Freitag, 11. Oktober 2019 09:00
  • Der Save/Restore einer DB ist immer schneller als das Exportieren/Importieren von Millionen von Zeilen.
    Beispiel:
    Der Save/Restore einer 40GB Datenbank dauert bei mir ca. 1,5 Stunden (Save 30 Minuten, Restore 60).
    Der direkte Import per SQL aller Tabellen und Datenzeilen über parallel 4 Tasks dauert ca. 16 Stunden.

    30 Minuten, um eine 40GB DB zu sichern? Performant ist das nicht unbedingt. Aber kommt immer auf die Rahmenbedingunen an....

    @Hipp1010:

    Generell, da es einfacher zu handhaben ist, wäre ich aber auch für ein Backup/Restore.

    Der Bulk Copy Weg wäre dann interessant, wenn das initiale Laden auf eine aktuellere Version des SQL Servers erfolgt und die Daten nachher in einer älteren Version landen sollen.

    Wäre auf jeden Fall interessant zu wissen welchen Weg Du nun eingeschlagen hast.

    Gruß Dirk


    May you never suffer the sentiment of spending a day without any purpose

    Donnerstag, 17. Oktober 2019 13:01
  • Da man ja inzwischen alles virtualisiert hat man auf die Rahmenbedingungen nun wirklich keinen Einfluss.
    Hier erfolgt der Save und auch Restore zum Reorg der Datenbank (Defragmentieren und aufräumen) auf derselben virtuellen Disk. Wieviele VM's da auf dem Host noch nebenher laufen kann ich leider nicht sehen.
    Donnerstag, 17. Oktober 2019 13:14
  • Noch haben wir keinen konkreten Weg eingeschlagen. Aber Plan A mit Backup/Upload/Restore wird immer mehr zum Favoriten. backup unserer 40GB-Db dauert ca. 2,5min. Nicht so besonders, aber ok.

    Aber wir sind noch dran.


    Gruß Hipp

    Donnerstag, 17. Oktober 2019 15:05