PostgreSQL Archive - oreillyblog

Der Jahrgang 2013 – Teil 2

Alexander Plaum — Wed, 27 Feb 2013 10:18:16 +0000

Tada! Der zweite Schwung druckfrischer deutschsprachiger Bücher in diesem Jahr. Diese Woche läuft die Auslieferung, spätestens nächste Woche sollten alle Händler versorgt sein: Von links nach rechts: Scrum – kurz & gut PostgreSQL Administration Das iPhone 5 Buch Backcatalog: Der Jahrgang 2013 – Teil 1

Der Beitrag Der Jahrgang 2013 – Teil 2 erschien zuerst auf oreillyblog.

Und jetzt alle mitsingen: Sieben Wochen, sieben Datenbanken

Alexander Plaum — Thu, 08 Nov 2012 10:27:42 +0000

Erinnern Sie sich noch an unser Twitter-Spiel #musikfürgeeks? Mit dem internationalen Videoclip zu unserem neuen RDBSM- und NoSQL-Buch „Sieben Wochen, sieben Datenbanken“ können wir quasi nahtlos daran anschließen: Für alle, denen das jetzt etwas schnell ging, gibt’s den doch ziemlich brillanten Text von Eric Redmond und Jim R. Wilson noch mal schwarz auf weiß (und im Anschluss gibt’s was zu gewinnen): Relational, columnar, graph or key-value store, document datastores, too. So much to discover, in this song we’ll cover from each type at least one or two. Neo4J, Postgres and HBase and Redis then CouchDB, Mongo and Riak. of partitions, consistency, availability: pick two, you can’t have all three-ach. Postgres is relational, stable, transactional. Tables have columns and rows. Rules, window functions and SQL for querying; vertically is how it grows. Riak’s key-value store implements Dynamo, shards data out to a ring. It’s REST-based with mapreduce link-walking functions and vector-clocks; made in Erlang. HBase is columnar just like BigTable: distributed, sorted and sparse. Hadoop’s ecosystem provides extra features but setup’s a pain in the arse. …

Der Beitrag Und jetzt alle mitsingen: Sieben Wochen, sieben Datenbanken erschien zuerst auf oreillyblog.

PostgreSQL: Entwickler Simon Riggs im Interview

Corina Pahrmann — Mon, 21 Feb 2011 10:42:04 +0000

Nutzen Sie OpenStreetMap? Telefonieren Sie via Skype? Oder spielen Sie World of Warcraft? All diese Angebote nutzen PostgreSQL, um ihre gewaltigen Datensammlungen vorzuhalten. Auch Banken, Regierungsbehörden oder Universitäten setzen auf das Open Source-Datenbanksystem, wie diese Liste der „Featured User“ zeigt. Nicht verwunderlich, denn PostgreSQL kann soviele Daten aufnehmen, wie der eigene Speicher hergibt – einige Petabyte sind das beispielsweise bei Yahoo!, das PostgreSQL zur Verarbeitung von Kundendaten einsetzt. Gleichzeitig läuft es stabil auf allen großen Serversystemen und kann frei erweitert und angepasst werden. Unsere britische Kollegin Josette Garcia hat gerade mit einem der PostgreSQL-Entwickler, Simon Riggs, gesprochen. In ihrem Interview wird eines der Erfolgsgeheimnisse von PostgreSQL klar: Eine Entwickler-Community, die routiniert und lösungsorientiert an dessen Weiterentwicklung arbeitet. „Jedes Jahr gibt es ein Major Release“, erklärt Riggs. „Wir überlegen, was dringend benötigt wird, entwerfen gemeinsam eine Lösung und implementieren diese dann.“ Nach einigen Tests sei der Code dann solide genug, um Eingang in PostgreSQL zu finden. Riggs bestätigt, dass PostgreSQL sehr häufig eingesetzt wird – und das ohne große Marketingstrategien. Die meisten Techies kennen PostgreSQL, und …

Der Beitrag PostgreSQL: Entwickler Simon Riggs im Interview erschien zuerst auf oreillyblog.

Performance-Tuning in PostgreSQL – Teil 2

Viviane Kramer — Mon, 14 Feb 2011 15:35:57 +0000

Vor kurzem haben wir uns bereits mit Performance-Tuning in PostgreSQL beschäftigt. Dabei haben wir im ersten Teil des Buchauszugs aus “PostgreSQL-Administration“ von Peter Eisentraut und Bernd Helmle drei Enpässe oder Flaschenhälse vorgestellt, die die Ausführung eines SQL-Befehls verlangsamen können. Im zweiten und letzten Teil stellen wir heute drei weitere Engpässe vor, die Sie zur Beschleunigung und Optimierung eines SQL-Befehls kennen sollten: nämlich Festplattenlatenz, Festplattenrotation und Netzwerkverbindungen. Festplattenlatenz Die Latenz eines Festplattensystems beschreibt, wie lange es dauert, bis eine bestimmte Information darauf gelesen werden kann, vor allem bedingt durch die nötigen mechanischen Bewegungen. Das fällt insbesondere bei Indexzugriffen ins Gewicht, da dort die Informationen naturgemäß nicht sequenziell, sondern verteilt vorliegen. Genau analysieren kann man diese Effekte als Anwender so gut wie nie. Man wird jedoch bemerken, dass bei wahlfreien Zugriffen wie einer Indexsuche der mit iostat oder ähnlichen Programmen beobachtete Festplattendurchsatz bei sehr niedrigen Werten wie 4 MByte/s sein Maximum zu erreichen scheint. Vermieden werden können Latenzeffekte am besten, indem man ausreichend RAM für die Indexe als Cache zur Verfügung stellt. Dadurch fallen die mit der …

Der Beitrag Performance-Tuning in PostgreSQL – Teil 2 erschien zuerst auf oreillyblog.

Performance-Tuning in PostgreSQL – Teil 1

Viviane Kramer — Wed, 02 Feb 2011 16:06:25 +0000

PostgreSQL gilt seit Jahren als das fortschrittlichste Open-Source-Datenbankmanagementsystem und ist millionenfach im Einsatz. Ein Thema, das PostgreSQL-Administratoren unter anderem beschäftigt, ist Performance-Tuning – also die Frage, wie Anfragen und SQL-Befehle schneller gemacht werden können. Dieser Frage und anderen widmen sich auch die Autoren Peter Eisentraut und Bernd Hemle in ihrem Buch „PostgreSQL-Administration„. Wie man Enpässe oder Flaschenhälse, die die Ausführung eines SQL-Befehls verlangsamen, richtig erkennt und optimiert, erfahren Sie im ersten Teil des Buchauszugs. Heute geht es um CPU, RAM und Festplattendurchsatz. Im zweiten Teil wird es dann um Festplattenlatenz, Festplattenrotation und Netzwerkverbindungen gehen. CPU PostgreSQL startet pro Datenbankverbindung einen Prozess, und moderne Betriebssysteme verteilen diese Prozesse dann auf mehrere CPU-Kerne, falls vorhanden. Generell kann aber somit ein SQL-Befehl nur auf maximal einem CPU-Kern laufen. Sehr rechenintensive SQL-Befehle können einen CPU-Kern schon eine Weile auslasten. Das kann man dann einfach mit Betriebssystemwerkzeugen wie ps oder top beobachten. In der Praxis ist die CPU aber im Gegensatz zu den anderen aufgeführten Kandidaten eher selten das Problem. Wenn doch, dann bleibt einem in der Regel nichts anderes …

Der Beitrag Performance-Tuning in PostgreSQL – Teil 1 erschien zuerst auf oreillyblog.