verteilte Datenbanken

Hallo,

ich suche eine Herangehensweise, wie ich Daten von vielen im Netz verteilten Datenbanken abfragen kann. Das Szenario ist folgendes:
Auf ein paar tausend Industrie-PCs werden lokal Daten in einer Datenbank erfasst. Das Schema der Datenbanken ist bekannt und ist immer das gleiche. Einige der erfassten Daten sind aber unter Umständen auch von globalem Interesse. Zugang ist normal über Internet möglich.
Für den globalen Zugriff auf alle Datenbanken soll eine Proxydatenbank eingerichtet werden. Diese kennt im wesentlichen nur die Verbindungs- und Zugangsdaten zu den einzelnen Industrie-PCs. Anfragen an den Gesamtdatenbestand werden an die Proxydatenbank gestellt und diese soll dann die einzelnen lokalen Datenbanken abfragen und die gesammelten Ergebnisse zusammen darstellen. Die Kommunikation erfolgt jeweils nur zwischen der Proxydatenbank und den lokalen Datenbanken.
Die zu erwartenden Datenmengen sind nicht so groß. Es handelt sich meist um einfache Serviceinformationen wie zum Beispiel Betriebsstunden. Problematisch sehe ich die Anzahl der Kommunikationsverbindungen. Es sollen immer die aktuellen Daten abgefragt werden.
Ein einfaches Skript in der Proxydatenbank kann sicher die einzelnen lokalen Datenbanken abfragen, aber dabei erwarte ich einige Performanceprobleme. Ein Test ist bis jetzt nicht richtig möglich, da sich das System noch in der Entwicklung befindet. Angedacht ist eine Realisierung unter Linux mit PostgreSQL.
Es wäre schön, wenn hier jemand eine hilfreiche Idee hätte, ob es andere Konzepte/Produkte als das Skripte gibt!
Danke!

Marcel

PG kann, außer durch untrusted precedures (z.B. in plperlU oder plsh) keine externen Dinge veranlassen.

Mit anderen Worten:

Das wird nix. Du wirst die Daten durch externe Tools sammeln und in eine zentrale DB eintragen lassen müssen, mit der Du dann arbeiten kannst. Zumal die Clients ‘nur’ via Internet verfügbar sind.

Andreas

Ich hab doch die gleiche Frage heute schon mal gesehen … ah, im Usenet war es :wink:

Nun, ich würde prinzipiell versuchen, das ganze anders herum aufzuziehen: alle relevanten Daten werden in eine zentrale Datenbank gepusht. Das spart zum Zeitpunkt der Abfrage eine Menge Performance.

Wenn das nicht möglich ist, würde ich eine Zwischenschicht einziehen, quasi ein Jobmanager. Bei einer Anfrage erzeugt dieses Programm die Anfragen an die einzelnen Datenbanken parallel und stellt somit sicher, dass nicht alle Anfragen nacheinander ausgeführt werden. Das dauert viel zu lange.


Grundsätzlich möchte ich an dieser Stelle jedoch folgendes sagen: wenn es möglich ist, macht euch doch bitte noch einmal sehr genaue Gedanken über euer Konzept. Da liegt wohl noch einiges im Argen, wenn ihr bisher nicht mal wisst, wie ihr an die Daten herankommt.
Bei so etwas kann ich allerdings helfen :wink:

Ich sehe, dass im Usenet ähnliche Antworten - und die gleichen Bedenken - wie hier auflaufen.

Dank Euch für Eure Hinweise! Wir werden noch mal unser Konzept überdenken.

Marcel

denn … wenn eine anforderung lautet, dass die Industrie-PCs quasi immer erreichbar sein sollen - damit man die gewuenschten Abfragen realisieren kann, dann sollte man daraus schließen, dass die lokalen DBs unsinnig sind. (du wirst ja nicht erst vor der Abfrage alle PCs einschalten wollen)

d.h. wenn es sowieso “den zentralen Knotenpunkt” gibt (von wo aus du fragen willst), dann ist es eigentlich nur konsequent, wenn das der Ort deiner DB wird - also die Industrie-PCs auf einer gemeinsamen entfernten DB operieren.

Also eine klassische bewährte Client-Server Umgebung.

Das ist so nicht möglich. Die Industrie-PCs müssen primär autark arbeiten. Eine Netzwerkverbindung kann nicht zu jedem Zeitpunkt garantiert werden. Dass dadurch unter Umständen nicht immer alle Industrie-PCs erreichbar sind, ist in Grenzen tolerierbar.

[_] Du hast verstanden.

Andreas

dann lautet der umkehrschluss - wenn sie eh nicht immer erreichbar sind/sein können, dann sorge dafuer, dass sie - wenn die Industrie-PCs online sind - einen gemeinsamen DB-Server für OLAP synchronisieren (neue daten “uploaden”).

so hast du auch eine saubere trennung der anwendungsbereiche:

  1. IndustriePC mit lokaler DB für OLTP
  2. gemeinsamer DB-Server für OLAP

die gannst du dann hervorrachn’d obdimiern

Da hast Du wohl recht, denn ich weiß nicht worauf Du anspielst.

@symbiont:
Die Unterteilung in zentrale OLAP-DB und verteilte OLTP-DBs ist eine Möglichkeit, die wir jetzt auch erwägen.

Du sollst das Konzept ganz anders aufbauen.

hallo …

für diese sache gibt es einige recht gute möglichkeiten. idealerweise schickt man die daten flexibel über eine queue. in diesem zusammenhang würde sich “pgq” anbieten. das ist ein ding, das skype open source gestellt hat und für ähnliche datentransport jobs benutzt.

du musst bei einer derartigen menge an rechnern davon ausgehen, dass du permanent irgendwelche kaputten maschinen hast oder irgendwelche leitungen ab und zu einfach spinnen. mit einer queue lässt sich das sehr schön lösen, erweitern und vor allem monitoren. ich hab sowas in die richtung schon mal in einem anderen kontext gemacht. geht echt sehr fein.

liebe grüße,

hans