Datenbank-Cluster oder ähnl.

Hallo,

als erstes mal ein paar Infos zum Problem. Im moment verwalte ich in meiner DB 4,2 Mio. Produkte. Diese bestehen aus mehreren Datensätzen in 47 Tabellen nicht alle belegen alle Tabellen. Im durchschnitt vermutlich ca. 30 Sätze pro Produkt. Mein Problem ist das ich das Updaten der Produkte und löschen veralteter Datensätze nicht mehr schnell genug auf einem Rechner ausführen kann. Es sind ca. 100.000 Productupdates pro Woche plus die Suchanfragen der Anwender.

Da ich nicht auf teure Hardware umsteigen will suche ich nach einer Lösung wie ich eine verteilte Datenbank realisieren kann die für die Anwendungen möglichst transparent ist. Nach längeren stöbern bei Google habe ich einiges zur Ausfallsicherheit gefunden. Zum Beispiel heartbeat, pg_cluster, db_mirror, pgpool, usw… Nach meiner Meinung ist das aber nicht ganz das was ich suche weil es nicht den Aufwand eines Suchprozesses über mehrere Systeme verteilt.

Es wäre schön wenn jemand Tips und Hinweise hat wie ich sowas lösen kann.

Viele Grüße und ein schönes neues Jahr
Alexander

Also eine einzelne Suche kannst du meines Wissens nicht auf mehrere Datenbanken verteilen, höchstens verschiedene Suchanfragen auf verschiedene DBs. pgcluster kann so etwas zum Beispiel.

Gegenfrage: bist du dir sicher, bereits ausreichend Performance aus deiner jetzigen Lösung herausgekitzelt zu haben?

Die von Dir genannten Dinge wie heartbeat und db_mirror sind eher was in Richtung Ausfallsicherheit, pgpool IIRC eher was, um mehrere Abfragen auf eine Reihe von Servern zu leiten. Das sind alles nicht Dinge, die Dir helfen werden. Zumal du sagst, es sei kein Geld für neuere Hardware da, denn Du müßtest ja neue Hardware jinstellen.

Du kommst vermutlich schneller und preiswerter zum Ziel, wenn Du versuchst, Deine jetzige Lösung zu optimieren.

Hilfreich wäre da z.B., lang laufende Abfragen zu finden und diese zu verbessern. Hilfreich wäre hier z.B.

log_min_duration_statement = XXXX

mit XXXX dem Schwellwert in ms, ab dem Du Befehle loggen willst. Die dann mit Explain anschauen.

Bist Du sicher, optimale Werte für die Speicherverwaltung zu haben?

07:11 < akretschmer> ??tuning
07:11 < pg_docbot_adz> For information about 'tuning' see:
07:11 < pg_docbot_adz> http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html :: http://www.powerpostgresql.com/PerfList ::
                       http://www.revsys.com/writings/postgresql-performance.html :: http://www.varlena.com/varlena/GeneralBits/116.php
07:11 < pg_docbot_adz> http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html

Schaue Dir mal diese Links an.

100.000 Updates pro Woche und so klingt jetzt nicht wirklich als eine unerreichbare Größe auf ALDI-Hardware. Also, versuch mal auf diesem Wege Deine Probleme zu lösen.


Andreas

Hallo,

also ob alles Optimal gestaltet ist bin ich mir nicht sicher aber ich bin mir sicher dass ein einzelner Standard-PC das nicht in ausreichender schnelligkeit schaft. Ich habe aber schon einiges (Indizierung, SQL-Optimierung) in der Richtung gemacht und glaube die wichtigsten Dinge gemacht zu haben. Die Links zur Speicherverwaltung muß ich mir erst noch Ansehen ob es da noch was neues gibt das ich noch nicht kenne.

Mit teurer Hardware meinte ich nicht generell keine neue Hardware. Ich möchte nur kein AIX, SUN, SG-Rechner oder ähnliches verwenden sondern Standard PC-Hardware.

Um Mißvertändnisse zu vermeiden nochmal einige Worte zu den 100.000 Produktupdates pro Woche. Ein Produkt besteht aus ca. 30 voneinander abhängigen Datensätzen die jede Woche eingefügt werden müssen. Mit einem Zeitlichen versatz werden die alten Producte wieder gelöscht.

Also 100.000 * 30 = 3.000.000 inserts + nochmal 3.000.000 deletes also 6.000.000 Datenbewegungen pro Woche nur um den Datenbestand aktuell zu halten. Es werden genau genommen nur 100.000 deletes Ausgeführt die RI sorgt für die Löschung der abhängigen Datensätze. Diese Datenbank muß aber auch noch Anwendern mit einer ausreichnden geschwindigkeit zur Arbeit zur Verfügung stehen. Also genau geschrieben als Produkt-DB für einen Online-Shop. Da fällt nicht nur die Seitengenerierung an sondern auch die Zugriffe per Suchfunktion. Ich habe viel zutrauen zu ALDI-Hardware aber da geht ihr die Puste aus. Zurzeit läuft nur die Bestandsaktualisierung und eine Teilweise Löschung alter Sätze.

Gruß
Alexander

Das mag alles sein, aber 6.000.000 Datenbewegungen pro Woche (!!!) schafft auch noch ein 486 spielend.

Wie schon gesagt, schau einfach, wo es klemmt und was man optimieren kann.

Die Daten der Inserts, wie kommen die rein? Auf einem Schwung via Schnittstelle? Falls ja, würde hier z.B. schon der Umstieg zu COPY viel bringen.

Machst Du regelmäßig ein VACUUM bzw. auch mal ein VACUUM FULL? Die Problematik der toten Tupel kennst Du, oder?

Hast Dir mal Explain bei Suchabfragen angeschaut?

Welche Version von PG einklich?



Andreas

Hallo alexander_ro,

schon den Beitrag: Teilweiser Import vom Shape-Dateien gelesen? Vielleicht helfen einige Tips aus dem Beitrag weiter.



mfg

fristo

Hallo,

Das mag alles sein, aber 6.000.000 Datenbewegungen pro Woche (!!!) schafft auch noch ein 486 spielend.

ja klar, und bei Google läuft ein PIII mit 500 Mhz. Daß das ein 486 schaft wenn er nur eine Tabelle mit einem Feld hat ist klar. Deine Einschätzung ist meiner Meinung nach mehr als unrealistisch. Die 6.000.000 wenn nur inserts sind mit geringer Datenmenge gebe ich Dir recht aber zum löschen der alten Datensätze müssen diese erst mal ermittelt werden und dann unter Beachtung der zu aktuallisierenden abhängigkeiten gelöscht werden.

Die Daten der Inserts, wie kommen die rein? Auf einem Schwung via Schnittstelle? Falls ja, würde hier z.B. schon der Umstieg zu COPY viel bringen.

Die Daten kommen aus XML-Dateien und werden per Insert in die Datenbank geschrieben. Aber die Inserts sind nicht wirklich das Problem. Das was sehr viel Zeit kostet ist die Suche der veralteten Sätze und die Löschung derselbigen. Auserdem glaube ich nicht daß ein konvertieren der XML-Daten in ein copy taugliches Format und dann einlesen in die DB sehr viel bringen würde. Ein anderer Punkt ist dass das einlesen der XML-Daten fertig und getestet ist und ich ungern daran noch umfangreiche Änderungen machen möchte.

Machst Du regelmäßig ein VACUUM bzw. auch mal ein VACUUM FULL? Die Problematik der toten Tupel kennst Du, oder?

Ja mache ich und ist mir bekannt.

Hast Dir mal Explain bei Suchabfragen angeschaut?

Explain habe ich mir angesehen und auch Zeitmessungen innerhalb der Anwendung gemacht. Die meiste Zeit braucht das Parsen der XML-Daten und das Löschen der veralteten Produkte.

Welche Version von PG einklich?

7.4.7 Debian Sarge

Gruß
Alexander

Was spricht gegen ein Update auf 8.x?

Ich unterstelle mal, die Such-Operationen haben mehr als ein Kriterium, nach denen selektiert wird.
Gerade seit 8.1 mit Bitmap Index Scan sind solche Dinge erheblich schneller geworden.

Andreas

Hallo,

Mir ist nicht ganz klar was mir der Beitrag bringen soll. Ist kein Windows und die Prozesse die sonst laufen sind ssh und notwendige System eigene also init, mgetty usw.

Gruß
Alexander

Eigentlicht nichts auser dass ich mich dann um Security-Updates selbst kümmern muß und jetzt das von den Debian Machern erledigt wird. Ja die haben mehrere kriterien. Zum Teil auch Verknüpfungen über mehrere Tabellen.

Alexander

Das würde dann einiges bringen. Du kannst von 7.4 zu 8.1 durchaus von Faktor 10 ausgehen.

Andreas

Btw.: IMHO ist seit 8.2 da ist 7.4 nicht mehr vom PG-Team supportet. Und PG hat in seiner Geschichte vergleichsweise wenig und wenn ja dann harmlose Security-Probleme gehabt…


Andreas

Stimmt habe eigentlich sehr selten Updates gesehen.

Faktor 10 ist eine ganze Menge das würde den Aufwand sicher rechtfertigen. Mit 4,2 Mio. * 30 das sind doch einige Datensätze die Eportiert/Importiert werden müssen. Wie lange das wohl dauert?

Wenn ich die letzen Postings mir so ansehe ist meine Anfängliche Frage etwas ins hintertreffen geraten. Gibts eine Lösung für die verteilte Ausführung von SQL-Befehlen oder nicht?
Oder gibt es andere Datenbanke die das können, nicht dass ich wechsel wollte lieber bau ich mir eine Lösung aber es wäre mal interessant zu wissen.

Ich habe in der Zwischenzeit ein wenig über das Problem noch nachgedacht und hätte eine Idee muß die aber noch etwas präzisieren und bedeutet sicher einiges an Entwicklungsaufwand wenns sowas aber noch nicht gibt könnte sich der Aufwand lohnen. Mich hat die Art wie das Netzwerkfilesystem OpenAfs arbeitet darauf gebracht.

Alexander

Einiges. Falls Du die Chance nutzen kannst, Deinen PIII (wenn ich das recht verstanden hab…) gegen was besseres von ALDI ersetzen zu können, dann installier das neue System und nutze das pg_dump(all) vom neueren System. 7.4 frißt Daten, zumindest u.U.

Das mit dem Faktor 10 kannst Du in etwa glauben. Der Sprung von 7.4 zu 8.0 kam mir nicht sooo dolle vor, aber 8.0 zu 8.1 war gewaltig dank dem Bitmap Index - Dingens. Was 8.2 nochmals zu 8.1 bringt muß ich erst mal selbst erkunden. Meine fetteste table hat knapp 2 Millionen Rows und Abfragen dauern, bei 3 oder mehr Kriterien, unter 0,x ms. (indexe jeweils), Rechner ist 2 Jahre alt, ATHLON mit 2 GHz oder so, nix besonderes.

Beispiel:

scholl=*# explain analyse select uf from hey_bde.bde_meldungen where datum = '2005-08-30' and maschine = 1200 and ab = 334045 and pos = 2 ;
                                                         QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on bde_meldungen  (cost=6.16..10.18 rows=1 width=15) (actual time=0.167..0.188 rows=4 loops=1)
   Recheck Cond: ((maschine = 1200) AND (datum = '2005-08-30'::date) AND (ab = 334045))
   Filter: (pos = 2)
   ->  BitmapAnd  (cost=6.16..6.16 rows=1 width=0) (actual time=0.143..0.143 rows=0 loops=1)
         ->  Bitmap Index Scan on idx_combi  (cost=0.00..2.71 rows=118 width=0) (actual time=0.086..0.086 rows=111 loops=1)
               Index Cond: ((maschine = 1200) AND (datum = '2005-08-30'::date))
         ->  Bitmap Index Scan on idx_ab  (cost=0.00..3.20 rows=343 width=0) (actual time=0.039..0.039 rows=55 loops=1)
               Index Cond: (ab = 334045)
 Total runtime: 0.273 ms
(9 rows)

Das war früher, bei weniger Daten, deutlich zäher. Ich hab hier vielleicht sogar blöde Indexe, resultierend aus der Tatsache, daß das schon ein paar Jahre läuft und ich nix geändert hab.
(kombinierte Indexe auf mehreren Spalten)

Wenn ich die letzen Postings mir so ansehe ist meine Anfängliche Frage etwas ins hintertreffen geraten. Gibts eine Lösung für die verteilte Ausführung von SQL-Befehlen oder nicht?

Wenn Du N Server mit exakt gleiche Daten hast, dann sicherlich trivial mit Pooling-Lösungen.
(für Abfragen only)

Oder gibt es andere Datenbanke die das können, nicht dass ich wechsel wollte lieber bau ich mir eine Lösung aber es wäre mal interessant zu wissen.

Angeblich kann ORA da einiges. Bin ich aber kein Experte von. Auf Arbeit tut eine ORA 8.x, und
es macht definitiv keinen Spaß, damit zu arbeiten. Der CLI-Client ist einfach nur schlecht. Und das ist noch sehr vorsichtig formuliert. Und echte Replikation mit ORA kostet richtig Geld. Was die taugt, kann ich mangels Erfahrung nicht sagen.

Ich habe in der Zwischenzeit ein wenig über das Problem noch nachgedacht und hätte eine Idee muß die aber noch etwas präzisieren und bedeutet sicher einiges an Entwicklungsaufwand wenns sowas aber noch nicht gibt könnte sich der Aufwand lohnen. Mich hat die Art wie das Netzwerkfilesystem OpenAfs arbeitet darauf gebracht.

Die Idee, sowas zu machen, ist sicherlich verlockend. Aber eine technische Realisierung, die das auch performant und stabil macht, ist nicht mehr trivial. Mir ist bekannt, daß es wohl Leute aus dem PG-Team gibt, die da mehr oder weniger dran basteln. Aber die halten sich da noch sehr bedeckt…

Alexander

Andreas

Performance Tricks:

  1. schriebe deine WAL Files auf eine seperate Platte
  2. schreibe deine Logs auf eine seperate Platte
  • pg_xlog
  • pg_clog
  • pg_log
  1. Autovacuum full ausführen
  2. reindex database force ausführen
  3. schau dir mal die Indicies von deinen Tabellen an

Einiges. Falls Du die Chance nutzen kannst, Deinen PIII (wenn ich das recht verstanden hab…) gegen was besseres von ALDI ersetzen zu können, dann installier das neue System und nutze das pg_dump(all) vom neueren System. 7.4 frißt Daten, zumindest u.U.

Nein kein PIII ein “AMD Athlon™ 64 Processor 2800+” laut cpuinfo. Zur Zeit werde ich mal bei diesem Rechner bleiben. Bis ich eine Lösung weiss wie ich dem ganzen Beine mache.

Das mit dem Faktor 10 kannst Du in etwa glauben. Der Sprung von 7.4 zu 8.0 kam mir nicht sooo dolle vor, aber 8.0 zu 8.1 war gewaltig dank dem Bitmap Index - Dingens. Was 8.2 nochmals zu 8.1 bringt muß ich erst mal selbst erkunden. Meine fetteste table hat knapp 2 Millionen Rows und Abfragen dauern, bei 3 oder mehr Kriterien, unter 0,x ms. (indexe jeweils), Rechner ist 2 Jahre alt, ATHLON mit 2 GHz oder so, nix besonderes.

Spricht eigentlich was dagegen wenn ich gleich die Version 8.2 nehme?
Hast Du zufällig eine Sinnvolle Zusammenstelleung der konfigurations Parameter? Ich habe schon mal vor einiger Zeit eine PG-Version selbst zusammengebaut aber da gingen dann einige praktische Dinge nicht (z.B. Befehlswiederhohlung in psql).

Die Idee, sowas zu machen, ist sicherlich verlockend. Aber eine technische Realisierung, die das auch performant und stabil macht, ist nicht mehr trivial. Mir ist bekannt, daß es wohl Leute aus dem PG-Team gibt, die da mehr oder weniger dran basteln. Aber die halten sich da noch sehr bedeckt…

Das größte Hindernis einer verteilten Lösung ist es einen Index Datenbankübergreifend aufzubauen. Ich kenne aber keinen Weg wie das gehen könnte. Sowas wie eine Userverwalteten Idex glaube ich gibt es nicht.

Für den rest gibts schon eine Menge fertige Hilfe wie zum Beispiel das Message Passing Interface (MPI) dazu gab es in der c’t 26/2006 eine Artikel. Das würde einem schon viel arbeit abnehmen. Einen Auszuführenden SQL müsste man zerlegen und dann die Ergebnisse wieder zusammenführen. Wenn die Server dann wie bei dem schon genannten OpenAFS einen Master vereinbaren kann der bei Inserts für die gleichmäsige Verteilung auf den Servern sorgen. Aber ein Select erfordert für seine kriterien einen DB übergreifenden Index sonst wird das schwierig.

nylen:
Das mit den Logfiles hatte ich auch schon versucht. Bringt aber nicht viel. An dem Rechner hängen 3 schnelle SCSI-Festplatten als Raid0. Nach meinen Tests ist für das Zeitintensive Löschen der alten Producte nicht die Platte der Engpass sondern die CPU. Bei den inserts bremsen die Platten aber die inserts sind so schon in relativ kurzer Zeit erledigt und der Gewinn an dieser stelle reicht nicht aus. Es ist ja nicht nur das aktualisieren der Produkte der Zeitgewinn muß so groß sein dass Tagsüber die Produktivzugriffe schnell laufen. Davon bin ich aber Meilenweit entfernt.

Alexander

Nein, natürlich nicht.

Hast Du zufällig eine Sinnvolle Zusammenstelleung der konfigurations Parameter? Ich habe schon mal vor einiger Zeit eine PG-Version selbst zusammengebaut aber da gingen dann einige praktische Dinge nicht (z.B. Befehlswiederhohlung in psql).

Ich verwende einklich immer Debian-Packete. Wenn Du selber baust und die History in psql fehlt, dann hast Du wohl libreadline vergessen.


Andreas

Gibts von Debian Pakete für die 8.1 oder 8.2. Ich habe keine gefunden.

Alexander

Ja.
deb http://people.debian.org/~mpitt/packages/sarge-backports/ /

08:44 < rtfm_please> For information about debian
08:44 < rtfm_please> see http://packages.debian.org/unstable/misc/postgresql.html
08:44 < rtfm_please> or http://people.debian.org/~mpitt/packages/sarge-backports/
08:44 < rtfm_please> or http://people.debian.org/~mpitt/postgresql-ng.html

und 8.2:

http://packages.debian.org/experimental/misc/postgresql-8.2

Ich nutze 8.1 von mpitt.

Hallo,

ich habe jetzt einen Versuch gemacht die Version 8.1 mit dem Debian Testing zu installieren. Das macht aber erhebliche Probleme mit abhängigkeiten. Der Rest meines Systems ist ja stable.

Das zweite Problem ist dass es scheinbar nicht möglich ist die zweite DB-Version parallel zu installieren. Ich wollte eigentlich die neue Datenbank dann gleichzeitig aufbauen wärend ich mit der alten weiter arbeite. Die müssten nicht gleichzeitig laufen.

Wenn ich das richtig verstanden habe ist doch das was zur Zeit unter testing von Debian gemacht wird das nächste release Etch und soll nach höhren sagen schon in recht fortgeschrittenem Zustand sein. Ich habe auf dem Rechner nur wenig laufen (DB, SSH). Ob es vielleicht besser ist gleich ein eigene Partition mit testing zu installieren. Sicherheitstechnisch zwar nicht Optimal aber ich weiss nicht wie das sonst laufen soll.

Gruß
Alexander