Datenbankabfrage komprimieren und übertragen

Installation und Anwendung von Datenbankschnittstellen wie SQLite, PostgreSQL, MariaDB/MySQL, der DB-API 2.0 und sonstigen Datenbanksystemen.
Antworten
Yogi
User
Beiträge: 80
Registriert: Montag 21. Januar 2008, 16:35
Wohnort: Bonner

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 :)
querdenker
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.
lunar

querdenker hat geschrieben: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 sein ;)

Ansonsten stimme ich dir natürlich zu.
Yogi
User
Beiträge: 80
Registriert: Montag 21. Januar 2008, 16:35
Wohnort: Bonner

@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
lunar

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.
Yogi
User
Beiträge: 80
Registriert: Montag 21. Januar 2008, 16:35
Wohnort: Bonner

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.
lunar

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 ;)
Yogi
User
Beiträge: 80
Registriert: Montag 21. Januar 2008, 16:35
Wohnort: Bonner

Ja, so langsam glaube ich, dass du recht hast :?

Ich bin gerade dabei ein Testsystem aufzubauen, momentan unter windows, vielleicht sollte ich lieber direkt mit Virtualbox und debian werkeln....
ProgChild
User
Beiträge: 210
Registriert: Samstag 9. April 2005, 10:58
Kontaktdaten:

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]
Yogi
User
Beiträge: 80
Registriert: Montag 21. Januar 2008, 16:35
Wohnort: Bonner

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?
ProgChild
User
Beiträge: 210
Registriert: Samstag 9. April 2005, 10:58
Kontaktdaten:

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.

Code: Alles auswählen

$ mysql -u benutzer -h www.mein-server.de -p
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.
Es ist nett, freundlich zu sein.
Auch nett: [url=http://www.progchild.de]Homepage[/url]
Yogi
User
Beiträge: 80
Registriert: Montag 21. Januar 2008, 16:35
Wohnort: Bonner

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? :shock:
ProgChild
User
Beiträge: 210
Registriert: Samstag 9. April 2005, 10:58
Kontaktdaten:

Yogi hat geschrieben:PS: Ist das ernsthaft gemeint, mit dem einfachen, direkten Zugriff auf die DB von extern? :shock:
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.

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]
Antworten