Re: Ausgesuchte Daten replizieren

Hallo,

in einer Anwendung zur Publizierung von Anzeigen werden die zu einer
Anzeige gehörenden Daten in verschiedene Tabellen einer Datenbank
geschrieben. Nur die für die Publikation notwendigen Daten werden auf einen
anderen Rechner übertragen und dort bereitgestellt. Die Übertragung erfolgt
derzeit mit einem pg_dump der relevanten Tabellen, der Übertragung der
Daten auf den entfernten Rechner und dort mit dem Ausführen der mit pd_dump
erzeugten SQL-Anweisungen. Die Initiierung der Übertragung erfolgt
zeitgesteuert durch cron.
Hat jemand eine Idee, wie man das in sofern vereinfachen kann, daß nur die
geänderten Daten übertragen werden?
Kann man nur bestimmte Datensätze, pg_dump-ähnlich aufbereitet, auslesen?

Gruß Uli

In epistula a Ulrich Mietke, die horaque Thu, Sep 23, 2004 at 02:34:56PM +0200:
> Hallo,
>
> in einer Anwendung zur Publizierung von Anzeigen werden die zu einer
> Anzeige gehörenden Daten in verschiedene Tabellen einer Datenbank
> geschrieben. Nur die für die Publikation notwendigen Daten werden auf einen
> anderen Rechner übertragen und dort bereitgestellt. Die Übertragung erfolgt
> derzeit mit einem pg_dump der relevanten Tabellen, der Übertragung der
> Daten auf den entfernten Rechner und dort mit dem Ausführen der mit pd_dump
> erzeugten SQL-Anweisungen. Die Initiierung der Übertragung erfolgt
> zeitgesteuert durch cron.
> Hat jemand eine Idee, wie man das in sofern vereinfachen kann, daß nur die
> geänderten Daten übertragen werden?
> Kann man nur bestimmte Datensätze, pg_dump-ähnlich aufbereitet, auslesen?

Was spricht gegen sowas wie:

psql: ~# DROP TABLE export_daten;
psql: ~# SELECT <...>
INTO export_daten
FROM <...>
WHERE <...>

% pg_dump --table export_daten

Wäre wahrscheinlich der minimale Aufwand in deinem Fall.

Gruß,
Peter

--
Die Schriftsteller können nicht so schnell schreiben,
wie die Regierungen Kriege machen; denn das Schreiben verlangt Denkarbeit.
-- Bertold Brecht

Peter Wullinger schrieb:
>
> Was spricht gegen sowas wie:
>
> psql: ~# DROP TABLE export_daten;
> psql: ~# SELECT <...>
> INTO export_daten
> FROM <...>
> WHERE <...>
>
> % pg_dump --table export_daten
>
> Wäre wahrscheinlich der minimale Aufwand in deinem Fall.
>
Damit erfasse ich leider nicht die gelöschten Datensätze.

Gruß Uli

In epistula a Ulrich Mietke, die horaque Fri, Sep 24, 2004 at 07:58:58AM +0200:
> Peter Wullinger schrieb:
> >
> > Was spricht gegen sowas wie:
> >
> > psql: ~# DROP TABLE export_daten;
> > psql: ~# SELECT <...>
> > INTO export_daten
> > FROM <...>
> > WHERE <...>
> >
> > % pg_dump --table export_daten
> >
> > Wäre wahrscheinlich der minimale Aufwand in deinem Fall.
> >
> Damit erfasse ich leider nicht die gelöschten Datensätze.

Okay, jetzt bin ich endgültig verwirrt ;-).

Vielleicht habe ich nur nicht so genau verstanden, was genau
in deinem Szenario implementiert werden muß.

Meine Interpretation war, daß du zwei PostgreSQL-Datenbanken hast,
wobei die eine die Backend-Datenbank mit allen Daten und die andere
die Frontend-Datenbank mit nur den notwendigen Daten für das
Content-Publishing ist.

Wenn die Tabellenstruktur 1:1 diesselbe ist, bietet sich vielleicht
eine "Replication"-Lösung für PostgreSQL an, wie z.B. slony an:

http://gborg.postgresql.org/project/slony1/projdisplay.php

Die kopieren dann nur die geänderten Daten.

Wenn sich aber die Frontend-Daten aus Queries der Backend-Daten
berechnen lassen, ist es vielleicht sinniger die Queries auf der
Backend-DB laufen zu lassen und selektiv in die Frontend-DB
einzuspielen. Je nach Szenario die effezientere oder aufwändigere
Lösung.

Gruß,
Peter

--
Man is born free, yet he is everywhere in chains.
-- Jean Jacques Rousseau

Peter Wullinger schrieb:
> In epistula a Ulrich Mietke, die horaque Fri, Sep 24, 2004 at 07:58:58AM +0200:
>> Peter Wullinger schrieb:
>>>
>>> Was spricht gegen sowas wie:
>>>
>>> psql: ~# DROP TABLE export_daten;
>>> psql: ~# SELECT <...>
>>> INTO export_daten
>>> FROM <...>
>>> WHERE <...>
>>>
>>> % pg_dump --table export_daten
>>>
>> Damit erfasse ich leider nicht die gelöschten Datensätze.
>
> Okay, jetzt bin ich endgültig verwirrt ;-).
>
Dann versuche ich das mal zu entwirren.

> Vielleicht habe ich nur nicht so genau verstanden, was genau
> in deinem Szenario implementiert werden muß.
>
Vielleicht habe ich mich auch missverständlich ausgedrückt.

> Meine Interpretation war, daß du zwei PostgreSQL-Datenbanken hast,
>
richtig, zwei PostgreSQL-Installationen auf unterschiedlichen Rechnern.

> wobei die eine die Backend-Datenbank mit allen Daten und die andere
> die Frontend-Datenbank mit nur den notwendigen Daten für das
> Content-Publishing ist.
>
ja. Auf der Backend-Datenbank werden die Anzeigen (bzw. dazugehörige
Datensätze) neu aufgenommen, geändert oder gelöscht. Möglichst zeitnah
sollten die Änderungen auf die Frontend-Datenbank übertragen werden. Das
Beste wäre es, wenn alle INSERT, UPDATE und DELETE Statements, die die
entsprechenden Tabellen betreffen, nach Beendigung der Transaktion auch auf
der Frontend-Datenbank durchgeführt werden.

> Wenn die Tabellenstruktur 1:1 diesselbe ist, bietet sich vielleicht
> eine "Replication"-Lösung für PostgreSQL an, wie z.B. slony an:
>
> http://gborg.postgresql.org/project/slony1/projdisplay.php
>
> Die kopieren dann nur die geänderten Daten.
>
Muß ich mir noch genauer ansehen.

> Wenn sich aber die Frontend-Daten aus Queries der Backend-Daten
> berechnen lassen,
>
Das ist zwar z. Z. nicht möglich, ließe sich aber mit einen zusätzlichen
Feld mit Zeitstempel oder "Replikationsbit" einrichten.

> ist es vielleicht sinniger die Queries auf der
> Backend-DB laufen zu lassen und selektiv in die Frontend-DB
> einzuspielen. ...
>
Die Verbindung kann zur Sicherheit nur vom Backend-Rechner zum
Frontend-Rechner aufgebaut werden. Der Frontend-Rechner darf keine
ausgehenden Verbindungen aufbauen. In die Zone, in der der Backend-Rechner
steht, dürfen keine Verbindungen aufgebaut werden.

Ich schildere mal auszugsweise und beispielhaft die Prozesskette.

In der Anzeigenannahme werden die Daten für eine Anzeige aufgenommen und
auf verschiedene Tabellen verteilt.
Der Anzeigentext kommt in ANZEIGE, die Kundenstammdaten kommen in KDDAT, in
welcher Rubrik die Anzeige erscheinen soll kommt in BRANCHE und der Ort in
der die Anzeige erscheinen soll kommt in GEOREF.
Die Daten aus ANZEIGE, BRANCHE und GEOREF werden an den Frontend-Rechner
übertragen. Die Daten aus KDDAT dürfen nicht übertragen werden.

Es kann aber auch sein, daß nur ein Teil der Daten in der Anzeigenannahme
verändert wird, z. B. soll die Anzeige in mehreren Rubriken oder Orten
erscheinen oder eine einzelne Rubrik oder ein Ort wird gelöscht.

Gruß Uli