Neue Clientanfrage = neuer Prozess?

Hallo PG-Profis,
wir starten ein umfangreiches Web-Projekt bei dem viele Web-Anfragen, Updates und intensiv querverknüfpte Datebankinhalte zu erwarten sind.
Daher suchen wir ein DBMS das stabil, performant, gut dokumentiert, skalierbar usw. ist.
PG ist dabei in die engere Wahl gekommen. Was mich wundert ist der Hinweis, dass PG zur Bearbeitung jeder neuen Clientanfrage einen neuen Prozess startet? Stimmt das? Wenn ja, wo liegt der Performance-Vorteil? Mir erscheint es als Nachteil, da 1. ein neuer Prozess instanziert werden muss 2. ein Kontextwechsel notwendig ist 3. etwaige Parameter im Speicher umkopiert werden müssen.

In diesem Zusammenhang macht es mich ebenfalls skeptisch, dass keine wirklich großen Projekte als Referenzen genannt werden. Was setzten Betreiber ein, die zig Terabyte große Datenbanken verwalten und zig Mio. PageImpressions pro Tag mit entsprechenden DB-Suchen und Updates zu verwalten haben? Sind das alles Oracle-Kunden? :wink:

Sicher Fragen, die schon oft aufgetaucht sind, aber die Forensuche hat mir keine gescheiten Suchergebnisse geliefert.
Danke für die Antworten.
Grüße mea

Willkommen!

PG ist dabei in die engere Wahl gekommen. Was mich wundert ist der Hinweis, dass PG zur Bearbeitung jeder neuen Clientanfrage einen neuen Prozess startet? Stimmt das? Wenn ja, wo liegt der Performance-Vorteil? Mir erscheint es als Nachteil, da 1. ein neuer Prozess instanziert werden muss 2. ein Kontextwechsel notwendig ist 3. etwaige Parameter im Speicher umkopiert werden müssen.

Ja, so gesehen stimmt das. Aber ein Apache oder ein Exim oder andere Dienste machen das auch, incl. Oracle.
Der Aufwand dafür ist aber minimal, dafür kann das dann aber auch auf einer Multiprozessor-Maschine skalieren.
Dann werden halt alle verfügbaren CPUs genutzt, um die Prozesse aufzuteilen.

In diesem Zusammenhang macht es mich ebenfalls skeptisch, dass keine wirklich großen Projekte als Referenzen genannt werden. Was setzten Betreiber ein, die zig Terabyte große Datenbanken verwalten und zig Mio. PageImpressions pro Tag mit entsprechenden DB-Suchen und Updates zu verwalten haben? Sind das alles Oracle-Kunden? :wink:

http://www.postgresql.org/about/casestudies/


Andreas

Zusätzlich zu dem, was akretschmer geschrieben hat:

Bei Oracle kenne ich das und Mysql erledigt (ausser unter Windows, dort werden Threads mit allen Vor- und Nachteilen genutzt) das auf die gleiche Art und Weise. Ist halt ein fork() mehr, den Read-Only Teil hat das OS sowieso schon im Speicher und mappt das bloss, die veränderlichen Daten müssen dann halt irgendwann einmal kopiert werden.

Um auf eure Vorraussetzungen einmal einzugehen:

  • Dokumentation: siehe Webseite, jede Minor Version hat seinen eigenen, sehr gut dokumentierten Versionszweig. Dort sind Beispiele aufgeführt, Anleitungen, jede Menge Hinweise und im Falle des Falles auch Kompatibilitätsunterschiede zum SQL Standard.
  • Performance und Skalierbarkeit: ich verweise mal auf: http://tweakers.net/reviews/657 Das sollte genug sagen. Ok, mit einer Oracle bekommt ihr vielleicht noch etwas mehr … für mehr Geld :wink:
  • Stabil: es gibt umfangreiche Regressiontests, die die Datenbank vor einem Release durchläuft und diese werden mit neuen Features auch ständig erweitert. Es ist eine ganze Weile her, das ich von Sicherheitsproblemen im Zusammenhang mit PostgreSQL gelesen habe und von Datenverlusten (ausser durch Fehlbedienung, Hardwareprobleme ect.) ist mir noch kein gutes Beispiel untergekommen.

Nun, ihr scheint da ein Projekt zu planen, wie wir es gerade abschliessen: 102 Tabellen, 13 davon in Public, die restlichen 89 existieren für jede Stadt noch einmal in einem separaten Schema. 78 Trigger für die erste Stadt, 9 Funktionen je Stadt, 69 Funktionen in public. Das ganze ist just heute in den Betatest gegangen, da werden noch ca. 10 GB Altdaten reinimportiert, die aus einer Mysql kommen.
Und wir sind froh, das alte System so langsam abschiessen zu können, da gab es mehr als genug Probleme :smiley:

Das ist richtig. Allerdings würde es für die Verteilung auf mehrere CPUs ausreichen, neue Threads anzulegen. Vorteil: Gemeinsamer Speicherbereich=weniger Kontext etc.
Ich wüsste gerne ~warum~ bei PG ganze Tasks gestartet werden.

eben. Die genannten CaseStudies beschränken sich auf wenige hundert GB Daten und/oder nur wenige 100Tausend User bzw. 3Mio PageImpressions pro Monat. Das ist zwar nicht wenig, aber auch nicht richtig viel. Was benutzt Amazon.com ? Was nutzt die Weltbank? Sowas wäre hochinteressant um zu wissen, dass auch Terabyte-Datenbanken auf viele Server verteilt mit PG effizient laufen, wobei ich das PG aufgrund der Architektur durchaus zutraue.

Danke für den Link. Die Benchmarks lassen mySQL wiedermal alt aussehen :slight_smile:
Schade, dass darin nicht auch die “beiden” kostenpflichtigen DBMS mit auftauchen…nur um zu sehen, wie groß der Abstand wirklich ist.

Danke für die schnellen und passenden Infos.
Grüße mea

Also es gibt durchaus auch Anwender (frag mal im englischsprachigen IRC Channel #postgresql), die bedeutend größere Datenmengen verwalten.

22:27:54 < xzilla> ads: omniti
22:28:13 < xzilla> ads: we have customer information, email stuff, web traffic logs, all kinds of jazz

Also auch Daten, die sich schnell ändern.


Die Diskussion, ob PG Threads oder Childs verwenden soll, ging bereits sehr, sehr häufig über die Mailinglisten. Der Konsens ist, das man bei Childs bleibt, um all die Probleme, die man bei Verwendung von Threads beachten muss, nicht zu haben. Als die 8.x Versionen native auf Windows portiert wurden, kam da einiges zum Vorschein. Es gibt sicherlich gute Argumente dafür, die aktuellen, die dagegen sprechen, leuchten mir im Sinne der Stabilität aber durchaus ein.

Du warst zu schnell, er ergänzte noch dies:

22:35 < xzilla> ads: fwiw we generate about 2.5 GB of wal logs per hour
22:36 < ads> nice

Und, naja, ich sag mal so: ich kenne Leute, die aufgrund der von Ihnen unterschriebenen NDA nicht sagen dürfen, welche großen Kunden ORA grad an PG verliert…


Andreas

sicher. Ich wollte auch keine Prinzipien-Diskussion auslösen :slight_smile:

mea

Hehe, ok.
Es gab halt speziell unter Windows, dort werden Threads genutzt, das ein oder andere Problemchen, das sich nur sehr schwer debuggen lässt. Ob da der kleine Startup Performancevorteil die vielen Nachteile und potentiell versteckten Bugs aufwiegt …