Hallo,
ich suche eine effektive Möglichkeit das Ergebnis einer Datenbankabfrage von einem Server zu einem anderen Server zwecks Weiterverarbeitung zu übertragen. Wäre es sinnvoll eine temporäre Tabelle mit den Ergebnissen zu erzeugen, mit myisampack zu komprimieren und dann per ftp zu übertragen? Diese Aktion sollte per Cronjob alle 60 Sek. (oder mehr) stattfinden.
Bin für Vorschläge offen
Datenbankabfrage komprimieren und übertragen
-
- User
- Beiträge: 424
- Registriert: Montag 28. Juli 2003, 16:19
- Wohnort: /dev/reality
Die Abfrage von dem Server machen, auf dem die Ergebnisse weiterverarbeitet werden sollen? Da braucht es kein komprimieren und übertragen per ftp.
Dabei sollte man allerdings ein bisschen Wert auf Sicherheit legen. So ohne weiteres würde ich eventuell sensible Datenbankinhalte nicht kreuz und quer durchs Netz schicken. Aber da Yogi ja auf ftp setzen, scheint Sicherheit eh nicht so wichtig zu seinquerdenker hat geschrieben:Die Abfrage von dem Server machen, auf dem die Ergebnisse weiterverarbeitet werden sollen? Da braucht es kein komprimieren und übertragen per ftp.
Ansonsten stimme ich dir natürlich zu.
@lunar: Schrieb ich nicht, dass ich auf der Suche nach effektiven Möglichkeiten bin?
@querdenker: Wenn ich das aber so mache, dann werden doch die Daten nicht gepackt, bevor sie verschickt werden, oder handelt das MySQL von sich aus sicher und effizient?
Edit: Wie es bis jetzt aussieht kann die Federated Engine ganz praktisch sein, obwohl noch nichts gelesen habe wie genau die Daten übertragen werden.
Edit2: Hier ein netter Link dahin: MySQL Federated Tables - The Missing Manual
@querdenker: Wenn ich das aber so mache, dann werden doch die Daten nicht gepackt, bevor sie verschickt werden, oder handelt das MySQL von sich aus sicher und effizient?
Edit: Wie es bis jetzt aussieht kann die Federated Engine ganz praktisch sein, obwohl noch nichts gelesen habe wie genau die Daten übertragen werden.
Edit2: Hier ein netter Link dahin: MySQL Federated Tables - The Missing Manual
Du kannst doch einfach die Datenbankverbindung über SSH tunneln. Dann hast du alles, was du brauchst: Komprimierung, Verschlüsselung und Authentfizierung. Außerdem hat das den Vorteil, dass bei der Datenbank ein "localhost" Zugriff ankommt, so dass du die MySQL-Nutzernamen nicht ändern musst.
Ich erlaube mir allerdings, nach dem Sinn zu fragen. Wie viele Daten willst du denn da übertragen, dass du glaubst, komprimieren zu müssen? Der Sinn der ganzen Sache erschließt sich mir überhaupt nicht.
Erstens hast du ja offenbar eh nur 60 Sekunden Bearbeitungszeit auf dem Zielhost. Zweitens übertragen DBMS Daten eh häppchenweise, nämlich normalerweise immer erst genau dann, wenn du mit "fetch_row" den nächsten Datensatz abholst. So groß können die Daten also gar nicht sein, dass Komprimierung erforderlich wäre. Im Zweifelsfall erhöht das nur die Latenz, weil das Protokoll erstmal Wörterbücher bilden muss, um die Daten zu komprimieren und so zwangsläufig mehr im Puffer halten muss.
Wenn du allerdings tatsächlich Daten im GB-Mengen transferieren willst, dann ist Kompression eh der völlig falsche Weg, da sich die Ausbeute in Grenzen hält. Selbst mit unwahrscheinlichen 50% Kompressionsrate bleiben bei 5 GB immer noch 2.5 übrig, was für ein Netzwerk auch genug Last ist.
Bei solchen Mengen ist dann der einzig richtige Weg ein Cluster-System, bei dem auf dem Zielhost ebenfalls ein komplettes DBMS läuft und der Quellhost jede Transaktion sofort weitergibt. Das verteilt das Volumen, auf dem Zielhost treten so gut wie keine Latenzen auf, und die Datenbanken sind trotzdem synchron.
Irgendwie verstehe ich also dein Problem nicht Imho reicht bei dir eine einfache Datenbankverbindung, die zur Sicherheit über einen SSH-Tunnel läuft, völlig aus. DBMS arbeiten bei solchen Verbrindungen eh inkrementell, die Netzwerklast verteilt sich also.
Ich erlaube mir allerdings, nach dem Sinn zu fragen. Wie viele Daten willst du denn da übertragen, dass du glaubst, komprimieren zu müssen? Der Sinn der ganzen Sache erschließt sich mir überhaupt nicht.
Erstens hast du ja offenbar eh nur 60 Sekunden Bearbeitungszeit auf dem Zielhost. Zweitens übertragen DBMS Daten eh häppchenweise, nämlich normalerweise immer erst genau dann, wenn du mit "fetch_row" den nächsten Datensatz abholst. So groß können die Daten also gar nicht sein, dass Komprimierung erforderlich wäre. Im Zweifelsfall erhöht das nur die Latenz, weil das Protokoll erstmal Wörterbücher bilden muss, um die Daten zu komprimieren und so zwangsläufig mehr im Puffer halten muss.
Wenn du allerdings tatsächlich Daten im GB-Mengen transferieren willst, dann ist Kompression eh der völlig falsche Weg, da sich die Ausbeute in Grenzen hält. Selbst mit unwahrscheinlichen 50% Kompressionsrate bleiben bei 5 GB immer noch 2.5 übrig, was für ein Netzwerk auch genug Last ist.
Bei solchen Mengen ist dann der einzig richtige Weg ein Cluster-System, bei dem auf dem Zielhost ebenfalls ein komplettes DBMS läuft und der Quellhost jede Transaktion sofort weitergibt. Das verteilt das Volumen, auf dem Zielhost treten so gut wie keine Latenzen auf, und die Datenbanken sind trotzdem synchron.
Irgendwie verstehe ich also dein Problem nicht Imho reicht bei dir eine einfache Datenbankverbindung, die zur Sicherheit über einen SSH-Tunnel läuft, völlig aus. DBMS arbeiten bei solchen Verbrindungen eh inkrementell, die Netzwerklast verteilt sich also.
Da hast du recht, riesig ist die zu übertragende Datenmenge wirklich nicht, aber regelmässig. Vielleicht denke ich mir das alles wirklich zu kompliziert. Einziger Punkt wäre vielleicht noch, dass ich auf der anderen Seite nicht unbedint MySQL brauche, SQLite dürfte ausreichen.
Naja, die Installation von MySQL ist nicht allzu kompliziert, ebenso wenig das Aufsetzen eines SSH-Tunnels.
Ich glaube, einen Cronjob zu schreiben, der die Daten in eine SQLite-Datenbank auf dem Zielsystem kopiert, dauert länger, als einfach eine normale DB-Verbindung zu nutzen
Ich glaube, einen Cronjob zu schreiben, der die Daten in eine SQLite-Datenbank auf dem Zielsystem kopiert, dauert länger, als einfach eine normale DB-Verbindung zu nutzen
Bist du sicher, dass du nicht verraten willst, was du vor hast? Immerhin, wie schon erwähnt, bietet mysql von Hause aus das Feature an, zwei Datenbanken synchron zu halten.
Es ist nett, freundlich zu sein.
Auch nett: [url=http://www.progchild.de]Homepage[/url]
Auch nett: [url=http://www.progchild.de]Homepage[/url]
Wieso will ich nicht verraten was ich vorhabe? Auf der einen Seite habe ich ein Forum, in diesem Fall myBB 1.4, auf der anderen Seite habe ich einen Rechenknecht, der in kurzen Abständen Daten von der Forum-Datenbank braucht um damit arbeiten zu können. Das Forum läuft auf dem einen Server (wenn ich ssh brauche kann ich nicht bei meinem jetzigen Provider bleiben) und die Rechnerei soll erst einmal auf einer meiner Heimkisten wo Debian drauf ist werkeln. Ab und an muss der Rechenknecht auch auf die Forum-Datenbank schreibend zugreifen bzw. bestimmte Skripte ausführen (externe Erzeugung von Unterforen, Gruppen, Email-Benachrichtigungen etc).
Was du meintest war glaub ich das mit den Federtated Tables, oder?
Was du meintest war glaub ich das mit den Federtated Tables, oder?
Ich dachte an sowas hier: http://www.tecchannel.de/server/sql/429801/
Aber wenn das Shared-Hosting ist, kannst du das knicken.
Versuch doch mal, eine Verbindung mit einem Mysql-Client deiner Wahl zu deinem Mysql server (der im Internet ist) aufzubauen und abfragen auszufühern.
Wenn das klappt, kannst du dein Programm ja direkt auf der Datenbank arbeiten lassen. Ist vermutlich weniger last, als wenn du dauernd den kompletten Datenbestand abfragst.
Andernfalls (falls zu direkten Zugriff auf den Server übers Netz hast) wäre da das Programm mysqldump.
Aber wenn das Shared-Hosting ist, kannst du das knicken.
Versuch doch mal, eine Verbindung mit einem Mysql-Client deiner Wahl zu deinem Mysql server (der im Internet ist) aufzubauen und abfragen auszufühern.
Code: Alles auswählen
$ mysql -u benutzer -h www.mein-server.de -p
Andernfalls (falls zu direkten Zugriff auf den Server übers Netz hast) wäre da das Programm mysqldump.
Es ist nett, freundlich zu sein.
Auch nett: [url=http://www.progchild.de]Homepage[/url]
Auch nett: [url=http://www.progchild.de]Homepage[/url]
nee Master/Slave ist nix, ich brauche ja nur einen kleinen Teil der Daten.
Ursprünglich hatte ich ja sogar vor mit mysqldump zu arbeiten, aber die Problematiken sind ja bereits angerissen worden. Momentan fixiere ich mich erst einmal auf die ssh-Lösung. Ob Federated Tables eine Alternative wären kann ich noch nicht sagen.
PS: Ist das ernsthaft gemeint, mit dem einfachen, direkten Zugriff auf die DB von extern?
Ursprünglich hatte ich ja sogar vor mit mysqldump zu arbeiten, aber die Problematiken sind ja bereits angerissen worden. Momentan fixiere ich mich erst einmal auf die ssh-Lösung. Ob Federated Tables eine Alternative wären kann ich noch nicht sagen.
PS: Ist das ernsthaft gemeint, mit dem einfachen, direkten Zugriff auf die DB von extern?
Naja... Wo liegt dabei das Problem? Wenn der Server eh schon zugriff von außen gewährt, dann ist da ja schon nicht mehr viel zu machen. Die Passwörter und der Server müssen halt sicher sein.Yogi hat geschrieben:PS: Ist das ernsthaft gemeint, mit dem einfachen, direkten Zugriff auf die DB von extern?
Jetzt kommt es drauf an, wie sensibel, die Daten sind, mit denen du arbeiten willst. Reicht es dir aus, dass die Authentifizierung sicher ist (also das Passwort nicht im klaartext übertragen wird) solltest du kein Problem mit einer direkten verbindung haben. (Sofern der Server die sichere authentifizierung unterstützt).
Wenn die Daten verschlüsselt werden sollen, dann kannst du dies auch mit Mysql und SSL machen. Aber da wird es wahrscheinlich bei Shared Hosting wieder schlecht aussehen. Da bleibt dir dann nur ein SSH-Tunnel oder ein VPN.
Es ist nett, freundlich zu sein.
Auch nett: [url=http://www.progchild.de]Homepage[/url]
Auch nett: [url=http://www.progchild.de]Homepage[/url]