* Markus Zakel wrote on Wed, Nov 22, 2000 at 09:34 +0100:
[...]
> Wenn der Besitzer des Nesletters dann an alle 100'000 empfänger
> personaliesierte Mails schickt dann wird die DB last wenn nur einer einen
> Verschickt nicht groß sein!
> jetzt verschicken aber 10'000 Besitzer insegesamt 10'000'000 Mais zur
> gleichen zeit dazu kommen noch zich votes, usw...
> Ihr seht dass ist sehr DB lastig.

Nee, da wird garantiert der Mailserver das langsamere Glied sein,
der muß dann 10M * 2KB oder mehr durch ne Internetleitung
bekommen (34Mbit? 155Mbit?). 

> > Was sind wirklich relevante Fragen ? Skalierbarkeit, Administration,
> > vorhandene Schnittstellen,
> Also:
> 1. Welche der 3 DB's ist gegenüber abstürzen am unempfindlichsten? 

Soweit mir bekannt, reagieren Datenbanken auf Abstürze meistens
sehr empfindlich.

> (d.h.
> dass ich nach dem absturtz alle daten wieder verfügbar habe! 

ollte ja wohl bei jeder Datenbank so sein (mySQL und
ramdisk-gepufferte Textfiles mal ausgenommen)

> Bei oracle
> giebt es ja so eine recover Funktion die alles (meinstens) wieder herstellt)

Wenn Du nur Oracle kennst, solltest Du Oracle verwenden. 

Wenn Du ernsthaft mit 10 Millionen eMails rechnest, solltest Du
Deine Fragen wirklich nicht hier stellen, sondern ein gutes
Consulting aufsuchen, das Erfahrungen in großen Projekten etc.
hat.

oki,

Steffen


-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.

---------------------------------------------------------------------
To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com
For additional commands, e-mail: suse-linux-help@suse.com

* Bernd Brodesser wrote on Thu, Nov 23, 2000 at 22:01 +0100:

* Steffen Dettmer schrieb am 23.Nov.2000:

...

* Markus Zakel wrote on Wed, Nov 22, 2000 at 09:34 +0100:

...

Also: 1. Welche der 3 DB's ist gegenüber abstürzen am unempfindlichsten?

...

Soweit mir bekannt, reagieren Datenbanken auf Abstürze meistens sehr empfindlich.

Was verstehst Du unter empfindlich reagieren? Einer Datenbank darf einen Absturz nichts ausmachen, sonst ist sie nichts wert.

Aber sie fallen eine Weile aus... Meistens bis nach dem nächsten Reboot :) Ist doch klar, daß ein Datenbanksystem keine Daten beim Crash verliert, dann wäre ja die Grundforderung nach Datenintegrität verletzt! Bei Oracle und DB2 gehe ich einfach davon aus, daß das funktioniert, und bei Sybase, Informix und PostgreSQL auch. Klar, mySQL kommt damit bestimmt nicht klar (eben keine richtige Datenbank, auch wenn mySQL langsam groß wird. Aber gibt ja schon PostgreSQL :)).

...

...

(d.h. dass ich nach dem absturtz alle daten wieder verfügbar habe!

Alle Daten die auf Platte sind. Das ist klar. Wichtig ist, daß siche die Datenbank auch nach einem Absturz in einem konsistenten Zustand befindet. Daten die gerade eingegeben wurden können verloren sein, nur muß die Datenbank das wissen, ob der Datensatz gilt oder nicht.

Klar. Deswegen bekommen Datenbanken ja raw Partitions, damit das System da nix cacht etc. Das ist natürlich Aufwand. Deshalb ist ne Datenbank auch langsamer als ne Textdatei :) Trozdem sollte man wichtige DBMS auf Batteriegepufferten RAID5 betreiben und ne USV an den Server stellen. Spart im Zweifelsfall zumindestens Ärger :)

...

sollte ja wohl bei jeder Datenbank so sein (mySQL und ramdisk-gepufferte Textfiles mal ausgenommen)

Das ist das Problem. Was ist wirklich auf Platte. Das muß eine Datenbank wissen.

Genau. Deshalb soll man ja auch keine Files verwenden usw. Für kleine DBs zum rumspielen ja ok, aber sonst eben genau deswegen schlecht. Aber inzwischen hat doch Linux Raw-Device Support. (Was ist daran eingentlich so schwierig?). Außerdem kennt eine Datenbank ihre eigene Struktur besser, und weiß, welche Stellen häufig benötigt werden, und gecacht werden müssen. Die werden dann vom OS nicht nochmal gecacht. Damit mehr Speicher :) Und Speicher mögen Datenbanken am liebsten :) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Steffen Dettmer wrote:

* Markus Zakel wrote on Wed, Nov 22, 2000 at 08:35 +0100:

...

Hallo,

Wie aus dem anderen Threat bekannt benutze ich einen IBM 64Bit Server!

Nee, hab ich nämlich nicht gelesen :)

...

Nun ist: 1. die Frage was für eine DB läuft da am besten? - Oracle, -DB2, -MySQL ???

Läuft da ein "normales" SuSE linux? Dann sollten alle DBs so gut laufen, wie auf einem PC.

...

2. Welche ist am Sichersten (gegenüber Datenverlust incl. absturtz) und recht schnell?

MySQL ist schnell, weil es sich kaum um Sicherheit kümmert. Auch kostet das nur $200, für manche Anwendungen ist's sogar frei. Vom Preisleistungsverhältnis ist PostgreSQL unschlagbar, ist nämlich (richtig) frei und kann Transaktionen usw.. MySQL steht eben einfach ne Stufe unter Oracle, PostgreSQL und Co. Mit DB2 mußte ich mal kurz arbeiten, hat mir überhaupt nicht gefallen.

Ich kenne (leider ? ;)) nur mySQL, PostgreSQL und Oracle. Wenn man Oracle einsetzen will, sollte man sich auf jeden Fall zu Gemüte führen, daß dahinter auch ein gewisser Administrierungsaufwand steckt. Denn Oracle ist nicht so einfach ... leider am selben Leid erfahren, ich muß damit arbeiten. Privat habe ich hier Postgres und Oracle am laufen ... Sybase wäre IMHO auch noch eine Alternative gewesen ... Wichtig für eine DB sind eben (wie schon vorher aufgeführt) Transaktionen und da kannst du mit mySQL nicht's anfangen ... Am besten du fragst mal unter news://de.comp.datenbanken.misc nach, da wist du garantiert eher eine fundierte Meinung bekommen! :-) B. (das B. steht heut für besonders lustig ...) --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com