Re: WebApplication und Betriebssystem Performance Fragen.

Andreas 'ads' Scherbaum schrieb:
> 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ühren können (also sprich wie CGI/Perl/PHP das
>> auch machen).
>>
>
> Die Lösung hierfür ergibt sich, wenn man sich Gedanken über die
> Anforderungen für deine Applikation macht - und etwas Know How dazu ins
> Spiel bringt.
>
Sorry, aber das ist etwas zu generell gesprochen.
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. Über Banalitäten wie "Know How ins Spiel
bringen" und "benutz mal
Google" ähnliches brauchen wir uns wirklich nicht zu unterhalten.

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".

>> 2.
>> Das Projekt ist eine Communityseite,wo ständig Nachrichten mittels
>> Inserts in Tabellenspalten eingefügt
>> werden (mid int = MessageNr) sender id (Verschicker) (recipid int =
>> Empfaenger), subject (TEXT) hier
>> kann quasi eine Bildschirmseite Text drin stehe (und dieses Feld macht
>> mir am meisten Kopfzerbrechen).
>>
>
> 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).

> 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?

>> 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ärt 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 ähnlich wie eine Materialzed View (gibts noch nicht
in PostgreSQL 8.3) verhält,
dahinter jedoch beliebig viele DB-Server vereint.

Das heisst, deine WebAnwendung verschickt über 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ührt
wird. Dabei hält Sequoia
alle in der Config angegebenen DB-Server auf dem gleichen Spiegellevel
und macht es daher
möglich einzelne DB's aus dem Grid herunterzufahren (Patchen, Upgrade,
ReConfig u.s.w)
und später wieder neu zu starten und zurück 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öglich 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ächsten in einer Liste von Connectoren die Du vorher selber
definieren kannst übergegangen.

Sequoia wird in der PostgreSQL Dokumentation zum Thema Hochverfügbarkeit
ausdrücklich erwähnt
und auch empfohlen.

> Für eine Community-Webseite verlangst du ziemlich viel, deine
> Anforderungen gehen in Richtung Hochverfügbarkeit. Dazu gehört aber
> auch die Absicherung gegen Strom- und Netzausfälle, gegen
> Hardwareprobleme und noch eine Reihe weiterer Maßnahmen und
> Fehlerfällen. Wirf etwas mehr Geld auf dein Problem, um deine
> Anforderungen zu erfüllen - speziell im Bereich Hardware und Hosting.
>
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).

> Deine Anforderungen lassen sich erfüllen, aber ich bezweifle, dass du
> als Neueinsteiger in PostgreSQL da sehr weit kommen wirst. Dafür
> benötigst du schon tiefgreifendes Wissen und einen Support, der schnell
> 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ü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.

>> 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äuft über 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ä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.

>> Performanceschwächster Teil der Gesammtapplikation ist die DB, da die
>> Formulare immer
>> erst dann ausgeliefert werden können wenn die DB die Daten angeliefert
>> oder verarbeitet hat.
>>
>
> Logisch.
>
>
> Aber so langsam frage ich mich, was wir hier diskutieren. Niemand wird
> dir einen Plan aufstellen, was du für deine Anwendung benötigst, weil
> du auch immer nur auf Nachfrage mit Details herausrückst. Wie deine
> 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über 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ält 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ß, Rudi