ich benötige für eine neue Entwicklung eine DB die Sicherheit bietet und PErformant ist.
So Sachen wie schnelles lesen und schreiben, sowie Transaktionen und paralleles Schreiben (da eine Multiuseranbindung) sollten möglich sein.
Nun habe ich einiges an Artikel gelesen, auch Vergleich von MySql und PG.
MySql >5 bietet nun auch ähnliche features an wie PG.
Wie sind eure Erfahrungen?
Bietet PG die entsprechenden Features die ich benötige?
Welche Sicherheitsaspekte bietet PG?
Was kann PG deutlich besser?
Oder sollte man doch eher auf kommerz. DBs zurückgreifen?
Die Frage nach Evaluierungen hatten wir hier doch letztens erst …
Du solltest vielleicht nicht so oberflächlich Fragen stellen wie “welche Sicherheitsaspekte bietet …” oder “was kann …”. Du solltest lieber schauen, was ihr konkret für euer Projekt benötigt und dann diese konkreten Fragen beantworten.
MySQL ht IMHO mittlerweile den entscheidenden Nachteil, das Sun nicht mehr alle Features und Engines in die freie Version implementieren wird. In diesem Fall, wenn ich dann sowieso Geld in die Hand nehmen muß, zahle ich lieber für was richtiges wie Oracle oder DB2. Im Highend-Bereich sowieso. Für alles andere ist ist Postgres meineserachtens die bessere Wahl, auch wenn der Umgang damit umständlicher erscheint als bei MySQL. Ansonsten kann ich dir nur raten, einen konkreten Anforderungskatalog für dein Projekt zu erstellen und diesen dann zu recherchieren. Danach kann man dann einen sinnvolleren Vergleich zwischen den einzelnen Produkten vornehmen.
danke für eure Antworten!
Ich habe in de letzten Tagen sehr viele Artikel und vergleiche zu diesem Thema gelesen. Leider ist es oftmals so, dass MySql beleuchtet wird, dabei aber die anderen DBs etwas zu kurz kommen.
Für mich ist es z.B. wichtig, dass es paralleles Schreiben/Lesen anbietet.
Transaktionen. Wobei bei den Transaktionen nicht alle Tabellen gesperrt werden.
Bei meiner Anwendung werden höchstwahrscheinlich zu mehreren Zeiten gleichzeitiges Lesen und Schreiben in die DB notwendig sein. Also eine sehr zeitkritische Anwendung.
PostgreSQL bietet durch MVCC eine bessere Performance bei gleichzeitigen Zugriffen. Um genau zu sein sind bei passender Hardware mehrere Hundert parallele Zugriffe ohne Performance Einbrüche kein Problem.
PostgreSQL kann replizieren, die passenden Stichworte für die Suche sind “PITR” und “Slony”, ev. noch “pgcluster”, aber das möchte man eigentlich nicht nutzen. Was du nicht findet wirst, ist eine Master-Master Replikation, wobei letzteres bei Mysql auch nur eine Augenwischerei ist.
Nun ja, das ist wie mit den Fliegen. Millionen von Fliegen fressen Scheiße. MySQL ist bei vielen Providern halt dabei, was aber nicht wirklich viel besagen muß.
Für mich ist es z.B. wichtig, dass es paralleles Schreiben/Lesen anbietet.
MySQL mit MyISAM macht IIRC bei Schreiboperationen einen Full Table Lock. Egal, was andere machen: in PG ist das kein Problem Dank MVCC.
Transaktionen. Wobei bei den Transaktionen nicht alle Tabellen gesperrt werden.
Wir haben sogar bei DDL-Operationen Transaktionen. Das bietet ORA z.B. nicht.
Bei meiner Anwendung werden höchstwahrscheinlich zu mehreren Zeiten gleichzeitiges Lesen und Schreiben in die DB notwendig sein. Also eine sehr zeitkritische Anwendung.
Ach ja eine Sache noch… Kann PG replizieren?
siehe ads.
GRüsse
Was PG auch kann, und MySQL nicht, kurze Auswahl:
Nutzung mehrere Indexe pro table und select
funktionale Indexe
kostenbasierter Optimizer (vergleich einfach mal die Explain-Ausgaben)
Transaktionen sind elementarer Bestandteil der DB, nicht einer Speicher-Engine.
Ich kann mich zwar nicht mit akretschmer & ads messen, jedoch stand ich auch vor dieser Frage und postgreSQL ist in jedem Fall das Richtige, wenn es um komplexere Anwendungen geht.
Du kannst z.B. einen Index auf LOWER(spalte) oder auch auf MD5(spalte) legen …
Wenn du dann einen Query ala WHERE MD5(spalte) = ‘md5 Summe’ ausführst, dann wird der Index mit den vorberechneten Werten genutzt.
Gibt es eine gute Seite, wo man vieles über Postgres nachlesen kann, wenn man sich da rein arbeiten möchte?
Die Doku z.B. ist sehr umfangreich und ein guter Start.
Ansonsten schreibe ich gerade an einem Buch
Welche Stolperfalen für Anfänger gibt es?
Diverse, aber nichts, was sich nicht lösen lässt.
Probleme haben vor allem diejenigen, die von Mysql kommen - alle anderen Datenbanken halten sich an Standards.
Ein weiterer Stolperstein, der mir einfällt, ist die Authentifizierung. Wenn du einen Blick in die Datei pg_hba.conf wirfst, findest du jedoch viele Beispiele.
Zu dem, was ads schon sagte, hier mal ein anderes Beispiel, was IMHO besser zeigt, was da alles geht.
Angenommen, Du hast eine Tabelle mit einer timestamptz-Spalte und eine Abfrage, wo Du nur die willst, die auf einen Sonntag fallen. Um den Wochentag zu bestimmen, gibt es extract(dow from timestamptz), allerdings ist dies nicht immutable. Das heißt ganz schlicht, daß diese Funktion nicht nur von den Daten selbst abhängt, sondern auch von der Zeitzone. Ich bilde also einen funktionalen Index auf extract() den Wochentag in der Zeitzone ‘cest’. Im folgenden mal ohne und mit dem Index ein EXPLAIN ANALYSE:
scholl=*# explain analyse select * from lief_kopf where extract(dow from ts at time zone 'cest') = 0;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------
Seq Scan on lief_kopf (cost=0.00..1892.32 rows=74 width=797) (actual time=185.524..185.524 rows=0 loops=1)
Filter: (date_part('dow'::text, timezone('cest'::text, ts)) = 0::double precision)
Total runtime: 185.651 ms
(3 rows)
scholl=*# create index idx_wochentag on lief_kopf(extract (dow from ts at time zone 'cest'));
CREATE INDEX
scholl=*# explain analyse select * from lief_kopf where extract(dow from ts at time zone 'cest') = 0;
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------
Bitmap Heap Scan on lief_kopf (cost=2.26..247.31 rows=74 width=797) (actual time=0.113..0.113 rows=0 loops=1)
Recheck Cond: (date_part('dow'::text, timezone('cest'::text, ts)) = 0::double precision)
-> Bitmap Index Scan on idx_wochentag (cost=0.00..2.26 rows=74 width=0) (actual time=0.104..0.104 rows=0 loops=1)
Index Cond: (date_part('dow'::text, timezone('cest'::text, ts)) = 0::double precision)
Total runtime: 0.274 ms
(5 rows)
Meine Abfrage ist gleich mal um grob Faktor 1000 schneller.
