[linux-l] Dateien mit '/' im Dateinamen

[Steffen Dettmer]

* Peter Ross wrote on Fri, Aug 08, 2003 at 10:46 +1000:
> > Warum setzt man eigentlich mySQL ein? Hab ich hier schonmal
> > gefragt, ich weiß, wollte bloß mal hören, ob's inzwischen einen
> > Grund gibt.
> 
> ich lass hier mal mein Halbwissen raus (bin SysAdmin, der oefter mit
> DB-Admins und -Entwicklern zusammenarbeitet)
> 
> Also Vorsicht, dies ist subjektiv!

Prima! Ist ja jede Entscheidung ein bißchen.

> Das beste Beispiel ist der erwaehnte Webserver, tomcat, dessen
> Daten aus der MySQL-DB kommen.

Catalina ist ein viel schönerer Name als Tomcat. Aber beides viel
schöner als drei- bis fünfstellige Abkürzungen/Zahlencodes, wie
viele kommerzielle Produkte heißen :-)

> Ich nenne das immer eine Read-Only-Datenbank.

> Das Design der DB ist recht "platt", d.h. es werden nicht allzu
> viele Joins gemacht, stattdessen werden kleinere Tabellchen
> direkt in die grossen eingebettet (also nicht bis zum Ende
> durchnormalisiert)
> 
> In diesem Szenario ist die DB verdammt schnell, und ich glaube,
> dass ist auch MySQLs Reputation.

Ja, stimmt. Macht Sinn. Wenn es nur schnell sein soll und nichts
können muß, aber nicht mehr in den Speicher paßt, ist das ein
Weg. Ja, ich hab vor langer Zeit mal verglichen: bei kleinen
Daten (so paar tausend Datensätze) ist mySQL schneller als
PostgreSQL. Bei mittleren Datenbanken (so mit paar Millionen
Datensätzen) werden die Unterschiede schnell verschwinden,
schätze ich, weil das Rechteprüfen etc., was PostgreSQL
zusätzlich macht, ja nicht mehr so ins Gewicht fällt. Ich hab
damals auch mal mit Perl hashes rumgespielt. Hatte irgendwie
einfach geschachtelt (so als join-mit-index-Simulation :-)) und
irgendwie war das furchtbar schnell. Na ja, sind dann ne Handvoll
memory-Zugriffe. Fetzt.

> Wenn das der Fall ist, kommen zumindest bei der 3er Version 'ne
> ganze Menge Macken zu Tage. In meiner letzten Firma waren
> "aufgehaengte" MySQL-Prozesse und kaputte Indizes leider nicht
> wirklich rar.

ohh. Ist ja schlimmer, als ich dachte... Dachte, es gibt nur
weniger Funktionen.

> Das hat die Firma dazu bewogen, auf Postgres umzusteigen.
> Probleme dieser Art verschwanden dadurch.

und man kann dann auch trigger und sowas in Pg/PSQL schreiben,
was die Oracle-Leute wieder freut, was? :-)

> MySQL 4 hoert sich ja vielversprechend an, z.B. was
> Verbesserungen im Bereich Transaktionen angeht, aber das
> Vertrauen war hin, keiner wollte das auch noch testen.

Ist dann zu erwarten, daß es dann fast so schnell wie PostgreSQL
wird, wenn man das alles unterstützt, nur das es nicht so stabil,
weil neu ist?

> Also - als "flache ReadOnly-DB" kann ich Dir zu MySQL raten.
> Typisch fuer einen Webserver, der Daten anzeigen soll
> (Fernsehprogramm, Preislisten, Shopping Center, was auch
> immer), wo Du die fortlaufenden Aenderungen nicht in die
> MySQL-DB einpflegst, sondern eher nach Aenderung in einer
> "richtigen" DB MySQL updatest.

mmm... Na ja, muß zugeben, für mich eher weniger. Ich arbeite mit
Datenbanken nicht so gern direkt auf Tabellen, weil man immer die
Software anpassen muß, wenn sich die Struktur ändert. Ich mach
mir da gerne StoredProcedures (oder eben Funktionen), die die
Daten entsprechend sammlen. Jajaja, ist natürlich noch langsamer,
aber dann muß man eben 256MB Speicher reinstecken. Macht zwar
erstmal mehr Arbeit, dafür kann man später auch mal Tabellen
aufteilen etc. und muß einfach nur die SPs anpassen, Testtreiber
durchnudeln lassen und die Chance, daß es dann noch geht, ist
recht groß :-)

Gut, ein Fernsehprogramm ist wohl nicht so groß, so daß man es
noch in einen Hash in den Speicher laden kann, denke ich. Und da
kommt dann an Performance nix mehr ran, natürlich unterbietete
auch nichts die Flexiblität :-)

> Fuer einen kleinen Online-Shop mag's ja auch noch gehen. Mehr
> wuerde ich MySQL 3 nicht zutrauen.

Na, bloß für einen kleinen Shop braucht man wieder keine
Performance, so daß man auch wieder PostgreSQL benutzen kann.
Außerdem muß man gerade bei Shops transaktionen haben, damit
Warenkörbe, Lager und Orderprocessing auch funktionieren, wenn
jemand im Browser "STOP" clickt, und das Backend nur noch ein
kleines EOF bekommt. Dann möchte ich schon ein sauberes Rollback
haben.

> Ach ja.. irgendwelche kleineren Problemchen, die der Entwickler
> der o.g.  Webserver monierte, waren in jeder neuen Version
> hinterm zweiten Punkt zu finden. Ich sollte doch bitte nicht
> von .37 auf .38 umstellen, aber .41 ginge wieder.. Eine neue
> Version gab's wohl alle 14 Tage.

Ohh, fein. Fetzt, wenn man das in Produktion hat... Dann updatet
man eben mal ne Datenbank? Mußte mal PostgreSQL von uralt
updaten, weil da doch jemand mehr als 8KB Strings in *ein*
Tabellenfeld haben mußte, und das alte PG nur 8KB konnte. Hat mit
Testen etc. einen Tag gedauert.

> Solche Wuensche sind auch nicht gerade vertrauensbildend.

Nee, wirklich nicht... 

Danke für Deine ausführliche Antwort, super!

oki,

Steffen

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