Installation einer weiteren Datenbank(anwendung)

Hallo Wissende,
ich habe hier einen Postges-Server, welcher von einem fremden Programm genutzt wird.
Was dieses Programm dort alles tut kann ich nicht 100% überblicken.

Ich brauch jetzt ein Postgres Backend für eine eigene Anwendung und möchte nach Möglichkeit diesen Server nutzen.

Mein Backend wird ca. 100.000.000 Datensätze umfassen.

*Was ist nach eurer Ansicht zu empfehlen, dass sich die beiden Anwendungen nicht in die Quere kommen.
*

Ich würde auf jeden Fall eine neue DB erstellen. Sollte ich darüben hinaus die beiden Anwendungen entkoppeln z.B. eigener Tabelspace und eigener …?

Gruß Steffen

Tablespaces machen Sinn, wenn diese letztendlich auf unterschiedlichen Platten sind.

Viel mehr kann man wohl auf die Frage nicht sagen …


Andreas

Eigene Tablespaces, eigene Datenbanken … alles darüber hinaus ist Glaskugelbetrachten.
Allein mit der Angabe von 100M Datensätzen kann man nicht viel aussagen. Da deine Datenbank aber anscheinend etwas größer wird - such dir jemanden, der sich mit PostgreSQL auskennt. Ansonsten wirst du in einige Anfängerfehler laufen.

Hallo,

such dir jemanden, der sich mit PostgreSQL auskennt

Was denkst du warum ich hier im Forum frage :wink: .

Die DB selbst wird groß, der Aufbau aber primitiv. Eine Datentabelle mit 100 Mil. DS und zwei Stammtabellen mit ein paar dutzend Datensätzen.
Nach einem (zunächst) einmaligen Import werden dann die Daten auschnittsweise wieder exportiert. Das war’s schon.
Habe halt nur etwas “Angst” vor der Datenmenge, deshalb die Rückfrage. Ich hatte mir das irgendwie auch einfacher vorgestellt. Aber diese Datenmenge ist auch für einen Datenbankserver (zumindest OutOfTheBox) ein ernstes Problem.

Ich bin bisher nur Desktopdatenbanken (MSAccess) gewöhnt, welche sich gegenseitig nicht beeinflussen.
Hier habe ich 2 Datenbanken auf einem Server und frage mich halt, ob die sich in die Quere kommen können. Im Normalfall würde ich sagen nein, aber bei dieser Datenmenge bin ich mir halt unsicher.

Btw:
Es passt eigentlich nicht hier rein, aber ich habe noch ein letztes Problem:
Ich möchte eine Anfügeabfrage durchfüren. Die Zieltabelle hat einen eindeutigen Index über 2 Felder. Die Anfügeabfrage soll aber trotz Indexverletzung die sauberen Datensätze importieren.
(ein vorheriger Abgleich auf Dupletten ist aus Zeitgründen nicht möglich)


Gruß Steffen

100 Millionen oder 100 Milliarden?

Aber diese Datenmenge ist auch für einen Datenbankserver (zumindest OutOfTheBox) ein ernstes Problem.

100 Mio auf sind auf keinen fall “ein ernstes” Problem.

Hier habe ich 2 Datenbanken auf einem Server und frage mich halt, ob die sich in die Quere kommen können. Im Normalfall würde ich sagen nein, aber bei dieser Datenmenge bin ich mir halt unsicher.

Die Menge spielt dabei überhaupt keine Rolle. Ob da 100MB, 100GB oder 100TB auf der Platte rumliegen ist egal. Aber nachdem sich die beiden Datenbanken gemeinsame Resource teilen, kann es natürlich zu Beinflussung komme.

Der I/O Durchsatz des Systems ist begrenzt. Wenn beide Datenbanken nun so unter Last stehen, dass sie einzeln die I/O Leistung des Systems zu 100% auslasten, dann wird jede einzelne langsamer werden (weil nur noch die Hälfte zur verfügung steht). Lasten die Anwendungen das System aber nicht aus (z.B. jede nur 30% der max. I/O Leistung) dann wird man kaum eine Beinflussung spüren.

Ich möchte eine Anfügeabfrage durchfüren. Die Zieltabelle hat einen eindeutigen Index über 2 Felder. Die Anfügeabfrage soll aber trotz Indexverletzung die sauberen Datensätze importieren. (ein vorheriger Abgleich auf Dupletten ist aus Zeitgründen nicht möglich)

Das ist ein bisschen dünn, von der Beschreibung. Normalerweise löst man dass folgendermassen:

insert foobar (col1, col2, col3)
select 42, 'foo', 'bar'
where not exists (select 1 from foobar where col1 = 42 and col2 = 'foo');

(col1, col2) ist dabei der eindeutige Index.

Hallo castrop,
Dank für die Antwort

Das ist ein bisschen dünn, von der Beschreibung. Normalerweise löst man dass folgendermassen

Ja leider hat sich “normal” als nicht praktibal erwiesen.

CREATE  TEMP TABLE tmp_imp (rw numeric(11,3), hw numeric(11,3) , hoe numeric(8,3));
COPY tmp_imp FROM 'c:/.../datei.csv' WITH DELIMITER ' ';
INSERT INTO zieltabelle ( rw, hw, hoe ,impIndex) 
   SELECT DISTINCT tmp_imp.rw, tmp_imp.hw, tmp_imp.hoe, 1 
   FROM tmp_imp  
   LEFT JOIN zieltabelle ON (tmp_imp.Hw = zieltabelle.hw) AND (tmp_imp.Rw = zieltabelle.rw) 
   WHERE zieltabelle.rw  Is Null;

Wenn ich 1 Mio. Datensätze (aus einer Textdatei) an 1 Mio. Datensätze in der Tabelle anfügen will ist das kein Thema (30s).
Aber 1 Mio. Datensätze an 20 Mio. Datensätze da bin ich schon bei 170s und ich denke das wird nix bei 100 Millionen.

Ich bin echt am verzweifeln:
Ich will doch einfach nur, dass er alle Datensätze die den UNIQUE-Key verletzen weglässt und die restlichen importiert. Gibt es dafür keinen Befehl? Ich finde einfach nix!!

Dazu müßte man sich die Pläne mal anschauen, und Indexe. Hast Du den DB-Server gescheit konfiguriert? Shared_memory etc.?

Andreas

Wieso nix?
Wenn 1 Mio in 20 Mio das 5 fache von 1 Mio in 1 Mio ist, dann wäre doch anzunehmen, dass 1 Mio in 100 Mio die 10-fache Zeit dauert. Das wären dann 300s. Find ich noch akzeptabel. Selbst wenn es nicht-linear steigt reden wir vermutlich immer noch von Minute und nicht von Stunden. Wie oft musst Du das denn machen?

Grundsätzlich kann man natürlich noch an ein paar Tuning Schrauben drehen um das bulk-loading schneller zu machen. checkpoint_segments und maintenance_work_mem fallen mir da spontan ein. Wenn die Zieltabelle grundsätzlich über die Imports neu aufgebaut werden kann und ihr damit leben könnt die Daten bei einem Crash zu verlieren (und eben aus den text Dateien wieder zu rekonstruieren) kann man darüber nachdenken die Tabelle als UNLOGGED zu erzeugen.

Ich will doch einfach nur, dass er alle Datensätze die den UNIQUE-Key verletzen weglässt und die restlichen importiert. Gibt es dafür keinen Befehl? Ich finde einfach nix!!

Nein, leider nichts in Postgres eingebautes, leider (sowas wie Oracles LOG ERRORS INTO, oder MySQLs ON DUPLICATE IGNORE wäre schön).

Hallo,
der Server ist “OutOffTheBox” und da er mir nich allein gehört, möchte ich da nicht all zu viel drehen.

Ich habe für die “angepasste” Anfügeabfrage eigentlich das Handtuch geworfen. Indizies selber haben durch das massige Anfügen eher gegensätzlich Effekte (ohne gehts schneller).

Ich denke wirklich, dass Anfügen trotz (Teil)Fehler die beste Variante für meinen Fall ist. Bekomme es aber mit PostgreSQL einfach nich gebacken.

Wie kann ich sagen: Füge an was geht und ignoriere den Rest?

Wie schon gesagt: geht nicht mit den Bordmitteln von Postgres

Hallo,

geht nicht mit den Bordmitteln von Postgres (hab ich überlesen oder du hattest das vermutlich nachträglich geschrieben.
Riesengroße Sch … :frowning: .
Jetzt habe ich ein ernsthaftes Problem.

Gruß Steffen

Man kann die Daten einfach in eine separate Tabelle laden und dann über INSERT INTO … SELECT FROM … WHERE all die Datensätze kopieren die den Unique Key nicht verletzen.
Das ist im ETL/Data Warehouse Bereich sowieso der passende Weg, da man über diesen Weg die Anfragen parallelisieren kann.

Und mit “such dir jemanden der sich mit PostgreSQL auskennt” meinte ich nicht das wir hier retroaktiv deine Probleme bearbeiten sondern das sich jemand dein gesamtes Konzept anschaut und von vorneherein auf Herz und Nieren prüft.

Es gibt externe Tools die sowas können (Stichwort ETL).
Allerdings bin ich mir nicht sicher ob das wirklich schneller ist als ein INSERT … SELECT … WHERE … was Du sowieso schon hast (allerdings fällt bei denen der Schritt mit der Zwischentabelle weg).

Ich habe für die “angepasste” Anfügeabfrage eigentlich das Handtuch geworfen

Nochmal: warum? Wie oft musst Du das machen? Wie schnell muss es denn laufen damit es akzeptabel ist?

der Server ist “OutOffTheBox” und da er mir nich allein gehört, möchte ich da nicht all zu viel drehen.

Wenn Performance so ein Thema ist, dann musst Du über Tuning des Servers nachdenken. Da führt kein Weg dran vorbei.

Es gibt einige einfache Dinge wie die beiden Parameter die ich erwähnt habe. Die stellen auch für andere Datenbanken auf dem Server keinen Nachteil. Dann die Unlogged Tabellen mit den Einschränkungen die ich schon erwähnt habe. Das ist aber mit einer automatisierten ETL Lösung vermutlich kein so großes Problem.

Hallo,

1Mil Bestand + 1 Mil neu → 30s
20Mil Bestand + 1 Mil neu–> 170s
100Mil. Bestand + 1 Mil neu → ???
Letztendlich “Versuch macht klug”. Und was muss das muss, da hilft kein jammern.
Hatte es mir nur anders ausgemalt. Ich muss einfach umdenken.

Selbst das anschließende Löschen der Mehrfachen ist sicher unrealistisch.
Sobald Unterabfragen ins Spiel kommen wird es halt bei der Datenmange kritisch, noch dazu, da ich für den schnellen Import ohne Indizies arbeite (arbeiten muss).

DELETE FROM Tabelle AS T
WHERE NOT EXISTS
  (SELECT Null FROM 
         (SELECT key, Min(id) AS MinID FROM Tabelle GROUP BY key) AS U
   WHERE U.key = T.key AND U.MinID = T.id)

Dieser (fremde) Code sollte dabei helfen, er läuft in Access aber nicht in PostGes. Aber ich habe jetzt genug genervt das sind dann erst mal meine “Hausaufgaben”.

Habe mit Access begonnen und das hatte 30 Mill. in (gefühlten) 10min drin - dann war allerdings Feierabend :wink: .

Gruß Steffen

Aber nach dem Import kannst Du die Indizes ja wieder anlegen. Indizes droppen, bulk insert, Indizes anlegen ist das übliche Vorgehen bei Massendaten.

DELETE Tabelle AS T
WHERE NOT EXISTS
(SELECT Null FROM
(SELECT key, Min(id) AS MinID FROM Tabelle GROUP BY key) AS U
WHERE U.key = T.key AND U.MinID = T.id)

>
> Dieser (fremde) Code sollte dabei helfen, er läuft in Access aber nicht in PostGes.

PostGes gibt es nicht. Auch nicht PostGre oder Postgre. Üblicherweise sagt/schreibt man Postgres oder einfach PG.

Was genau läuft denn bei dem Statement nicht? Sieht auf den ersten Blick gut (allerdings inneffizient) aus.

Duplicate aus einer Tabelle schmeissen geht aber auch anders:

Die allgemeine (DBMS unabhängige) Lösung sieht normalerweise so aus:

```text
DELETE FROM dupes
WHERE id NOT IN (SELECT min(b.id)
                 FROM   dupes b
                 GROUP BY unique_col1, unique_col2
                 HAVING count(*) > 1);

Das geht davon aus, dass uniq_col1/unique_col2 keine Duplicate haben dürfen und die Spalte id Eindeutig ist.

Eine Postgres spezifische Version (z.B. wenn es keine eindeutige Spalte gibt sieht so aus)

delete from tabelle
DELETE FROM tabelle a
WHERE a.ctid <> (SELECT min(b.ctid)
                 FROM  tabelle b
                 WHERE a.unique_col1 = b.unique_col1
                   and a.unique_col2 = b.unique_col2);

Also ein DELETE in einer großen Tabelle ist immer eine schlechte Idee. Das hinterlässt massenweise leere Blöcke, die aber nicht weggeräumt werden können. VACUUM muss ran, muss sich das alles anschauen und muss alles zur Wiederverwendung markieren.

Dafür das sich das wie ein typisches Data Warehouse anhört macht ihr da eine Reihe konzeptioneller Fehler.

Dem muß ich (leider) zustimmen. $KUNDE von uns hat eine Tabelle, die vielleicht 2000 - 3000 Records enthält, also nicht wirklich dramatisch. Aber: Zum Teil werden manche Records mehrfach pro Sekunde verändert (und zwar relativ viele), und z.T. sind die Records bis zu einigen MB groß. Ganz schlecht … Bloat ohne Ende, im fetten GB-Bereich. Will nur sagen: man sollte sich wirklich vorher überlegen, was man tut.

Andreas

Hallo,

Dafür das sich das wie ein typisches Data Warehouse anhört macht ihr da eine Reihe konzeptioneller Fehler.

Also ich komme aus der Accessecke und da kann man beim Anlegen einer Tabelle mit

[KoordinateX] [KoordinateY] [Höhe]

nmK keine konzeptionellen Fehler machen.
Wenn ich also “konzeptionelle” Fehler mache muss das Spezialwissen von PG sein. Dieses fehlt mir leider.

Das Projekt was ich mit 5-10 Millionen Datensätzen in Access innerhalb von 30min abgewickelt hatte, hat sich auf Grund der Datenmenge jetzt leider extrem ausgeweitet. Ich werde nach jetzigem Stand, das Projekt zwar umsetzen können, aber das Zeitverhalten ist enttäuschend.

Die oft vertretene Meinung:
“Nimm doch statt AccessBE einen SQL-Server und du bist deine Probleme los!” stufe ich für mich als falsch ein.
Eine “normale” Umsetzung von Tabellen auf einen “normalen” Server hat in meinem Fall zu keiner befriedigenden Lösung geführt.

Entweder meine Erwartungen waren zu hoch, oder mein PG (Datenbankserver)-Wissen ist zu gering.

Ich gehe jetzt von Letzterem aus und werde mich dem Selbststudium widmen.

Danke an alle “Mitwirkenden” :slight_smile:

Sorry, aber Du irrst. Eine mehr als 08-15-Anwendung basiert auf mehr als einer Tabelle. Die Aufteilung, was man wie in welchen Tabellen nach welchem Prinzip speichert, ist das ‘Konzept’, und da kann man sehr wohl recht schnell Fehler machen.

Das Projekt was ich mit 5-10 Million Datensätzen in Access innerhalb von 30min abgewickelt hatte, hat sich auf Grund der Datenmenge jetzt leider extrem ausgeweitet. Ich werde nach jetzigem Stand, das Projekt zwar umsetzen können, aber das Zeitverhalten ist enttäuschend.

Siehe oben, siehe Antwort von ads, siehe Deine eigenen Erfahrungen mit Access.

Die oft vertretene Meinung:
“Nimm doch statt AccessBE einen SQL-Server und du bist deine Probleme los!” stufe ich für mich als falsch ein.

Ja, korrekt. Eine 1zu1 - Abbildung einer Rezepte-Datenbank mit 36 Datensätzen auf etwas, was Faktor 1Million und mehr größer ist, skaliert nicht von selbst. Siehe oben, siehe ads, siehe Deine eigene Erfahrung.

Eine “normale” Umsetzung von Tabellen auf einen “normalen” Server hat in meinem Fall zu keiner befriedigenden Lösung geführt.

Siehe oben, siehe 1zu1-Abbildung, erwähnte ich schon ads und Deine Erfahrungen?

Entweder meine Erwartungen waren zu hoch, oder mein PG (Datenbankserver)-Wissen zu gering.

Ich gehe jetzt von Letzterem aus und werde mich dem Selbststudium widmen.

Das hat nicht unbedingt was mit PG zu tun, aber Deine Schlußfolgerung ist schon okay.


Ach ja: Hardware, Optimierung der Config an diese?

Andreas

Hallo,

Eine mehr als 08-15-Anwendung basiert auf mehr als einer Tabelle.

Es ist aber sogar weniger als eine 0815 Anwendung, eine Tabelle mit Datensätzen zu je 3 Double-Werten (hatte ich oben beschrieben).
Wenn aber z.B. die Erstellung eines Indexes (gefühlte) 30 Minuten dauert, dann hilft kein Datenmodell, sondern vermutlich nur Servertuning.
Das Ganze ist für mich aber neu und ich muss selbst sehen wie ich damit klar komme.