Sunday, May 18, 2008

Re: [pgsql-de-allgemein] WebApplication und Betriebssystem Performance Fragen.

*hrmpf*

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

> Andreas 'ads' Scherbaum schrieb:

> Sorry, aber das ist etwas zu generell gesprochen.

Natürlich. Deine "Anforderungen" waren nicht mehr als 6 generelle
Punkte. Was erwartest du?

> Ich weiß nicht wie alt Du bist und wie viel KnowHow Du in deinem Leben
> 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ünger und etwas länger damit beschäftigt. Was
wird das jetzt, ein *Vergleich?

> Über Banalitäten wie "Know How ins Spiel bringen" und "benutz mal
> Google" ähnliches brauchen wir uns wirklich nicht zu unterhalten.

Ich habe nichts von "Google" gesagt. Eine Suchmaschine soll sich jeder
selbst aussuchen und bedienen können.

Was ich jedoch sage (und meine): du startest hier ein Projekt, mit
welchem du 100% Verfügbarkeit erreichen möchtest und gibst gleichzeitig
zu, dich mit PostgreSQL noch nicht viel beschäftigt zu haben.
Was soll ich dir sonst empfehlen ausser: du brauchst dafür mehr
Erfahrung. Wenn du dich davon persönlich angegriffen fühlst, ist das
nicht mein Problem.

> Ich gehe davon aus, das Du Dich mit Postgres beschäftigt 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äre Daten und/oder
längere Texte in Datenbanken gehalten werden. Das war nicht nur
PostgreSQL, da kamen mehrere Datenbanken dabei vor.

Ich möchte 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ört 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ändern, Datenbankstruktur überprüfen ect.
> > Da gibt es viele Möglichkeiten.
> >
> Ich weiß nicht ob Du Dich manchmal in die Rolle dessen hinneinversetzt
> der deine Texte am Ende
> ließt, aber genau solche Aussagen sind, um es diplomatisch auszudrücken
> - eher gewöhnungsbedürftig
> (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ähten, sonst
würdet ihr das nicht auf eine neue Datenbank portieren wollen. Das ist
ein geeigneter Zeitpunkt, auch mal auf die aktuellen Probleme zu
schauen und zu überprüfen, welche Konzeptänderungen man einbringen kann.

Da du allerdings nichts konkretes sagst - was erwartest du zu hören?
Irgendwelche konkreten Lösungen?

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

Du hast gar nichts verstanden.
Du hast ein Nachrichtensystem. Wieviele Nachrichten davon werden
ständig benötigt 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ür schnellere Antwortzeiten.

Du kannst das natürlich als "Dampfplauderrei" (Dampfplauderei) abtun ...
sorgst aber nur dafür, dass ich mich nicht weiter mit dir unterhalten
will.

> Hochverfügbarkeit ist korrekt. Mein Provider verfügt über die technische
> Infrastructure derartige
> technische Rahmenbedinungen zu garantieren (das sind alles einzelne
> Rootserver in einem
> Hochverfügbarkeitsrechenzentrum mit Diesel-Notstrohmagregaten u.s.w -
> das bieten jedoch heute
> schon viele).

Das genügt (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 über
das aktuelle (laufende) Konzept vorschlage und einige Ansätze liefere,
wirfst du mir "Dampfplauderrei" vor. Geh doch und löse deine Probleme
allein.

> Denk mal bitte etwas ausführlicher darüber nach bevor
> Du antwortest, denn bisher hatte ich den Eindruck das Du, auch wenn Du
> Dich manchmal komisch äußerst
> 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äuft da
> > bei dir?
> >
> Also 8.1 läuft derzeit auf dem Produktionsserver aber zur Entwicklung
> arbeite ich mit 8.3.
> Leider gibt es für Debian Etch noch kein Stablepaket für 8.3 und ich
> wollte deshalb noch
> etwas abwarten.

Dann ist Debian Etch die falsche Plattform. Dafür wird es nie eine
offizielle 8.3 geben. Nach dem Feature Freeze wird die Software
Plattform nicht mehr geändert, es wird nur noch Bugfixes geben.
Die nächste Debian Version kommt dann in 1-3 Jahren heraus.

Jedoch gibt es von Debian-Maintainern bereitgestellte 8.3 Pakete.

> Das Textfeld muss darüber 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önntest, habe
ich einige Mails vorher schon mal geschrieben und wiederhole das hier
nicht.


So, ich gehe mal Sonne genießen

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

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

No comments: