Von Postgres wird immer besser! am Di, 15. Mai 2012 um 17:29 #
Vielen Dank für den Artikel! Es freut mich immer wieder, wenn ich sehe, dass sich Postgres so toll entwickelt. Es scheint zurzeit das einzige auch in grösseren Projekten ernsthaft einsetzbare OpenSource-RDBMS zu sein (oder kennt jemand bessere?).
Besonders schön finde ich, dass sich die DB wirklich an den SQL-Standard hält (oder versucht es zumindest intensiv). Bei MySQL gibt es ja da sehr viel Besonderheiten, die die Portabilität des SQL-Codes auf andere Datenbanksysteme ungemein erschweren (was gerade dann relevant wird, wenn ein Projekt wachst und ggf. das RDBMS ausgewechselt werden muss).
Wir benutzen in unseren Projekten immer HSQL. Die Performanz ist ungeschlagen und auch der nicht so schlaue Administrator freut sich, daß er nicht so viel tun muß.
Ich frage mich immer, warum Programme oft nur bis zu einer bestimmten Anzahl Prozessoren skalieren. Meine (naive) Vorstellung ist, dass wenn ich mein Programm so plane, dass es in mehreren Threads abgearbeitet werden kann, dann sollte doch kein Limit entstehen. Oder ist bei solchen Programmen die Anzahl von Threads im Programmcode hart verdratet? Oder wird die Verwaltung der Threads ab einem Punkt so "teuer", dass mehr Rechenleistung für die Synchronisierung als für den eigentlichen Programmablauf verbraucht wird? Wird letzteres nicht über die verwendeten Threadbibliotheken oder VMs abgewickelt und nicht durch die Anwendung selbst?
Wenn du ein Programm planst und schreibst, musst du unter anderem auch die Threads koordinieren. Z.B. musst du verhindern, dass sie nicht gleichzeitig bestimmte Variablen schreiben, um Race-Conditions zu verhindern. Diese Koordination kann auch vom Datendurchsatz abhängen. Denn wenn ein Thread die ganze Zeit am rechnen ist, hat er vielleicht weniger Zeit für Thread-Koordination?
Es gibt bestimmte Algorithmen die sehr gut skalieren. (Vektorrechnung zB) Andere sind kompliziert zu skalieren, wie zB SQL-Datenbankabfragen...
Vielen Dank für den Artikel!
Es freut mich immer wieder, wenn ich sehe, dass sich Postgres so toll entwickelt. Es scheint zurzeit das einzige auch in grösseren Projekten ernsthaft einsetzbare OpenSource-RDBMS zu sein (oder kennt jemand bessere?).
Besonders schön finde ich, dass sich die DB wirklich an den SQL-Standard hält (oder versucht es zumindest intensiv). Bei MySQL gibt es ja da sehr viel Besonderheiten, die die Portabilität des SQL-Codes auf andere Datenbanksysteme ungemein erschweren (was gerade dann relevant wird, wenn ein Projekt wachst und ggf. das RDBMS ausgewechselt werden muss).
Gruss
JustMe
Wir benutzen in unseren Projekten immer HSQL. Die Performanz ist ungeschlagen und auch der nicht so schlaue Administrator freut sich, daß er nicht so viel tun muß.
Das ist aber Pech, dass ich das gehört habe.
Du wolltest einen neuen Computer? Das wird wohl nix.
Ich frage mich immer, warum Programme oft nur bis zu einer bestimmten Anzahl Prozessoren skalieren. Meine (naive) Vorstellung ist, dass wenn ich mein Programm so plane, dass es in mehreren Threads abgearbeitet werden kann, dann sollte doch kein Limit entstehen. Oder ist bei solchen Programmen die Anzahl von Threads im Programmcode hart verdratet? Oder wird die Verwaltung der Threads ab einem Punkt so "teuer", dass mehr Rechenleistung für die Synchronisierung als für den eigentlichen Programmablauf verbraucht wird? Wird letzteres nicht über die verwendeten Threadbibliotheken oder VMs abgewickelt und nicht durch die Anwendung selbst?
Woher soll die Threadbibliothek oder die VM wissen, wie die Daten einer bestimmten Applikation am besten zu parallelisieren sind?
Ne, es liegt hauptsächlich am Overhead, den die Parallelisierung erzeugt. Irgendwann ist der größer als der Gewinn
Wenn du ein Programm planst und schreibst, musst du unter anderem auch die Threads koordinieren. Z.B. musst du verhindern, dass sie nicht gleichzeitig bestimmte Variablen schreiben, um Race-Conditions zu verhindern. Diese Koordination kann auch vom Datendurchsatz abhängen. Denn wenn ein Thread die ganze Zeit am rechnen ist, hat er vielleicht weniger Zeit für Thread-Koordination?
Es gibt bestimmte Algorithmen die sehr gut skalieren. (Vektorrechnung zB) Andere sind kompliziert zu skalieren, wie zB SQL-Datenbankabfragen...