Hallo Leute!

Ich bin neu und hoffe mit meinem Einstandathema eine angeregte Debatte
loßtreten zu
können, rund um das Thema Performance von PostgreSQL 8.3 unter Unixoide=
n
Betriebssystemen. :-)

Besonders würde mich (wenn vorhanden) euere ganz persöhnlichen Eindrü=
cke
und Schilderungen
zu eueren Projekte interessieren wie ihr Postgres einsetzt, wir ihr
Peakspitzen bewältigt (denke
mal dass das bei Websites schon ziemlich wichtig ist) und wie ihr euere
Skalierbarkeitspfade
evaluiert. Da es im Subject steht, würde ich auch gerne von euch wissen=

wie es mit euerem
Server OS aussieht. Was benutzt ihr? Welche Distri (Linux) oder welche
Unix Edition benutzt
ihr im Performancekritischenbereich wenns um die Auswahl des richtigen
OS geht?

Grüße,
Rudi

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

rudi [at] je-more.de wrote:
> Ich bin neu und hoffe mit meinem Einstandathema eine angeregte Debatte
> loßtreten zu
> können, rund um das Thema Performance von PostgreSQL 8.3 unter Unixoide=
n
> Betriebssystemen. :-)
>
> Besonders würde mich (wenn vorhanden) euere ganz persöhnlichen Eindr=
ücke
> und Schilderungen
> zu eueren Projekte interessieren wie ihr Postgres einsetzt, wir ihr
> Peakspitzen bewältigt (denke
> mal dass das bei Websites schon ziemlich wichtig ist) und wie ihr euere=

> Skalierbarkeitspfade
> evaluiert. Da es im Subject steht, würde ich auch gerne von euch wissen=

> wie es mit euerem
> Server OS aussieht. Was benutzt ihr? Welche Distri (Linux) oder welche
> Unix Edition benutzt
> ihr im Performancekritischenbereich wenns um die Auswahl des richtigen
> OS geht?

=DCber persönliche Eindrücke kann man - so hoffe ich - nicht hitzig dis=
kutieren,
aber mitteilen kann man sie.

Wir haben 8.2 im Einsatz und werden 8.3 wahrschinlich überspringen.

Wir setzen RedHat Enterprise Linux ein, weil das bei allen unseren neueren
UNIX-Maschinen zum Einsatz kommt. Für PostgreSQL würden da keine
Extrawürste gebraten werden. Wir sind ein eher ziemlich großer Betrieb.

Wir haben uns eigene RPM-Pakete für PostgreSQL geschrieben, um
a) unseren DBAs die Arbeit zu erleichtern, b) eigene Patches, Add-Ons
und Nonstandard-Konfigurationsparameter verwenden zu können und
c) damit wir einfach mehr als einen Cluster auf einer Maschine betreiben k=
önnen.
Automatische =DCberwachung geschieht durch eine einfach gestrickte Patrol-
Lösung und wäre sicher verbesserungsfähig.

Wir haben sehr gute Erfahrungen mit PostgreSQL gemacht; die größten Pro=
bleme
im Entwicklungsbereich haben wir mit Npgsql (.NET-Provider), das für
unsere auf Windows laufenden Web-Applikationen zum Einsatz kommt.

Performancekritische Projekte hatten wir erst eines, bei dem RHEL 5.1
zum Einsatz kommt. Dort haben wir festgestellt, daß Booten mit dem Parame=
ter
'elevator=3Ddeadline' die I/O-Performance vervierfacht hat (Kernel 2.6).
Gennauere Beschreibung des Setup siehe
http://archives.postgresql.org/pgsql-performance/2008-04/msg 00148.php

"Skalierbarkeitspfade evaluieren" klingt für mich - mit Verlaub -
nach Quality Assurance Consultant-Geschwätz. Was ist damit wirklich gemei=
nt?

Liebe Grüße,
Laurenz Albe

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Albe Laurenz wrote:

> "Skalierbarkeitspfade evaluieren" klingt für mich - mit Verlaub -
> nach Quality Assurance Consultant-Geschwätz. Was ist damit wirklich g=
emeint?

Damit ist gemeint "wie oft kann ich meinen dicken Datenbank-Hobel durch
einen noch dickeren Datenbank-Hobel ersetzen bevor ich meine Applikation
den neuen Gegebenheiten anpassen muss." und in Folge "Wie geht das?".

Mag jetzt für österreichische Verhältnisse unrealistisch sein, aber=
gut
gehende "neue" Websites können Zeiten haben, wo sich jedes Monat an die=

Zahl der Visitors/angemeldeten User eine Null dranhängt, und wenn man d=
a
noch kein gut skalierendes System hat kanns sein, dass man mit dem
Server-ins-Rack-schrauben nicht mehr nachkommt ;).

Und für Rudi: http://www.amazon.de/dp/067232699X/ ist ein guter Einstie=
g
in das Thema.


lg,
michael

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Michael Renner wrote:
>> "Skalierbarkeitspfade evaluieren" klingt für mich - mit Verlaub -
>> nach Quality Assurance Consultant-Geschwätz. Was ist damit wirklich ge=
meint?
>
> Damit ist gemeint "wie oft kann ich meinen dicken Datenbank-Hobel durch=

> einen noch dickeren Datenbank-Hobel ersetzen bevor ich meine Applikation=

> den neuen Gegebenheiten anpassen muss." und in Folge "Wie geht das?".

Danke für die =DCbersetzung.

Also die Frage ist: wie plane ich meine Architektur, damit sie ausbaufähi=
g ist.
Ich fürchte, daß läßt sich schwer allgemein beantworten... Das kommt
auf die Gegebenheiten und Anforderungen im Einzelfall an.
Erfahrung, technische Kenntnisse und gute analytische Fähigkeiten braucht=
man da.

> Mag jetzt für österreichische Verhältnisse unrealistisch sein,

Dazu schweige ich lieber und lächle.

Liebe Grüße,
Laurenz Albe

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Hi!

Am Freitag 02 Mai 2008 09:32:40 schrieb Albe Laurenz:
> Wir haben sehr gute Erfahrungen mit PostgreSQL gemacht; die größten
> Probleme im Entwicklungsbereich haben wir mit Npgsql (.NET-Provider), das
> für unsere auf Windows laufenden Web-Applikationen zum Einsatz kommt.

Welche Probleme hattet ihr mit Npgsq? Bei mir wahr es die fehlende Massieru=
ng
des einfachen Hochkomma. Unter Linux und Windows gleichermaßen.

Olaf

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Olaf Radicke schrieb:
> Welche Probleme hattet ihr mit Npgsq? Bei mir wahr es die fehlende Massierung
> des einfachen Hochkomma.
aber jetzt massiert Ihr die Hochkomma ausreichend und alles ist gut?

sorry, aber bei diesem Tippfehler konnte ich einfach nicht anders.... ;-)



--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Olaf Radicke schrieb:
>> Wir haben sehr gute Erfahrungen mit PostgreSQL gemacht; die größten
>> Probleme im Entwicklungsbereich haben wir mit Npgsql (.NET-Provider), das
>> für unsere auf Windows laufenden Web-Applikationen zum Einsatz kommt.
>
> Welche Probleme hattet ihr mit Npgsq? Bei mir wahr es die fehlende Massie=
rung
> des einfachen Hochkomma. Unter Linux und Windows gleichermaßen.

SQL-Injection?

Wir hatten bisher folgende Probleme:

- Client-Prozeß hängt sich auf mit 100% CPU, wenn wir größere Werte=
über
eine SSL-verschlüsselte Verbindung speichern. Wurde durch eine neue
Mono.Security.dll behoben.
- Client-Prozeß schickt bei einer SSL-Renegotiation 2 überflüssige By=
tes,
die die Datenbankverbindung zum Absturz bringen.
Dies ist ein bisher nicht behobener Fehler der Mono.Security.dll.
- Bei standard_conforming_strings=3Don wurden Backslashes falsch
interpretiert. Behoben in Npgsql 1.0.1.

Hauptsächlich sind es also Mono-Bugs, an denen wir zu kauen hatten.
Die betreffen einen nicht, wenn man keine verschlüsselten Verbindungen
verwendet.

Liebe Grüße,
Laurenz Albe

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Am Freitag 02 Mai 2008 14:57:13 schrieb Albe Laurenz:
> Hauptsächlich sind es also Mono-Bugs, an denen wir zu kauen hatten.
> Die betreffen einen nicht, wenn man keine verschlüsselten Verbindungen
> verwendet.

Das betrifft auch meine Applikation. Darum: gut zu wissen. Danke.

Olaf

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

On Fri, 2 May 2008 10:38:40 +0200 Albe Laurenz wrote:

> Michael Renner wrote:
> >> "Skalierbarkeitspfade evaluieren" klingt f=C3=BCr mich - mit Verlaub -
> >> nach Quality Assurance Consultant-Geschw=C3=A4tz. Was ist damit wirkli=
ch gemeint?
> >
> > Damit ist gemeint "wie oft kann ich meinen dicken Datenbank-Hobel durch=

> > einen noch dickeren Datenbank-Hobel ersetzen bevor ich meine Applikatio=
n
> > den neuen Gegebenheiten anpassen muss." und in Folge "Wie geht das?".
>
> Danke f=C3=BCr die =C3=9Cbersetzung.
>
> Also die Frage ist: wie plane ich meine Architektur, damit sie ausbauf=C3=
=A4hig ist.
> Ich f=C3=BCrchte, da=C3=9F l=C3=A4=C3=9Ft sich schwer allgemein beantwort=
en... Das kommt
> auf die Gegebenheiten und Anforderungen im Einzelfall an.
> Erfahrung, technische Kenntnisse und gute analytische F=C3=A4higkeiten br=
aucht man da.

Das ist richtig - nur m=C3=BCssen diese Erkentnisse teilweise schon in die
Entwicklung der Plattform einflie=C3=9Fen.

Es bringt =C3=BCberhaupt nichts, wenn ein f=C3=A4higer Admin die Datenbanken
betreut - und die Webdesigner wild irgendwelche unperformanten Anfragen
da drauf loslassen d=C3=BCrfen.


Bis dann

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

> "Skalierbarkeitspfade evaluieren" klingt für mich - mit Verlaub -
> nach Quality Assurance Consultant-Geschwätz. Was ist damit wirklich g=
emeint?
>
> Liebe Grüße,
> Laurenz Albe
Danke Albe für deinen Bericht.

Nun ja, Skalierbarkeitspfade sind Wege zur Skalierbarkeit (den Begriff
sollte ja nun jedem ein Begriff sein) ;D

Es fängt damit an, das ich eine WebApplication plane, z.B mit Tomcat al=
s
Webcontainer für dynamisches HTML
und als Zugriffstreibergepsann auf die PostgreSQL DB ein Class 4
JDBC-Treiber mit vorgeschaltenen Apache
Connectionpooler (DBCP) aus den Apache Commons (entspricht einer Tomcat
Standard DB-Verbindung auch
zu anderen DB's ausser Postgres).

Meine intuitiven (gedachten) Skalierbarkeitspfade sind hier:

1.Server mit mehr RAM ausrüsten
2.SCSI Disk-Subsystem mit RAID 0 / 1 oder Kombination mit RAID Stripeset
3.OS sollte einen Kernel mit 64-Bit haben der SMP unterstützt
4.OS sollte einen Kernel haben das mit Peakspitzen und unter Vollast
reaktionsfähig bleibt.
5.Das Dateisystem sollte kein Jounaling FS sein, da Postgres FSync
offenbar dadurch ausgebremst wird.
6.Die Filesystemblockgrösse sollter der entsprechen, wie Postgres sie
von der Disk liest und schreibt (ist z.B bei den BSD's so)
7.Tablespaces anlegen, die auf verschiedenen Disks liegen, wenn möglich=

mit verschiedenen SCSI Controllern verbunden.
8.Prepared Statemets wo es geht, grössere Insert Operationen mittels
Copy statt SQL INSERT
9.PostgreSQL 8.3 oder höher verwenden um von der Leistungssteigerung
durch asynchrone Commits zu profetieren.
19.PostgresSQL 8.3 oder höher verwenden um von den Verteilten
Checkpoints zu profitieren (checkpoint_completion_target)

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

rudi [at] je-more.de wrote:

> Meine intuitiven (gedachten) Skalierbarkeitspfade sind hier:

[..]

Alles was du da beschrieben hast sind Tunings an der (gemeint ist:
_DER_) Datenbank. Die sind sehr zu begrüßen, besonders wenn die Leist=
ung
der Maschine durch simple Modifikationen deutlich verbessert werden
kann; Skalierbarkeitspfade fangen aber meistens dort an wo es nichtmehr
_DIE_ Datenbank gibt ;). Zumindest nichtmehr als Alleinherrscherin über=

"alle Daten wo gibt".

Tuning des Basis-Systems sollte mit dem Operations-Team in Kombination
mit "dem Internetz" [1] schon vorab analysiert/erarbeitet werden (wenn
das System in absehbarer Zeit deutliche Lastzuwächse bekommen wird);
falls es zu einzelnen Punkten fragen gibt kann man die hier gerne erört=
ern.

Viel wichtiger ist allerdings die Frage "Wird der Punkt bald kommen an
dem _DIE_ Datenbank nicht mehr reicht?" und gleich darauf "Und dann?".

lg,
michael


[1] Und da das Internetz meistens eine blöde Sau ist wenn man sinnvolle=

Information sofort in aufbereiteter Form haben möchte:

Eine Liste von Links die ich zusammengetragen habe:
http://del.icio.us/terrorobe/postgresql%2Bperformance

Und hier das was der Bot in #postgresql-de auf freenode ausspuckt:

<pg_docbot_adz> For information about 'performance' see:
<pg_docbot_adz>
http://www.depesz.com/index.php/2007/07/05/how-to-insert-dat a-to-database=
-as-fast-as-possible/
:: http://www.postgresql.org/docs/current/static/performance-ti ps.html
:: http://www.revsys.com/writings/postgresql-performance.html
<pg_docbot_adz> http://www.powerpostgresql.com/Docs ::
http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html


--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Danke für die Links, doch Du kannst mir vertrauen, wie man Google oder
die Maillinglisten
durchsucht habe ich schon selber herrausbekommen.

Ich stehe an dem Punkt wo ich Erfahrungsberichte in der
Entscheidungsfindung berücksichtigen möchte.
Das lässt sich durch keine Google oder Suchfunktionen ermitteln, sonder=
n
eher durch einen
gezielten, konstruktiven Dialog.

Performancetuning ist sicherlich auch ein Teil eines
Skalierbarkeitspfads, wenn es dazu dienlich ist den
operative Betrieb günstig zu gestalten und Lösungswege erschließt w=
ie
man damit in Zukunft besser umgehen kann.

Für mich stellen sich in der momentanen Planung eher die Fragen:
FreeBSD oder Linux?
SCSI oder SATA? (wie siehts mit FreeBSD Treiber dafür aus)
Kann man Slony dafür verwenden eine Terrabyte Datenbank effizient zu
spiegeln? (nur spiegelung, keine Schreibzugriffe, aber lesende Abfrage)
Auf welchen Layer soll ich das DB Loadbalancing implementieren und wie?


--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

rudi [at] je-more.de wrote:

> Performancetuning ist sicherlich auch ein Teil eines
> Skalierbarkeitspfads, wenn es dazu dienlich ist den
> operative Betrieb günstig zu gestalten und Lösungswege erschließt=
wie
> man damit in Zukunft besser umgehen kann.

Ja, nur ist dieses Thema sehr schnell erschöpft, und durch suboptimales=

Applikationsdesign in Kombination mit der dementsprechenden
Besucher/Systemlast verbrennt man in der Realität meistens deutlich meh=
r
Ressourcen als mit schlecht getuneten Subsystemen.

> Für mich stellen sich in der momentanen Planung eher die Fragen:
> FreeBSD oder Linux?

Das, mit dem das Operations-Team besser zurechtkommt. FreeBSD war bis
zum letzten Release performancemässig im Hintertreffen, allerdings
konnten die Jungs mittlerweile deutlich aufholen. [1]

> SCSI oder SATA? (wie siehts mit FreeBSD Treiber dafür aus)

Heutzutage lautet die Frage eher SAS oder SATA. SAS-Platten haben
durchgehend bessere seek-times als ihre SATA-Pendants; wenn du
schreiblastige Anwendungen hast, oder das Working Set der Datenbank
nicht mehr in den Page-Cache passt sollte man auf jedenfall in Richtung
SAS tendieren.

Ausserdem sollte man schauen, dass man einen Controller mit ausreichend
dimensionierten (Batterie-gestützten!) Write-Cache verwendet; das kann
einen bei periodischen Rewrites der selben Stripes (WAL, etc.) einiges
an Performance bringen.

FreeBSD-Treiber-Fragen kann ich nicht beantworten, aber wenn man mal
vergleicht wieviel Geld mittlerweile hinter Linux steckt, kann man
pauschal postulieren dass die Linux-Treiber deutlich besser gewartet
sein dürften ;).


> Kann man Slony dafür verwenden eine Terrabyte Datenbank effizient zu
> spiegeln? (nur spiegelung, keine Schreibzugriffe, aber lesende Abfrage)

Pet-Peeve-Alarm. Terra =3D=3D Das unter deinen Schuhen. Tera =3D=3D Ein S=
I-Prefix.

Pauschal-Antwort: Ja, kann man.

Längere Antwort: Schau dir mal an wie Slony arbeitet und ob die daraus
resultierenden Parameter bei einem Betrieb in deiner Umgebung tragbar
sind oder nicht. Interessant sind v.a. Performance beim replizieren,
Rebuild von Nodes wenn sie ausgefallen sind sowie Wartung im Allgemeinen
(DDL-Replikation etc.).

> Auf welchen Layer soll ich das DB Loadbalancing implementieren und wie?

Für diese Frage gibts bei PostgreSQL (gottseidank?) keine
Pauschalantwort und ich hab mich mit dem Thema bis jetzt nicht wirklich
beschäftigt um hier sinnvoll Auskunft geben zu können.

Ich kann nur mitgeben, dass man DB-Loadbalancing grundsätzlich nur bei
geclusterten Datenbeständen machen sollte (jede Node hält einen Teil =
der
Daten), da die gängige Methode des "Read-only Slaves" nur begrenzt
skalierbar ist und Konsistenz- (Asynchrone Replikation) oder
Performanceprobleme (Two-phase Commit) mit sich führt.

lg,
michael


[1] http://bsd.slashdot.org/article.pl?sid=3D08/03/06/1313218

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Andreas 'ads' Scherbaum wrote:

>> Also die Frage ist: wie plane ich meine Architektur, damit sie ausbauf=
=C3=A4hig ist.
>> Ich f=C3=BCrchte, da=C3=9F l=C3=A4=C3=9Ft sich schwer allgemein beantw=
orten... Das kommt
>> auf die Gegebenheiten und Anforderungen im Einzelfall an.
>> Erfahrung, technische Kenntnisse und gute analytische F=C3=A4higkeiten=
braucht man da.
>
> Das ist richtig - nur m=C3=BCssen diese Erkentnisse teilweise schon in =
die
> Entwicklung der Plattform einflie=C3=9Fen.
>
> Es bringt =C3=BCberhaupt nichts, wenn ein f=C3=A4higer Admin die Datenb=
anken
> betreut - und die Webdesigner wild irgendwelche unperformanten Anfragen
> da drauf loslassen d=C3=BCrfen.

Ja, v=C3=B6llig deiner Meinung. Deswegen sollte man die Teams die solche
"dicken" Projekte umsetzen halbwegs interdisziplin=C3=A4r besetzen, damit=
man
nicht erst beim "Umdrehen des Z=C3=BCndschl=C3=BCssels" feststellen muss,=
dass der
Vogel nie fliegen wird. Regelm=C3=A4ssige Benchmarks durch die
Entwicklungsperiode durch, mit Lastmustern die der Realit=C3=A4t entsprec=
hen
sind da sehr n=C3=BCtzlich.

Das bedeutet alles nat=C3=BCrlich sp=C3=BCrbaren Mehraufwand (sowohl bei =
der
Teamzusammenstellung als auch bei der Projektgestehung), aber dies
sollte das Mindestma=C3=9F bei umfangreichen Projekten, die Heute im
IT-Umfeld umgesetzt werden, sein.

Zu diesem Thema bieten sich Parallelen aus der Bau-Branche an - man
l=C3=A4sst ja eine Br=C3=BCcke nicht von einer Gruppe Menschen aus _einem=
_
Fachbereich (zB einer Gruppe Spenglern) bauen die sich an einer Skizze
auf einem Taschentuch orientieren. Kann man machen, kann auch gutgehen,
professionell ists allerdings nicht. Aber anscheinend sind in der IT die
Kosten eines Versagens noch nicht prohibitiv genug um ein nachhaltiges
Umdenken in der Branche zu bewirken ;).

lg,
michael

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

So nun habe ich mich mal etwas in das Thema des Loadbalancing im Bereich
Postgres eingelesen. Derzeit eprobe ich Sequoia, einen JDBC Loadbalancer
der auch
Postgres unterstützt. Das System arbeitet auf der Basis der State
Replikation.

Für meine Anwendung gaukelt Sequoia ein normales PostgreSQL Backend vor=
,
tatsächlich greife ich via Sequoia nur auf eine virtuelle DB zu,
dahinter können sich
jedoch beliebig viele, spiegelgleich PostgreSQL Backends verstecken (die
von Sequoia
selbstständig hochrepliziert und somit neue Spiegel angelegt werden)
Theoretisch
funktioniert das ganze auch crossdb, es wird jedoch nicht empfohlen
also nutze
ich nur PostgreSQL als Backend.

Hat schon jemand mit Statement Replikation, Parallele Queries durch so
ein Tool
wie Sequoia oder PGPool2 durchgeführt und kann etwas über die
Performance sagen?
Ist Slony für das bereitstellen von Spielgen eventuell besser geeignet?




--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

On Sat, 17 May 2008 10:51:19 +0200 rudi [at] je-more.de wrote:

> Hat schon jemand mit Statement Replikation, Parallele Queries durch so
> ein Tool
> wie Sequoia oder PGPool2 durchgef=C3=BChrt und kann etwas =C3=BCber die=

> Performance sagen?
> Ist Slony f=C3=BCr das bereitstellen von Spielgen eventuell besser geeign=
et?

Niemand kennt deine Anwendung wirklich, bisher wissen wir nur, dass du
ganz viele Messages in einer Tabelle halten m=C3=B6chtest.

Statement-basierte L=C3=B6sungen sind nett ... allerdings muss man einige
Sachen beachten. Z.B. wie man mit Timestamps ect. umgeht. Das steht
aber imho auch in der FAQ so mit drin.


Slony dagegen ist eine Master-Slave L=C3=B6sung, aber auch hier wird die
Verwendbarkeit stark von deinen Anforderungen und deiner Applikation
abh=C3=A4ngen.


Der Vorschlag w=C3=A4re, f=C3=BCr deine Anwendung mal einen Anforderungskat=
alog
aufzustellen und dann zu schauen, welche Datenbank das erf=C3=BCllt. Alles
andere ist wildes Herumr=C3=BChren im Dunst der m=C3=B6glicherweise vorhand=
enen
Features.



Bis dann

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Andreas 'ads' Scherbaum schrieb:
> Statement-basierte L=C3=B6sungen sind nett ... allerdings muss man eini=
ge
> Sachen beachten. Z.B. wie man mit Timestamps ect. umgeht. Das steht
> aber imho auch in der FAQ so mit drin.
>
Du meinst wenn man eine zu "generalisierte" L=C3=B6sung einsetzt, die dan=
n
m=C3=B6glicherweise nicht mehr
in der Lage ist z.B Postgres Timestamps zu behandeln?

> Slony dagegen ist eine Master-Slave L=C3=B6sung, aber auch hier wird di=
e
> Verwendbarkeit stark von deinen Anforderungen und deiner Applikation
> abh=C3=A4ngen.
>
Slony ist gef=C3=A4hrlich, weil man mit dem Master doch wieder einen Sing=
le
point of Failure hat.

> Der Vorschlag w=C3=A4re, f=C3=BCr deine Anwendung mal einen Anforderung=
skatalog
> aufzustellen und dann zu schauen, welche Datenbank das erf=C3=BCllt. Al=
les
> andere ist wildes Herumr=C3=BChren im Dunst der m=C3=B6glicherweise vor=
handenen
> Features.
>

Ok, dann hoffe ich das es sowas wie ein kleiner Anforderungsplan ist
(der Priorit=C3=A4t nach).

1.
Geschwindigkeit auch unter Last bei vielen konkurierenden Insert/Select
Queries, desto schneller
desto besser (die User am Webfrontend sollen zu jeder Zeit in,
Bruchteilen von sek. ihre dynamischen
HTML Operationen durchf=C3=BChren k=C3=B6nnen (also sprich wie CGI/Perl/P=
HP das
auch machen).

2.
Das Projekt ist eine Communityseite,wo st=C3=A4ndig Nachrichten mittels
Inserts in Tabellenspalten eingef=C3=BCgt
werden (mid int =3D MessageNr) sender id (Verschicker) (recipid int =3D
Empfaenger), subject (TEXT) hier
kann quasi eine Bildschirmseite Text drin stehe (und dieses Feld macht
mir am meisten Kopfzerbrechen).
3.
Keine Downtimes durch Backup, Patch Update/Upgrade
4.
Keine Unterbrechnung des DB-Betriebs durch Hardwareprobleme
5.
Skalierbare Performance des Gesammtsystems durch hinzuf=C3=BCgen und
entfernen von
neuen DB Servern.

Appserver:
Applicationserver ist Apache Geronimo 2.1.1, 64-Bit AMD64 JRE 1.6.0_06,
Webserverlayer
Tomcat 6.x DB Schnittstelle JDBC (Postgres 8.1 JDBC Treiber) innerhalb
des Geronimo Connectionpools.
Appserver Loadbalancing der Webapplikationen l=C3=A4uft =C3=BCber das in =
Geronimo
bereits integrierte
WADI (Web Application Distributed Infrastructure) von Codehaus.

Performanceschw=C3=A4chster Teil der Gesammtapplikation ist die DB, da di=
e
Formulare immer
erst dann ausgeliefert werden k=C3=B6nnen wenn die DB die Daten angeliefe=
rt
oder verarbeitet hat.




--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

--On Samstag, Mai 17, 2008 13:20:26 +0200 rudi [at] je-more.de wrote:

> Slony ist gefährlich, weil man mit dem Master doch wieder einen Single
> point of Failure hat.

Slony-I war nie als integrierte Hochverfügbarkeitslösung gedacht.

Slony-I kann als Bestandteil einer HA-Lösung dienen, allerdings benötig=
t
man einen =DCberwachungsdienst ala Heartbeat (siehe FAILOVER-Kommando). Abe=
r
es besteht bei Slony-I die Gefahr bereits erfolgreiche Transaktionen zu
verlieren (aufgrund der asynchronen Technik), weshalb man eher dazu
übergeht den Master anderweitig abzusichern. Kommt halt auch ein bisschen=

auf die Logik der Daten an, die da reinwandern. Wie gesagt, Slony-I ist ein=

Bauteil, aber keine hochintegrierte Lösung.

--
Thanks

Bernd

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

On Sat, 17 May 2008 13:20:26 +0200 rudi [at] je-more.de wrote:

> Andreas 'ads' Scherbaum schrieb:
> > Statement-basierte L=C3=B6sungen sind nett ... allerdings muss man eini=
ge
> > Sachen beachten. Z.B. wie man mit Timestamps ect. umgeht. Das steht
> > aber imho auch in der FAQ so mit drin.
> >
> Du meinst wenn man eine zu "generalisierte" L=C3=B6sung einsetzt, die dan=
n
> m=C3=B6glicherweise nicht mehr
> in der Lage ist z.B Postgres Timestamps zu behandeln?

Nein, das Problem entsteht eher, wenn man Funktionen einsetzt, die auf
jeder der Datenbanken hinter dem Pool ein anderes Ergebnis liefern,
weil die Ergebnisse volatil sind. Auf so etwas muss die Anwendung
vorbereitet sein.



> > Slony dagegen ist eine Master-Slave L=C3=B6sung, aber auch hier wird die
> > Verwendbarkeit stark von deinen Anforderungen und deiner Applikation
> > abh=C3=A4ngen.
> >
> Slony ist gef=C3=A4hrlich, weil man mit dem Master doch wieder einen Sing=
le
> point of Failure hat.

Slony ist nicht "gef=C3=A4hrlich", Slony ist ein Konzept. Aber dazu hat
Bernd schon mehr geschrieben.



> Ok, dann hoffe ich das es sowas wie ein kleiner Anforderungsplan ist
> (der Priorit=C3=A4t nach).

Das ist ein Anforderungsplan f=C3=BCr dich, aber nicht f=C3=BCr deine Appli=
kation.
Das ist ein Unterschied.



> 1.
> Geschwindigkeit auch unter Last bei vielen konkurierenden Insert/Select=

> Queries, desto schneller
> desto besser (die User am Webfrontend sollen zu jeder Zeit in,
> Bruchteilen von sek. ihre dynamischen
> HTML Operationen durchf=C3=BChren k=C3=B6nnen (also sprich wie CGI/Perl/P=
HP das
> auch machen).

Die L=C3=B6sung hierf=C3=BCr ergibt sich, wenn man sich Gedanken =C3=BCber =
die
Anforderungen f=C3=BCr deine Applikation macht - und etwas Know How dazu ins
Spiel bringt.



> 2.
> Das Projekt ist eine Communityseite,wo st=C3=A4ndig Nachrichten mittels=

> Inserts in Tabellenspalten eingef=C3=BCgt
> werden (mid int =3D MessageNr) sender id (Verschicker) (recipid int =3D=

> Empfaenger), subject (TEXT) hier
> kann quasi eine Bildschirmseite Text drin stehe (und dieses Feld macht
> mir am meisten Kopfzerbrechen).

Konzept anpassen, Konzept ver=C3=A4ndern, Datenbankstruktur =C3=BCberpr=C3=
=BCfen ect.
Da gibt es viele M=C3=B6glichkeiten.

Ich wette mal dass von deinen vielen Millionen oder Milliarden
Nachrichten nur ein sehr geringer Teil st=C3=A4ndig abgerufen wird. Daf=C3=
=BCr
gibt es geeignete Technologien, so etwas verf=C3=BCgbar zu machen.



> 3.
> Keine Downtimes durch Backup, Patch Update/Upgrade

Ich darf mal kurz und heftig lachen, oder?
Sind wir wieder bei "keine Downtime, weil Patches gibt es nur alle 3
Monate"?

F=C3=BCr eine Community-Webseite verlangst du ziemlich viel, deine
Anforderungen gehen in Richtung Hochverf=C3=BCgbarkeit. Dazu geh=C3=B6rt ab=
er
auch die Absicherung gegen Strom- und Netzausf=C3=A4lle, gegen
Hardwareprobleme und noch eine Reihe weiterer Ma=C3=9Fnahmen und
Fehlerf=C3=A4llen. Wirf etwas mehr Geld auf dein Problem, um deine
Anforderungen zu erf=C3=BCllen - speziell im Bereich Hardware und Hosting.

Deine Anforderungen lassen sich erf=C3=BCllen, aber ich bezweifle, dass du
als Neueinsteiger in PostgreSQL da sehr weit kommen wirst. Daf=C3=BCr
ben=C3=B6tigst du schon tiefgreifendes Wissen und einen Support, der schnell
reagieren kann.



> 4.
> Keine Unterbrechnung des DB-Betriebs durch Hardwareprobleme

Was heisst bei dir "keine". 100%? Unrealistisch. Wieviele neuner
m=C3=B6chtest du hinter dem Dezimalpunkt stehen haben?



> 5.
> Skalierbare Performance des Gesammtsystems durch hinzuf=C3=BCgen und
> entfernen von
> neuen DB Servern.

Entspricht deinem Konzept.



> Appserver:
> Applicationserver ist Apache Geronimo 2.1.1, 64-Bit AMD64 JRE 1.6.0_06,=

> Webserverlayer
> Tomcat 6.x DB Schnittstelle JDBC (Postgres 8.1 JDBC Treiber) innerhalb
> des Geronimo Connectionpools.
> Appserver Loadbalancing der Webapplikationen l=C3=A4uft =C3=BCber das in =
Geronimo
> bereits integrierte
> WADI (Web Application Distributed Infrastructure) von Codehaus.

Warum ist da immer noch PG 8.1 im Spiel? Oder welche Version l=C3=A4uft da
bei dir?


> Performanceschw=C3=A4chster Teil der Gesammtapplikation ist die DB, da di=
e
> Formulare immer
> erst dann ausgeliefert werden k=C3=B6nnen wenn die DB die Daten angeliefe=
rt
> oder verarbeitet hat.

Logisch.


Aber so langsam frage ich mich, was wir hier diskutieren. Niemand wird
dir einen Plan aufstellen, was du f=C3=BCr deine Anwendung ben=C3=B6tigst, =
weil
du auch immer nur auf Nachfrage mit Details herausr=C3=BCckst. Wie deine
Anwendung aufgebaut ist, weiss immer noch keiner. Wie deine
Anforderungen im Detail (nicht nur in 5 Stichpunkte gefasst) aussehen,
weiss auch niemand. Bei dem, was du hier schreibst, fallen
normalerweise ein paar Dutzend Seiten Anforderungen hinten aus dem
Prozess heraus - und das alles, bevor auch nur ein Server installiert
wurde.

Wenn die Anforderungen unabh=C3=A4ngig von der zu verwendenden Software
definiert sind, entscheidet man, wie man zum gew=C3=BCnschten Ziel kommt -
und welche Datenbank die Anforderungen erf=C3=BCllt. Alles andere ist
Herumprobieren ohne definiertes Ziel.


Aus dem Grund verabschiede ich mich aus dieser Diskussion. Wenn du ein
konkretes Konzept hast und wenn ihr wisst, wie wichtig euch die gesamte
Applikation ist ("keine Ausfallzeit" heisst im Umkehrschluss: der
Betrieb der Datenbank ist lebenswichtig), lass uns das doch mal wissen.


Bis dann

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Andreas 'ads' Scherbaum schrieb:
> 1.
>> Geschwindigkeit auch unter Last bei vielen konkurierenden Insert/Selec=
t
>> Queries, desto schneller
>> desto besser (die User am Webfrontend sollen zu jeder Zeit in,
>> Bruchteilen von sek. ihre dynamischen
>> HTML Operationen durchf=C3=BChren k=C3=B6nnen (also sprich wie CGI/Per=
l/PHP das
>> auch machen).
>>
>
> Die L=C3=B6sung hierf=C3=BCr ergibt sich, wenn man sich Gedanken =C3=BC=
ber die
> Anforderungen f=C3=BCr deine Applikation macht - und etwas Know How daz=
u ins
> Spiel bringt.
>
Sorry, aber das ist etwas zu generell gesprochen.
Ich wei=C3=9F nicht wie alt Du bist und wie viel KnowHow Du in deinem Leb=
en
schon sammeln kontest,
aber ich bin 33 Jahre alt und seit 15 Jahren in der Softwareentwicklung
mit Datenbanken der
verschiedensten Herrsteller. =C3=9Cber Banalit=C3=A4ten wie "Know How ins=
Spiel
bringen" und "benutz mal
Google" =C3=A4hnliches brauchen wir uns wirklich nicht zu unterhalten.

Ich gehe davon aus, das Du Dich mit Postgres besch=C3=A4ftigt hast und
vielleicht bist Du in einem Projekt
mal damit befasst gewesen wie man Tabellenspalten des Typ Postgres/Text
mit durchschnittlich
einer Bildschirmseite Usertext 1 bis 1000 Zeichen am besten organisiert.
Wenn nicht, dann hast
Du zumindest eine "kleine".

>> 2.
>> Das Projekt ist eine Communityseite,wo st=C3=A4ndig Nachrichten mittel=
s
>> Inserts in Tabellenspalten eingef=C3=BCgt
>> werden (mid int =3D MessageNr) sender id (Verschicker) (recipid int =3D=

>> Empfaenger), subject (TEXT) hier
>> kann quasi eine Bildschirmseite Text drin stehe (und dieses Feld macht=

>> mir am meisten Kopfzerbrechen).
>>
>
> Konzept anpassen, Konzept ver=C3=A4ndern, Datenbankstruktur =C3=BCberpr=
=C3=BCfen ect.
> Da gibt es viele M=C3=B6glichkeiten.
>
Ich wei=C3=9F nicht ob Du Dich manchmal in die Rolle dessen hinneinverset=
zt
der deine Texte am Ende
lie=C3=9Ft, aber genau solche Aussagen sind, um es diplomatisch auszudr=C3=
=BCcken
- eher gew=C3=B6hnungsbed=C3=BCrftig
(nicht technisch, aber zwiswchenmenschlich).

> Ich wette mal dass von deinen vielen Millionen oder Milliarden
> Nachrichten nur ein sehr geringer Teil st=C3=A4ndig abgerufen wird. Daf=
=C3=BCr
> gibt es geeignete Technologien, so etwas verf=C3=BCgbar zu machen.
>
Ok, ich habe nun verstanden das es Dir offensichtlich auf
Dampfplauderrei ankommt
oder wie ist es sonst m=C3=B6glich das Du st=C3=A4ndig mit so vielen wort=
nichts
zum Ausdruck bringst?

>> 3.
>> Keine Downtimes durch Backup, Patch Update/Upgrade
>>
>
> Ich darf mal kurz und heftig lachen, oder?
> Sind wir wieder bei "keine Downtime, weil Patches gibt es nur alle 3
> Monate"?
>
Nein, aber hier gebe ich zu das es erkl=C3=A4rt werden muss.
Ich beabsichtige Sequoia (OpenSource)
http://sequoia.continuent.org/HomePage als Bindeglied zwischen
PostgreSQL DB-Server 8.3 und WebApplicationserver einzusetzen. Sequoia
ist eine DB-Clustering
Middleware, die sich =C3=A4hnlich wie eine Materialzed View (gibts noch n=
icht
in PostgreSQL 8.3) verh=C3=A4lt,
dahinter jedoch beliebig viele DB-Server vereint.

Das heisst, deine WebAnwendung verschickt =C3=BCber das Sequoia
Verbindungsobjekt ganz normal
wie immer seine Selects/Updates/Inserts aber in Wirklichkeit ist nicht
nicht klar auf welchen von
Sequoia verwalteten DB-Servern diese Query auch wirklich ausgef=C3=BChrt
wird. Dabei h=C3=A4lt Sequoia
alle in der Config angegebenen DB-Server auf dem gleichen Spiegellevel
und macht es daher
m=C3=B6glich einzelne DB's aus dem Grid herunterzufahren (Patchen, Upgra=
de,
ReConfig u.s.w)
und sp=C3=A4ter wieder neu zu starten und zur=C3=BCck ins Grid zu kehren.=
Sequoia
bringt dann die Datendifferenz
des sich wieder online befindlichen DB-Servers auf den neuesten Stand
und bzieht ihn danach
wieder in die SQL Abfrageoperation der WebApplikation ein. So ist es
m=C3=B6glich eine Allways On DB zu
betreiben. Der einzige Singlepoint of Failure kann sich ergeben, wenn
der zentrale Sequoia Connector
versagt, allerdings ist das auch kein Problem da Sequoia anbietet
mehrere Connectoren parallel zu
betreiben. Sollte der erste Server mit dem Sequoia Connector nicht
erreichbar sein, wird einfach auf
den n=C3=A4chsten in einer Liste von Connectoren die Du vorher selber
definieren kannst =C3=BCbergegangen.

Sequoia wird in der PostgreSQL Dokumentation zum Thema Hochverf=C3=BCgbar=
keit
ausdr=C3=BCcklich erw=C3=A4hnt
und auch empfohlen.

> F=C3=BCr eine Community-Webseite verlangst du ziemlich viel, deine
> Anforderungen gehen in Richtung Hochverf=C3=BCgbarkeit. Dazu geh=C3=B6r=
t aber
> auch die Absicherung gegen Strom- und Netzausf=C3=A4lle, gegen
> Hardwareprobleme und noch eine Reihe weiterer Ma=C3=9Fnahmen und
> Fehlerf=C3=A4llen. Wirf etwas mehr Geld auf dein Problem, um deine
> Anforderungen zu erf=C3=BCllen - speziell im Bereich Hardware und Hosti=
ng.
>
Hochverf=C3=BCgbarkeit ist korrekt. Mein Provider verf=C3=BCgt =C3=BCber =
die technische
Infrastructure derartige
technische Rahmenbedinungen zu garantieren (das sind alles einzelne
Rootserver in einem
Hochverf=C3=BCgbarkeitsrechenzentrum mit Diesel-Notstrohmagregaten u.s.w =
-
das bieten jedoch heute
schon viele).

> Deine Anforderungen lassen sich erf=C3=BCllen, aber ich bezweifle, dass=
du
> als Neueinsteiger in PostgreSQL da sehr weit kommen wirst. Daf=C3=BCr
> ben=C3=B6tigst du schon tiefgreifendes Wissen und einen Support, der sc=
hnell
> reagieren kann.
>
Ok, um das mal klar zu stellen!
Ich bin also ein Neuling weil ich die Frage stelle wie man eine derzeit
700 GByte grosse Tabelle besser
normalisieren der skaliarbar restrukturieren kann? Denk mal bitte etwas
ausf=C3=BChrlicher dar=C3=BCber nach bevor
Du antwortest, denn bisher hatte ich den Eindruck das Du, auch wenn Du
Dich manchmal komisch =C3=A4u=C3=9Ferst
ein kompetenter Entwickler bist mit dem man sich austauschen kann.

>> Appserver:
>> Applicationserver ist Apache Geronimo 2.1.1, 64-Bit AMD64 JRE 1.6.0_0=
6,
>> Webserverlayer
>> Tomcat 6.x DB Schnittstelle JDBC (Postgres 8.1 JDBC Treiber) innerhalb=

>> des Geronimo Connectionpools.
>> Appserver Loadbalancing der Webapplikationen l=C3=A4uft =C3=BCber das =
in Geronimo
>> bereits integrierte
>> WADI (Web Application Distributed Infrastructure) von Codehaus.
>>
>
> Warum ist da immer noch PG 8.1 im Spiel? Oder welche Version l=C3=A4uft=
da
> bei dir?
>
Also 8.1 l=C3=A4uft derzeit auf dem Produktionsserver aber zur Entwicklun=
g
arbeite ich mit 8.3.
Leider gibt es f=C3=BCr Debian Etch noch kein Stablepaket f=C3=BCr 8.3 un=
d ich
wollte deshalb noch
etwas abwarten.

>> Performanceschw=C3=A4chster Teil der Gesammtapplikation ist die DB, da=
die
>> Formulare immer
>> erst dann ausgeliefert werden k=C3=B6nnen wenn die DB die Daten angeli=
efert
>> oder verarbeitet hat.
>>
>
> Logisch.
>
>
> Aber so langsam frage ich mich, was wir hier diskutieren. Niemand wird
> dir einen Plan aufstellen, was du f=C3=BCr deine Anwendung ben=C3=B6tig=
st, weil
> du auch immer nur auf Nachfrage mit Details herausr=C3=BCckst. Wie dein=
e
> Anwendung aufgebaut ist, weiss immer noch keiner.
Hatte ich eigentlich schon mehrfach beschrieben.
Im Detail geht es mir um das Textfeld in einer Tabellenspalten in dem
ganze Bildschirmseiten Text verfasst
hinterlegt liegen. Wie kann ich eine Tabellenstrukturaufbauen die dieses
Feld entlastet oder die Daten
anders so ablegen, das die Daten in dem Feld besser verteilt werden (da
bin ich ganz frei, mehrere
Spalten, ClusterDB-Text Feld oder was es sonst so gibt).

Das Textfeld muss dar=C3=BCber hinnaus noch Steuerzeichen zur
Bildformatierung, die nicht HTML sind
beinhalten die vom Webfrontend beim dynamischen HTML generieren
umgesetzt werden.

Ich glaube um ein Postgres Textfeld zu besprechen braucht es nicht die
komplette Beschreibung.
Hier mal das DDL Statement der Tabelle:

// Tabelle enth=C3=A4lt ca. 700 GByte Daten
CREATE TABLE webapp.messages
(
mid integer NOT NULL,
sender integer NOT NULL,
recipient integer NOT NULL,
subject character varying(20) NOT NULL,
message text, <<<<--------------------Problemfeld
createdate date,
CONSTRAINT pk_mid PRIMARY KEY (mid)
)
WITHOUT OIDS
TABLESPACE sys_messages;
ALTER TABLE webapp.messages OWNER TO sysdba;


Ist das nun konkret genug? :-)

Gru=C3=9F, Rudi


--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

*hrmpf*

On Sun, 18 May 2008 12:13:35 +0200 rudi [at] je-more.de wrote:

> Andreas 'ads' Scherbaum schrieb:

> Sorry, aber das ist etwas zu generell gesprochen.

Nat=C3=BCrlich. Deine "Anforderungen" waren nicht mehr als 6 generelle
Punkte. Was erwartest du?



> Ich wei=C3=9F nicht wie alt Du bist und wie viel KnowHow Du in deinem Leb=
en
> schon sammeln kontest,
> aber ich bin 33 Jahre alt und seit 15 Jahren in der Softwareentwicklung=

> mit Datenbanken der
> verschiedensten Herrsteller.

Dann bin ich ein Jahr j=C3=BCnger und etwas l=C3=A4nger damit besch=C3=A4ft=
igt. Was
wird das jetzt, ein *Vergleich?



> =C3=9Cber Banalit=C3=A4ten wie "Know How ins Spiel bringen" und "benutz m=
al
> Google" =C3=A4hnliches brauchen wir uns wirklich nicht zu unterhalten.

Ich habe nichts von "Google" gesagt. Eine Suchmaschine soll sich jeder
selbst aussuchen und bedienen k=C3=B6nnen.

Was ich jedoch sage (und meine): du startest hier ein Projekt, mit
welchem du 100% Verf=C3=BCgbarkeit erreichen m=C3=B6chtest und gibst gleich=
zeitig
zu, dich mit PostgreSQL noch nicht viel besch=C3=A4ftigt zu haben.
Was soll ich dir sonst empfehlen ausser: du brauchst daf=C3=BCr mehr
Erfahrung. Wenn du dich davon pers=C3=B6nlich angegriffen f=C3=BChlst, ist =
das
nicht mein Problem.



> Ich gehe davon aus, das Du Dich mit Postgres besch=C3=A4ftigt hast und
> vielleicht bist Du in einem Projekt
> mal damit befasst gewesen wie man Tabellenspalten des Typ Postgres/Text=

> mit durchschnittlich
> einer Bildschirmseite Usertext 1 bis 1000 Zeichen am besten organisiert.=

> Wenn nicht, dann hast
> Du zumindest eine "kleine".

Eine "kleine" was?
Ich habe mehrere Projekte umgesetzt, bei denen bin=C3=A4re Daten und/oder
l=C3=A4ngere Texte in Datenbanken gehalten werden. Das war nicht nur
PostgreSQL, da kamen mehrere Datenbanken dabei vor.

Ich m=C3=B6chte also schon sagen, dass ich nicht nur das wiedergebe, was
andere zu dem Thema sagen sondern auch meine ganz eigenen Erfahrungen
gesammelt habe. In keinem Fall hat es etwas gebracht, nur die Datenbank
zu entwickeln. Dazu geh=C3=B6rt jedesmal auch eine Betrachtung der
I/O-Leistung der Server und eine Betrachtung der sonstigen eingesetzten
Software (Caches, Webserver, Programmiersprache ect.)



> > Konzept anpassen, Konzept ver=C3=A4ndern, Datenbankstruktur =C3=BCberpr=
=C3=BCfen ect.
> > Da gibt es viele M=C3=B6glichkeiten.
> >
> Ich wei=C3=9F nicht ob Du Dich manchmal in die Rolle dessen hinneinverset=
zt
> der deine Texte am Ende
> lie=C3=9Ft, aber genau solche Aussagen sind, um es diplomatisch auszudr=
=C3=BCcken
> - eher gew=C3=B6hnungsbed=C3=BCrftig
> (nicht technisch, aber zwiswchenmenschlich).

LOL
Ich habe dich nach konkreten(!) technischen Anforderungen gefragt und du
lieferst einen 6-Punkte Plan ab. Damit kann niemand etwas anfangen.

Deine aktuelle Datenbank platzt anscheinend aus den N=C3=A4hten, sonst
w=C3=BCrdet ihr das nicht auf eine neue Datenbank portieren wollen. Das ist
ein geeigneter Zeitpunkt, auch mal auf die aktuellen Probleme zu
schauen und zu =C3=BCberpr=C3=BCfen, welche Konzept=C3=A4nderungen man einb=
ringen kann.

Da du allerdings nichts konkretes sagst - was erwartest du zu h=C3=B6ren?
Irgendwelche konkreten L=C3=B6sungen?



> > Ich wette mal dass von deinen vielen Millionen oder Milliarden
> > Nachrichten nur ein sehr geringer Teil st=C3=A4ndig abgerufen wird. Daf=
=C3=BCr
> > gibt es geeignete Technologien, so etwas verf=C3=BCgbar zu machen.
> >
> Ok, ich habe nun verstanden das es Dir offensichtlich auf
> Dampfplauderrei ankommt
> oder wie ist es sonst m=C3=B6glich das Du st=C3=A4ndig mit so vielen wort=
nichts
> zum Ausdruck bringst?

Du hast gar nichts verstanden.
Du hast ein Nachrichtensystem. Wieviele Nachrichten davon werden
st=C3=A4ndig ben=C3=B6tigt und wieviele bloss vorgehalten, um sie ev. mal
abzurufen? In der Regel ruft man die letzten Nachrichten ab.
Diese Nachrichten kann man anderweitig (memcache, andere Tabelle ect)
vorhalten und von dort abrufen. Das entlastet deine eigentliche
Datenbank und das sorgt allgemein f=C3=BCr schnellere Antwortzeiten.

Du kannst das nat=C3=BCrlich als "Dampfplauderrei" (Dampfplauderei) abtun .=
...
sorgst aber nur daf=C3=BCr, dass ich mich nicht weiter mit dir unterhalten
will.



> Hochverf=C3=BCgbarkeit ist korrekt. Mein Provider verf=C3=BCgt =C3=BCber =
die technische
> Infrastructure derartige
> technische Rahmenbedinungen zu garantieren (das sind alles einzelne
> Rootserver in einem
> Hochverf=C3=BCgbarkeitsrechenzentrum mit Diesel-Notstrohmagregaten u.s.w =
-
> das bieten jedoch heute
> schon viele).

Das gen=C3=BCgt (noch) nicht, aber lassen wir das aussen vor.



> Ich bin also ein Neuling weil ich die Frage stelle wie man eine derzeit=

> 700 GByte grosse Tabelle besser
> normalisieren der skaliarbar restrukturieren kann?

Du hast selbst gesagt, dass du dich bei Oracle gut auskennst, aber
nicht bei PostgreSQL. Du fragst selbst, wie man das ganze besser
strukturieren kann, aber in dem Moment, in dem ich ein Nachdenken =C3=BCber
das aktuelle (laufende) Konzept vorschlage und einige Ans=C3=A4tze liefere,
wirfst du mir "Dampfplauderrei" vor. Geh doch und l=C3=B6se deine Probleme
allein.



> Denk mal bitte etwas ausf=C3=BChrlicher dar=C3=BCber nach bevor
> Du antwortest, denn bisher hatte ich den Eindruck das Du, auch wenn Du
> Dich manchmal komisch =C3=A4u=C3=9Ferst
> ein kompetenter Entwickler bist mit dem man sich austauschen kann.

[X] Geh weg.

Du schaffst es, mit allen hier anzuecken.



> > Warum ist da immer noch PG 8.1 im Spiel? Oder welche Version l=C3=A4uft=
da
> > bei dir?
> >
> Also 8.1 l=C3=A4uft derzeit auf dem Produktionsserver aber zur Entwicklun=
g
> arbeite ich mit 8.3.
> Leider gibt es f=C3=BCr Debian Etch noch kein Stablepaket f=C3=BCr 8.3 un=
d ich
> wollte deshalb noch
> etwas abwarten.

Dann ist Debian Etch die falsche Plattform. Daf=C3=BCr wird es nie eine
offizielle 8.3 geben. Nach dem Feature Freeze wird die Software
Plattform nicht mehr ge=C3=A4ndert, es wird nur noch Bugfixes geben.
Die n=C3=A4chste Debian Version kommt dann in 1-3 Jahren heraus.

Jedoch gibt es von Debian-Maintainern bereitgestellte 8.3 Pakete.



> Das Textfeld muss dar=C3=BCber hinnaus noch Steuerzeichen zur
> Bildformatierung, die nicht HTML sind
> beinhalten die vom Webfrontend beim dynamischen HTML generieren
> umgesetzt werden.

Anderswo parst man das HTML einmal und legt das geparste HTML dann
ebenfalls in der Datenbank oder in einem Filesystemcache ab. Spart
Performance.



> Ist das nun konkret genug? :-)

Nein. Was bringt eine Tabelle, wenn das Gesamtkonzept nicht steht?
Wie du die Tabelle besser strukturieren oder aufteilen k=C3=B6nntest, habe
ich einige Mails vorher schon mal geschrieben und wiederhole das hier
nicht.


So, ich gehe mal Sonne genie=C3=9Fen

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein