Postgres-XC project Page. Multi-Master (Read und Write) Cluster für PostgreSQL. Unterstützt replicated Setups genauso wie partitioned Setups (oder Mischformen).
postgresql
PostgreSQL: Documentation: 8.4: hstore. Aus der Reihe "Sachen die deine Datenbank kann, die du aber vielleicht nicht kennst": Key-Value-Stores innerhalb eines PostgreSQL Datenfeldes. Oder auch poor-mans-object-notation. Oder einfach dann praktisch, wenn man lose strukturierte Daten ablegen will, aber nicht ständig das Schema anpassen will - das Schema sind dann die primären Daten für die Ordnung des Modells, die Abhängigkeiten, Kardinalitäten etc. - und das hstore Feld speichert dann die zusätzlichen Ausprägungen, die sich zum Beispiel durch fachliche Anforderungen dynamisch ergeben. Manchmal die bessere Alternative zu einer ausnormalisierten Property-Tabelle. Und das ganze ist schon seit den 8er Versionen drin (ist allerdings ein ladbares Modul).
TeamPostgreSQL - PostgreSQL Web Admin GUI Tools. Sieht gut aus, eine Weboberfläche für die Administration von PostgreSQL Datenbanken, die an PGAdminIII heranreicht und nicht so spartanisch aussieht wie PHPPGAdmin. Allerdings hab ich Probleme auf Datenbanken aus einem Projekt zuzugreifen - es scheint nicht alles so ganz sauber implementiert zu sein, speziell bei der Behandlung von Sequences. Von daher kann ich noch nichts dazu sagen, ob es performant ist. Das ganze kommt komplett mit Java-Tomcat-Server daher, so das man es direkt lokal installieren und ausführen kann.
The Schemaverse. Und weil wir gerade bei seltsamen Projekten sind: da hat jemand ein MMO programmiert, das komplett innerhalb PostgreSQL läuft. Also pgSQL als Sprache benutzt. Sowas wie ein Multi-User-Schiffeversenken. Nur läuft es halt in einer Datenbank. Und wird über SQL bedient.
Temporal Keys, Part 2 | Experimental Thoughts. Man lernt doch immer wieder was neues über PostgreSQL - diesmal PERIOD, ein Datentyp, der Zeitspannen umfasst, und EXCLUDES, eine weitere Form von Constraint auf Tabellen, mit denen sich zusammen mit PERIOD dann Überlappungen von Zeiträumen schon im Datendesign vermeiden lassen. Unter Dynamics AX gibt es sowas in Form der Date Effectivity, wobei das dann noch etwas weiter geht, weil auch automatisches Anlegen neuer Bereiche, Gap-Freiheit von Zeitleisten etc. abgebildet werden, wärend das hier nur die Grundlagen für überlappungsfreie Datensätze sind. Andererseits lässt sich das ja auch wesentlich breiter nutzen, da man beliebige EXCLUDES-Constraints formulieren kann.
XML in Postgres – The Game Changer « Flex and Specs() - ich sollte wirklich mal mehr die neuen PostgreSQL Features angucken. Speziell weil die XML-Unterstützung in PostgreSQL einige der Vorteile von dokumentenorientierten Datenbanken auf die relationale Welt rüberbringen, ohne dass man dazu extra Middleware braucht.
PostgreSQL: News: 9.0 Alpha 4 Available Now - hieß bisher 8.5, ist also die Version mit der streaming replication.
git.postgresql.org Git - postgresql.git/commit - die ersten Replikationsfeatures kommen in den PostgreSQL Tree und werden daher in 8.5 verfügbar sein. Klasse!
What happened to Hot Standby? - echte native Synchronisation kommt für PostgreSQL 8.5! Gibt schon bestehende Lösungen, aber native ist natürlich einfacher für die Administration. Und sollte endlich die albernen Diskussionen mit den MySQL-Jüngern verkürzen.
Postgres-R: a database replication system for PostgreSQL - mal angucken?
Materialized Views in PostgreSQL - interessante Alternative zu Denormalisierung (bzw. eine Technik zu organisierter Denormalisierung, die das relationale Modell nicht allzusehr mit Füssen tritt, da die logische Sicht weiterhin die saubere normalisierte Form ist, aber automatisch performance-optimierte Denormalisierungen stattfinden)
Database test: dual Intel Xeon 5160 (6/6) - könnten jetzt bitte alle MySQL-Verfechter die Grafiken angucken und endlich die Schnauze halten? MySQL ist ein gehypter Karteikasten mit mittelmäßiger Performance (die man sich mit selbstschrottenden Indizes erkaufen muss) und unzureichenden Features. Punkt.
Automatic Pickle Serialization and Deserialization with PostgreSQL - sehr interessant, automatisches pickle/unpickle bei Nutzung von PsycoPG2.
cucumber2: an object-relational mapping system for Python and PostgreSQL - ein weiterer ORM für Python. Besonderheit hier: PostgreSQL Tabellenvererbung wird benutzt, um die Übergänge zwischen Objekten und Klassen einfacher zu gestalten. Dadurch aber auch nicht auf andere Datenbanken portierbar.
jacobian.org : Django performance tips - Jacob, einer der Dango Core-Devs schreibt über Performance-Tuning für Django Applikationen. Deckt sich stark mit meinen Erfahrungen.
pgpool page - interessanter Verbindungsproxy für PostgreSQL mit Connection-Pooling und Datenbank-Failover.
sql relay ist ein SQL connection pool der verschiedenste Datenbanken bedienen kann und die Verbindungen von Clients zur Datenbank über einen zentralen Pool abwickelt. Ideal in Multi-Host-Umgebungen und wenn die Connecton-Last zu hoch ist (z.B. erzeugt Django pro Request eine Connection).
PostgreSQL 8.1
PostgreSQL 8.1 mit Two-Phase-Commits und Benutzerrollen:
Transaktionen können nun auf mehreren Rechnern mit PREPARE TRANSACTION vorbereitet und später gemeinsam ausgeführt werden. Fällt eine Maschine nach dem PREPARE aus, lässt sich die Transaktion nach dem Neustart per COMMIT korrekt abschließen.
Yes!
PostgresPy ist eine Sammlung verschiedener Python-Module rund um Postgres. Serverseite und Clientseite.
Wer mit PostgreSQL nur gelegentlich arbeitet, es sozusagen als Desktopdatenbank benutzen will: PostgreSQLX ist eine Zusammenstellung des PostgreSQL Servers die einfach als Mac Applikation gestartet und gestoppt werden kann. Ideal für Entwickler. Dazu dann noch die PGAccess Oberfläche und man kann auf sowas wie Microsoft Access verzichten. Auch das alles natürlich wieder nur ab 10.3 (wird Zeit das 10.4 kommt und ich zu Hause wieder mal auf aktuellem Stand bin).
PostgreSQL 8.0.2 released with patent fix
Gerade gefunden: PostgreSQL 8.0.2 released with patent fix. PostgreSQL hat also eine neue Minor-Version bekommen in der ein patentierter Caching-Algorithmus (arc) gegen einen nicht patentierten (2Q) ausgetauscht wurde. Das interessante: das ist eines der Patente die IBM für Open Source freigegeben hat. Und warum haben die trotzdem gewechselt? Weil IBM diese Patente für Open Source Nutzung zwar freistellt, aber nicht für kommerzielle Nutzung - PostgreSQL ist aber unter BSD Lizenz, die explizit auch kommerzielle Nutzung völlig frei stellt.
Für PostgreSQL selber hätte das kein Problem bedeutet: solange es BSD bleibt, hätte weiter die Nutzung des IBM-Patents keine Probleme gemacht. Nur ein späterer Lizenzwechsel - wie er z.B. entsteht wenn jemand die BSD-Software für ein kommerzielles Produkt als Basis wählt - wäre ausgeschlossen.
Ein schönes Beispiel wie selbst liberal gehandhabte Softwarepatente Probleme machen. Denn gerade mittelständische Firmen die kommerzielle Produkte auf Open Source aufbauen hätten also eine bisher verfügbare Basis verloren - nur aufgrund des patentierten Cachingalgorithmus (effiziente Speicherung von und effizienter Zugriff auf Daten - also nach Clements' Vorstellung patentierbar).
Im Falle von PostgreSQL ist es unkritisch abgelaufen: der patentierte Algorithmus ist nicht schneller oder besser als sein nicht patentierter. Und für die Software selber ist nichts wirklich weltbewegendes verändert worden. Aber das muss (und wird) nicht immer so glimpflich ablaufen. Im Bereich Audioprocessing und Videoprocessing sind die patentierten Minenfelder viel weiter ausgebaut und damit viel kritischer für freie Projekte.
Ok, man mag jetzt noch argumentieren das mit GPL Lizenz dem PostgreSQL das nicht passiert wäre. Aber mit GPL Lizenz sind eben manche Formen der Verwendung wie sie bei PostgreSQL heute schon existieren (z.B. das Firmen Spezialdatenbanken auf PostgreSQL aufbauen ohne diese Spezialdatenbanken zu Open Source zu machen) nicht möglich. Man mag dazu stehen wie man will - Ideologie hin oder her - das PostgreSQL Projekt hat nunmal die BSD Lizenz als Basis gewählt.
Selbst wohlwollende Patenthandhabung im Kontext von Open Source Software wäre also problematisch. Genau sowas ist der Grund warum ich generell gegen Softwarepatente bin.
Revanche des Karteikastens
Tja, es gibt so Tage im Leben eines Admins die tun weh, aber sind nötig: ich spiele im Moment mit einem Spam-Filter ( DSPAM) herum, der seinen Statistikdaten in einer SQL-Datenbank speichert. Der Spamfilter unterstützt eine ganze Reihe von Datenbanktreibern, unter anderm PostgreSQL und MySQL und ein paar andere non-client-server Datenbanken (SQLite etc.). Ich hab also gewohnheitsgemäß zuallererst zu PostgreSQL gegriffen - lief auf der Kiste ja eh schon.
Nunja, am Anfang etwas zäh und die Kiste wurde etwas unter Damp gesetzt, aber ich habe ein paar Tipps im Netz gefunden mit denen man PostgreSQL für DSPAM Beine machen konnte. Danach lieft der Rechner zwar nicht begeisternd schnell, aber deutlich fixer als vorher. Also mal ne Nacht durchlaufen lassen.
Nunja, am nächsten Tag das böse Erwachen: tonnen von blockierten Prozessen, schweinelangsame Updates gegen die Datenbank, tödliche Performance beim Umlernen einer Mail: 12 Minuten Laufzeit keine Besonderheit. Autsch. Der Dump der Datenbank ist zu dem Zeitpunkt schon 100 MB gross. Das ganze ist irgendwie nicht so begeisternd, wenn die Systemlast so immer zwischen 3 und 6 pendelt ... Ok, also in den sauren Apfel beissen und den Karteikasten MySQL installiert und konfiguriert. Danach dann den Exim wieder hochgefahren und die wartenden Mail einsortiert. Effekt: totale Load-Explosion. Loads oberhalb von 30 und dann irgendwann schlug der Watchdog zu und bootet. Oh shit. Alles klar, mal nachgeguckt was eigentlich in der Kiste steckt: jau, nur 256 MB Speicher und der MySQL-Server geriet massiv ins Pagen. Da kann er nu ja nix für, wenn ich einfach zu wenig Speicher habe. PostgreSQL hatte damit weniger Probleme, weil das Speichermanagement von PostgreSQL wesentlich statischer ist und der Server nicht so viel Speicher in der Grundkonfiguration an sich reisst.
Ok, Jutta hat mit ihrem Linux-Kasten den Speicher getauscht und jetzt hat der Server 512 MB Speicher, das reicht ihm für den Zweck. Und die Systemlast mit MySQL drauf ist deutlich besser als alles vorher. Ok, ich könnte sicherlich auch PostgreSQL mit grösserer Konfiguration zu besserer Performance bringen, aber das Problem war den Symptomen nach bei PostgreSQL die massive Anzahl paralleler Updates und die Multiversion-Transaktions-Technik des Servers - die war in diesem konkreten Fall definitiv im Weg.
Merke: MySQL ist zwar weiterhin nur ein glorifizierter Karteikasten und MyISAM definitiv das eigentlich dümmste Tabellenformat das man wählen kann, aber keine Technik ist so blöd das man sie nicht doch ab und an brauchen könnte. Wenn die Daten nämlich völlig transaktions-fremd sind - weil der SQL-Server eben einfach nur als Datenablage missbraucht wird, ohne das es ein echtes fachliches Datenmodell mit grosser referentieller Integrität vorliegt - sollte man eben einfach keine Datenbank benutzen deren Schwerpunkt dem genau entgegensteht. Da ist MySQL und MyISAM schlicht und einfach die bessere Wahl.
Besser als Berkley-DB oder andere In-Process-Datenbanken ist es allemal, denn die können nur über File-Locking verlässlich arbeiten und bei den massiven parallelen Updates die DSPAM nunmal macht (er lernt - je nach Einstellung - bei jeder Mail und aktualisiert so seine statistische Basis) ist eine Datenbank auf Filesystembasis denkbar ungünstig.
Jetzt werde ich mal die nächste Nacht abwarten und schauen wie sich DSPAM mit dem nächtlichen Mailberg abmüht und wie das System morgen aussieht, wenn mehrere tausend Mails durchgerauscht sind (ja, wir verbraten mit nur zwei Usern gigantische Mengen an Mailtraffic - liegt primär an Bergen von Spam, Bergen von administrativen Mails diverser Systeme und Bergen von Mailinglisten). Mal schauen ob das System morgen noch genauso fix ist wie heute. Ich fürchte ja das ich bei den Mengen an Mail auch die MySQL-Basis für DSPAM an den Rand des Möglichen treiben werde ...
Update: also bis jetzt siehts sehr gut mit der Load aus, der Karteikasten hat also tatsächlich mal die Nase vorne
Ape kann Python-Objekte in Zope transparent auf Filesystemobjekte oder PostgreSQL Datenbanken mappen. Könnte auf der Arbeit sehr interessant sein. Kann auch standalone (ohne Zope) benutzt werden.
Pro-Linux News: Daffodil Replicator wird freie Software - Replicator der Datenbank-agnostisch ist und unter anderem PostgreSQL unterstützt
tsearch-v2-intro - Einführung in tsearch2 - eine Volltextindextechnik für PostgreSQL
Tsearch2 - full text extension for PostgreSQL - weitere Dokumentationen zu tsearch2
ONLamp.com: Introducing Slony - Slony ist eine asynchrone Replikationslösung für PostgreSQL
Squawks of the Parrot: Suboptimal optimizing - PostgreSQL hat einen Bug beim Optimieren von LIKE Ausdrücken
Tsearch2 - full text extension for PostgreSQL - Volltextindizes für PostgreSQL
gppl's nest - Hierarchische Queries mit PostgreSQL