Wir machen Sie auf eine Übersetzung von Joseph Hellersteins Artikel „Rückblick auf Postgres“ aufmerksam , der unter der Creative Copyright International Copyright Affirmation Version 4.0 (CC-BY 4.0) veröffentlicht wurde. Die Autoren behalten sich das Recht vor, diese Arbeit auf persönlichen und Unternehmenswebsites mit einem ordnungsgemäßen Link zur Quelle zu verbreiten.

Übersetzung von Elena Indrupskaya. Ich möchte von mir selbst hinzufügen, dass "ein Programmierer, der unbedingt ein System mit Multi-Versionierung bauen wollte" Vadim Mikheev zu sein scheint, aber wir alle kennen die "Freiwilligen aus Russland", die GiST neu geschrieben haben.

Anmerkung

Dies ist eine Erinnerung an das Postgres-Projekt, das an der University of California in Berkeley durchgeführt wurde und von Mitte der 1980er bis Mitte der 1990er Jahre von Mike Stonebraker geleitet wurde. Als eine von vielen persönlichen und historischen Erinnerungen wurde dieser Artikel für das Buch [ Bro19 ] über Stonebreakers Turing Award angefordert. Daher liegt der Schwerpunkt des Artikels auf der Hauptrolle von Stonebreaker und seinen Gedanken zum Design. Aber Stonebreaker war nie ein Programmierer und störte sein Entwicklungsteam nicht. Die Postgres-Codebasis war die Arbeit eines Teams brillanter Studenten und gelegentlich hauptberuflicher Universitätsprogrammierer, die etwas mehr Erfahrung (und nur ein etwas höheres Gehalt) als Studenten hatten. Ich hatte das Glück, in den letzten Jahren des Projekts als Student diesem Team beizutreten. Ich habe nützliches Material für diesen Artikel von einigen der älteren Studenten erhalten, die an dem Projekt beteiligt waren, aber alle Fehler oder Auslassungen sind meine. Wenn Sie einen von ihnen bemerken, kontaktieren Sie mich bitte und ich werde versuchen, sie zu beheben.

1. Einleitung

Postgres war das ehrgeizigste Projekt von Michael Stonebreaker - sein ernsthafter Versuch, ein universelles Datenbanksystem zu schaffen. Seit einem Jahrzehnt hat das Projekt mehr Artikel, Doktoranden, Professoren und Unternehmen hervorgebracht als jede andere Stonebreaker-Aktivität. Das Projekt deckte auch mehr technische Bereiche ab als jedes andere System, das er baute. Trotz des inhärenten Risikos dieser Größenordnung wurde Postgres auch das erfolgreichste Software-Artefakt, das aus den Forschungsteams von Stonebreaker hervorging, und sein Hauptbeitrag zu Open Source. Dies ist ein Beispiel für ein erfolgreiches „zweites System“ [ Bro75 ]. Zum Zeitpunkt des Schreibens, mehr als 30 Jahre seit Beginn des Projekts, ist das Open-Source-PostgreSQL-System das weltweit beliebteste unabhängige Open-Source-Datenbanksystem und das viertbeliebteste Datenbanksystem. Unternehmen, die aus Postgres gegründet wurden, erwirtschafteten insgesamt mehr als 2,6 Milliarden US-Dollar (Anschaffungskosten). In jeder Hinsicht hatte die Vision des Postgres Stonebreaker eine enorme anhaltende Resonanz.

1.1. Hintergrund

Stonebreaker war zu Beginn seiner Karriere ein großer Erfolg mit dem Forschungsprojekt Ingres Berkeley [ SHWK76 ] und dem anschließenden Startup, das er zusammen mit Larry Rowe und Eugene Wong gründete: Relational Technology, Inc. (RTI).

Als sich RTI in den frühen 1980er Jahren entwickelte, begann Stonebreaker mit der Unterstützung von Datentypen in DBMS, die über die traditionellen Zeilen und Spalten des ursprünglichen relationalen Codd-Modells (Edgar Frank Codd) hinausgingen. Ein motivierendes Beispiel war zu dieser Zeit die Notwendigkeit von Datenbanken zur Unterstützung von CAD-Werkzeugen (Computer Aided Design) für die mikroelektronische Industrie. In einem Artikel von Stonebreaker und Studenten aus dem Jahr 1983 erklärten Brad Rubenstein und Antonin Guttman, wie viel diese Branche benötigt, um „neue Datentypen wie Polygone, Rechtecke, Textzeichenfolgen usw.“ zu unterstützen. effektive räumliche Suche “,„ komplexe Integritätsbeschränkungen “sowie„ Entwurfshierarchien und Mehrfachdarstellungen “in denselben physischen Strukturen [ SRG83 ]. Mit dieser Motivation begann die Gruppe mit der Indizierung (einschließlich der Verwendung von Guttman-R-Bäumen für die räumliche Indizierung [ Gut84 ]) und dem Hinzufügen abstrakter Datentypen (ADTs) zum relationalen Datenbanksystem. Zu dieser Zeit waren ADTs ein beliebtes neues Design von Programmiersprachen, das zuerst von Barbara Liskov, später Preisträgerin des Turing-Preises, eingeführt und von Lonely Rowe, einer neuen Mitarbeiterin bei Stonebreaker, in der Programmierung von Datenbankanwendungen untersucht wurde. Ein Artikel in einem SIGMOD-Datensatz von 1983 [ OFS83 ] Stonebreaker und die Studenten James Ong und Dennis Fogg beschreiben eine Studie dieses Konzepts in der Ingres-Erweiterung ADT-Ingres, die viele der untersuchten Präsentationskonzepte enthält tiefer und mit besserer Systemunterstützung in Postgres.

2. Postgres: allgemeine Informationen

Wie der Name schon sagt, ist Postgres Post-Ingres: ein System, das entwickelt wurde, um das, was Ingres tun könnte, zu nutzen und darüber hinauszugehen. Eine Besonderheit von Postgres war die Einführung der letztendlich objektrelationalen Eigenschaften der Datenbank: Unterstützung des Konzepts der objektorientierten Programmierung im Datenmodell und der deklarativen Abfragesprache des Datenbanksystems. Stonebreaker plante jedoch auch, eine Reihe anderer technologischer Probleme unabhängig von der objektorientierten Unterstützung in Postgres zu lösen, z. B. aktive Datenbankregeln, versionierte Daten, tertiärer Speicher und Parallelität.

Zwei Artikel wurden über das Design von Postgres geschrieben: eine Beschreibung des frühen Designs von 1986 SIGMOD [ SR86 ] und eine Zwischenbeschreibung in CACM 1991 [ SK91 ]. Das Postgres-Forschungsprojekt wurde 1992 mit der Gründung von Illustra, einem Startup-Startup, an dem Stonebreaker, der leitende Doktorand Wei Hong und später Chefprogrammierer Jeff Meredith beteiligt waren, nach und nach zunichte gemacht. In der folgenden Liste sind die im Artikel von 1986 genannten Gelegenheiten mit einem Sternchen * gekennzeichnet, und die Gelegenheiten aus dem Artikel von 1991, die nicht im Artikel von 1986 enthalten waren, sind mit einem Dolch ^{† gekennzeichnet} . Die anderen unten aufgeführten Aufgaben wurden in der System- und Forschungsliteratur übernommen, sind jedoch in keiner Entwurfsspezifikation enthalten. Viele dieser Themen wurden bei Postgres behandelt, lange bevor sie von anderen untersucht oder neu erfunden wurden. In vielen Fällen war Postgres seiner Zeit zu weit voraus, und das Interesse an Themen stieg aus einer modernen Perspektive später an.

ADT-Unterstützung im Datenbanksystem
- Komplexe Objekte (d. H. Verschachtelte Daten oder nicht erste normale Formulardaten (nicht erste normale Form - NF2)) *
- Benutzerdefinierte abstrakte Datentypen und Funktionen *
- Erweiterbare Zugriffsmethoden für neue Datentypen *
- Optimierte Abfrageverarbeitung mit kostspieligen benutzerdefinierten Funktionen
Aktive Datenbanken und Regelsysteme (Trigger, Warnungen) *
- Regeln, die als Umschreiben von Anforderungen implementiert wurden ^†
- Regeln, die als Trigger für die Aufnahmeebene implementiert wurden ^†
Protokollbasierte Speicherung und Wiederherstellung
- Wiederherstellungscode mit reduzierter Komplexität, der das Protokoll als Daten * behandelt und nichtflüchtigen Speicher für den Festschreibungsstatus verwendet ^†
- Nicht umgeschriebener Speicher und zeitliche Abfragen ^†
Unterstützung für neue Deep-Storage-Technologien, insbesondere optische Festplatten *
Unterstützung für Multiprozessoren und spezialisierte Prozessoren *
Unterstützung für verschiedene Sprachmodelle
- Minimale Änderungen am relationalen Modell und Unterstützung für deklarative Abfragen *
- Zugriff auf den „Fast Track“ über interne APIs unter Umgehung der Abfragesprache ^†
- Mehrsprachigkeit ^†

Wir werden kurz den Beitrag von Postgres für jeden dieser Punkte in Bezug auf spätere Arbeiten auf dem Gebiet der Datenverarbeitung diskutieren.

2.1. ADT-Unterstützung im Datenbanksystem

Das klare Ziel von Postgres bestand darin, neue objektrelationale Eigenschaften zu unterstützen: Erweiterung der Datenbanktechnologie, um die Vorteile sowohl der relationalen Abfrageverarbeitung als auch der objektorientierten Programmierung zu nutzen. Im Laufe der Zeit wurde das objektrelationale Konzept, das erstmals in Postgres erschien, zur Standardfunktionalität in den meisten modernen Datenbanksystemen.

2.1.1. Komplexe Objekte

Sehr oft werden Daten als verschachtelte Entitäten oder „Objekte“ dargestellt. Ein klassisches Beispiel ist eine Bestellung, in die eine Reihe von Produkten, deren Mengen und Preise eingebettet sind. Die Religion der relationalen Modellierung schrieb vor, dass solche Daten in einem Format ohne Verschachtelung umstrukturiert und gespeichert werden sollten, wobei mehrere flache Objekttabellen (Bestellungen, Produkte) mit verbindenden flachen Beziehungstabellen (product_in_order) verwendet wurden. Ein typischer Grund für diese Abflachung ist die Verringerung der Datenverdoppelung (da das Produkt in vielen Bestellungen redundant beschrieben wird), wodurch die Komplexität oder Fehler beim Aktualisieren aller redundanten Kopien vermieden werden. In einigen Fällen möchten Sie jedoch die Unteransicht beibehalten, da dies für die Anwendung selbstverständlich ist (z. B. der Layoutmechanismus der Schaltung in CAD) und Aktualisierungen selten sind. Diese Debatte über Datenmodellierung ist mindestens so alt wie das relationale Modell.

Der Hauptansatz von Postgres bestand darin, in Bezug auf die Datenmodellierung auf zwei Stühlen zu sitzen: Postgres speicherte Tabellen als den „externesten“ Datentyp, erlaubte jedoch Spalten, „komplexe“ Typen zu haben, einschließlich verschachtelter Tupel oder Tabellen. Eine der weniger verbreiteten Implementierungen, die erstmals im ADT-Ingres-Prototyp untersucht wurde, bestand darin, die deklarative Deklaration einer Tabellentypspalte als Abfragedefinition zu ermöglichen: "Quel als Datentyp" [ SAHR84 ] (Quel - Ingres Query Language - Ca. .) .

Das „postrelationale“ Thema der Unterstützung sowohl für deklarative Abfragen als auch für eingebettete Daten ist im Laufe der Jahre wieder aufgetaucht, häufig durch Streitigkeiten darüber, welche besser sind. Während der Zeit von Postgres in den 1980er und 1990er Jahren haben einige Gruppen, die an objektorientierten Datenbanken beteiligt waren, diese Idee aufgegriffen und zur Standard-OQL-Sprache weiterentwickelt, die dann nicht mehr verwendet wurde.

Um die Jahrtausendwende wurden deklarative Abfragen zu verschachtelten Objekten zu einer Besessenheit der Forschung für das Segment der Community von Datenbankentwicklern in Form von XML-Datenbanken. Die resultierende XQuery-Sprache (angeführt von Don Chamberlin, der Person von SQL) ist erforderlich, um komplexe Objekte in der Postgel-Sprache von Postgres zu unterstützen. XQuery ist in der Industrie weit verbreitet und weit verbreitet, war jedoch bei Benutzern noch nie beliebt. Heute werden diese Konzepte in Abfragesprachenprojekten für das in Browseranwendungen beliebte JSON-Datenmodell erneut untersucht. Wie bei OQL treten diese Sprachen in Gruppen, die zunächst deklarative Abfragen zugunsten einer entwicklerorientierten Programmierung ablehnten (die „NoSQL“ -Bewegung), häufig als späte Ergänzung nur aus dem Wunsch heraus auf, dem System wieder Abfragen hinzuzufügen. Zur gleichen Zeit, als Postgres im Laufe der Jahre wuchs (und von der Postquel-Abfragesprache zu SQL-Versionen wechselte, die viele der betrachteten Ziele erfüllen), wurde eingebettete Daten wie XML und JSON in Allzweck-DBMS unterstützt, ohne dass dies erforderlich war oder signifikante Neugestaltung. Kontroversen laufen mit unterschiedlichem Erfolg, und der Ansatz von Postgres, die relationale Struktur mithilfe von Erweiterungen für verschachtelte Daten zu erweitern, hat sich nach dem Abklingen der Argumente wiederholt als natürlicher Endzustand für alle Parteien erwiesen.

2.1.2. Benutzerdefinierte abstrakte Datentypen und Funktionen

Postgres schlug nicht nur verschachtelte Typen vor, sondern brachte auch die Idee vor, undurchsichtige, erweiterbare ADTs einzuführen, die in der Datenbank gespeichert, aber vom Kernel nicht interpretiert werden. Grundsätzlich war dies immer Teil des relationalen Modells von Codd: Ganzzahlen und Zeichenfolgen waren traditionell, aber tatsächlich umfasst das relationale Modell jeden atomaren Datentyp mit Prädikaten. Die Aufgabe bestand darin, eine solche mathematische Flexibilität in der Software bereitzustellen. Um Abfragen zu verwenden, die diese Objekte interpretieren und bearbeiten, muss ein Anwendungsprogrammierer in der Lage sein, benutzerdefinierte Funktionen (UDFs) für diese Typen im System zu registrieren und diese Funktionen in Abfragen aufzurufen. Es ist auch wünschenswert, dass benutzerdefinierte Aggregatfunktionen (UDA) die Sammlungen dieser Objekte in Abfragen zusammenfassen. Das Postgres-Datenbanksystem war innovativ und unterstützte diese Funktionen umfassend.

Warum sollten solche Funktionen in ein DBMS und nicht in Anwendungen auf hoher Ebene integriert werden? Die typische Antwort auf diese Frage war ein wesentlicher Vorteil für die Leistung des auf den Daten platzierten Codes gegenüber dem „Ziehen“ der Daten in den Code. Postgres hat gezeigt, dass dies in einer relationalen Umgebung ganz natürlich ist: Im relationalen Metadatenkatalog waren nur geringfügige Änderungen erforderlich, und es wurden Code-Aufrufmechanismen von Drittanbietern erstellt, aber die Abfragesyntax, die Semantik und die Systemarchitektur funktionierten einfach und elegant.

Postgres ist seiner Zeit bei der Erforschung dieser Funktionalität etwas voraus. Zu dieser Zeit war die Datenbankforschungsgemeinschaft insbesondere nicht besonders besorgt über die Sicherheitsauswirkungen des Herunterladens von unsicherem Code auf den Server. Dies wurde als Problem wahrgenommen, als die Technologie in der Branche wahrgenommen wurde. Stonebreaker brachte Postgres in seinem Startup Illustra auf den Markt, das Informix in hohem Maße für seine Fähigkeit zur Unterstützung von DataBlade-Erweiterungspaketen, einschließlich UDF, erworben hat. Informix ist mit seiner Postgres-basierten Technologie und seinem starken Angebot an parallelen Datenbanken zu einer erheblichen Bedrohung für Oracle geworden. Oracle hat stark in die negative Vermarktung der Risiken investiert, die mit der Fähigkeit von Informix verbunden sind, "unsicheren" Benutzer-C-Code auszuführen. Einige führen den Tod von Informix auf diese Kampagne zurück, obwohl der Finanzbetrug von Informix (und die anschließende Strafverfolgung des damaligen CEO durch den Bund) sicherlich schwerwiegendere Probleme aufwirft. Jetzt, Jahrzehnte später, unterstützen alle großen Datenbankanbieter benutzerdefinierte Funktionen in einer oder mehreren Sprachen und verwenden neue Technologien, um sich vor Serverabstürzen oder Datenkorruption zu schützen.

Die Technologie-Stacks der Big Data der 2000er Jahre, einschließlich des MapReduce-Phänomens, das Stonebreaker und David DeWitt [ DS08 ] „viel Blut verdorben“ hat, sind eine Neuimplementierung der Idee von Postgres - Benutzercode, der in die Anfrage aufgenommen wurde. Es scheint, dass MapReduce Postgres-Softwareentwicklungsideen weitgehend mit Parallelitätsideen von Systemen wie Gamma und Teradata kombiniert, mit einigen geringfügigen Neuerungen beim Neustart des Abfrageprozesses für Workloads mit extremer Skalierbarkeit. Startups, die auf Postgres, Greenplum und Aster basierten, zeigten um 2007, dass die Parallelisierung von Postgres für die meisten Kunden zu etwas viel Funktionalerem und Praktischerem als MapReduce führen kann, aber 2008 war der Markt noch nicht für diese Technologie bereit. . Mittlerweile, im Jahr 2018, verarbeitet fast jeder Big-Data-Stack im Wesentlichen die parallele SQL-Workload mit UDF, was dem Design sehr ähnlich ist, das Stonebreaker und das Team erstmals in Postgres verwendet haben.

2.1.3. Erweiterbare Zugriffsmethoden für neue Datentypen

Relationale Datenbanken wurden ungefähr zur gleichen Zeit wie B-Bäume in den frühen 1970er Jahren entwickelt, und B-Bäume gaben Codd einen Traum von „Unabhängigkeit von der physischen Datenspeicherung“: Die Indizierung mit B-Bäumen bietet eine Indirektionsebene, die Reorganisiert den physischen Speicher adaptiv, ohne dass Anwendungsänderungen erforderlich sind. Die Hauptbeschränkung von B-Bäumen und den damit verbundenen Strukturen bestand darin, dass sie nur Gleichheitssuche und Abfragen im eindimensionalen Bereich unterstützen. Was aber, wenn Sie zweidimensionale Bereichsabfragen haben, die für Mapping- und CAD-Anwendungen typisch sind? Dieses Problem war bei Postgres bekannt, und der von Antonin Guttman in der Stonebreaker-Gruppe entwickelte R-Baum [ Gut84 ] war einer der erfolgreichsten neuen Indizes, mit denen dieses Problem in der Praxis gelöst werden konnte. Die Erfindung der Indexstruktur löst jedoch nicht das Problem der Unterstützung mehrdimensionaler Bereiche in einem DBMS für komplexe Systeme. Es gibt viele Fragen. Können Sie Ihrem DBMS problemlos eine Zugriffsmethode wie R-Bäume hinzufügen? Können Sie dem Optimierer beibringen, zu verstehen, dass die angegebene Zugriffsmethode für bestimmte Abfragen nützlich ist? Können Sie eine korrekte Wiederherstellung und gleichzeitigen Zugriff erreichen? Dies war ein sehr kühner Punkt im Postgres-Aktionsplan: Ein Problem mit der Softwarearchitektur, das den größten Teil des Datenbankmoduls betrifft, vom Optimierer über die Speicherebene bis hin zum Journal- und Wiederherstellungssystem. Postgres-R-Bäume sind zu einer starken treibenden Kraft geworden und ein Paradebeispiel für die elegante Erweiterbarkeit der Zugriffsmethodenschicht und ihre Integration in den Abfrageoptimierer. Postgres zeigte mit einem undurchsichtigen ADT, wie eine abstrakt beschriebene Zugriffsmethode (in diesem Fall ein R-Baum) registriert wird und wie ein Abfrageoptimierer ein abstraktes Auswahlprädikat (in diesem Fall eine Bereichsauswahl) erkennen und mit dieser abstrakt beschriebenen Zugriffsmethode abgleichen kann. Bei der ersten Arbeit wurde der gleichzeitigen Zugangskontrolle weniger Aufmerksamkeit geschenkt: Das Fehlen einer eindimensionalen Reihenfolge der Schlüssel machte das in B-Bäumen verwendete Schloss in diesem Fall nicht anwendbar.

Die vielversprechenden Eigenschaften der erweiterbaren Zugriffsmethoden von Postgres inspirierten eines meiner ersten Forschungsprojekte am Ende der Graduiertenschule: Generalisierte Suchbäume - GiST [ HNP95 ] und das nachfolgende Konzept der Indizierungstheorie [ HKM ⁺ 02 ]. Nach meiner Promotion habe ich GiST für ein Semester in Postgres implementiert, was das Hinzufügen der neuen Indexierungslogik zu Postgres noch einfacher machte. Die Dissertation von Marcel Kornacker aus Berkeley (Marcel Kornacker) löste die komplexen Probleme der Wiederherstellung und des gleichzeitigen Zugriffs, die sich aus dem erweiterbaren "Template" -Typ des Index GiST [ KMH97 ] ergeben.

Heute kombiniert PostgreSQL die ursprüngliche Softwarearchitektur erweiterbarer Zugriffsmethoden (mit B-Tree-, GiST-, SP-GiST- und Gin-Indizes) auf vorteilhafte Weise mit der Erweiterbarkeit und dem intensiven Wettbewerbszugriff der Generalized Search Tree Interface (GiST). GiST-Indizes unterstützen das beliebte PostGIS-Geoinformationssystem, das auf PostgreSQL basiert. Gin-Indizes bieten Unterstützung für die interne Textindizierung in PostgreSQL.

2.1.4. Abfrageoptimierer mit teuren UDFs

Bei der herkömmlichen Abfrageoptimierung bestand die Aufgabe darin, die Menge des Tupelstroms (und damit der E / A-Operationen) zu minimieren, die bei der Verarbeitung der Anforderung erstellt wurden. Dies bedeutete, dass Anweisungen, die Tupel filtern (abrufen), zu Beginn des Abfrageplans gut sind, während Anweisungen, die neue Tupel generieren (verbinden), später ausgeführt werden müssen. Infolgedessen "pushen" Abfrageoptimierer die Abrufoperatoren unter die Verbindungen und ordnen sie zufällig an, wobei sie sich stattdessen auf die clevere Optimierung von Verbindungen und Festplattenzugriffen konzentrieren. UDFs haben den Ansatz geändert: Wenn Ihre Beispielanweisungen teure UDFs enthalten, kann die Ausführungsreihenfolge der UDFs für die Optimierung der Leistung von entscheidender Bedeutung sein. Wenn die UDF im Auswahloperator wirklich viel Zeit in Anspruch nimmt, ist es außerdem möglich, dass die Auswahl nach den Verbindungen durchgeführt wird (dh die Auswahl sollte "Pull-up" - Auswahl "Pull-up" sein). Die Berücksichtigung dieser Faktoren hat den Suchraum für den Optimierer kompliziert. Ich nahm dieses Problem als die erste schwierige Aufgabe in der Graduiertenschule und es war schließlich Gegenstand meiner Masterarbeit bei Stonebreaker in Berkeley und meiner Promotion in Wisconsin unter der Leitung von Jeff Naughton, aber mit der ständigen Hilfe von Stonebreaker. Postgres war das erste DBMS, das die Kosten und die Selektivität benutzerdefinierter Funktionen in einem Datenbankverzeichnis speicherte. Wir näherten uns dem Optimierungsproblem, nachdem wir die optimale Reihenfolge der Abtastoperationen und dann die optimale Abwechslung der Abtastoperationen entlang der Zweige jedes Verbindungsbaums gefunden hatten, die bei der Plansuche berücksichtigt wurden. System R .

, , . , , .

PostgreSQL , . , , , , 2018 . , , , , , . , Postgres .

, , , PostgreSQL (Neil Conway), « » .

2.2.

Postgres . : , « », 1990- .

. — Datalog. « » : , , .

Datalog , - . Datalog — « » . , , .

, , , , . .

(Eric Hanson), Ingres, Postgres. (Spyros Potamianos) PRS2: Postgres Rules System 2. . — . , Ingres. « » « ». , « » « 10%». , « », . ( ), .

PRS2 , , . Postgres (, ) Postgres 3.1 1991 ( ):

 
*        :
*     .        
*  (. .        
* "" )    .   -  
*   () .        .
*   .    .     
*   .  ...
* ,  , ? ,    ,  .
*         , 
*  ...

Postgres , «» — . PostgreSQL, - .

Postgres « » IBM Starburst MCC HiPAC. SQL . . , , , , « »: , . , - , , , , . , , , , Postgres.

2.3. X

Postgres :

Postgres, - . (write-ahead log — WAL), , . , Ingres 1970- , . [ SK91 ]

, , . , IBM Tandem . : - , , , .

X Postgres . , , , — « » « » . , , — . , «» . : , . Postgres, , , , [ Sto87 ]. Postgres .

« » , , . . , , , , Postgres. Postgres . PostgreSQL .

, PostgreSQL : . , PostgreSQL , Postgres, , Postgres . , (snapshot isolation) Oracle -, .

(Mike Olson) , , B- Postgres B- Berkeley DB, Postgres. . Berkeley DB Sleepycat Corp., () PostgreSQL « ». : , (MVCC), , .

PostgreSQL . Greenplum PostgreSQL . (Matt McCline)— (Jim Gray) Tandem. .

. , NoSQL ( , WAL), (MMDB — main memory databases, ). , . , .

2.4.

Mitten im Postgres-Projekt hat sich Stonebreaker als einer der Führungskräfte für ein großes Stipendium für digitale Landwissenschaften namens Project Sequoia angemeldet. Ein Teil des Zuschussvorschlags war die Verarbeitung beispielloser Mengen digitaler Satellitenbilder, die bis zu 100 Terabyte Speicher benötigten, d. H. Eine viel größere Datenmenge, als es zu diesem Zeitpunkt sinnvoll wäre, sie auf Magnetplatten zu speichern. Die Grundlage der vorgeschlagenen Lösung bestand darin, die Idee der Erstellung eines DBMS (Postgres) zu untersuchen, das den Zugriff auf den halbautonomen „tertiären“ Speicher erleichtert, der von Roboterlaufwerken mit automatischem Plattenwechsel für die Verwaltung von optischen Platten- oder Bandbibliotheken bereitgestellt wird.

Dies führte zu verschiedenen Studien. Eines davon war das Inversion-Dateisystem - ein Versuch, eine Abstraktion des UNIX-Dateisystems über ein relationales DBMS bereitzustellen. In einem Übersichtsartikel für Sequoia beschrieb Stonebreaker dies in seiner üblichen Art, „einfache Übung“ zu bevormunden [ Sto95 ]. Tatsächlich ist Mike Olson, ein Student bei Stonebreaker (und der spätere Gründer von Cloudera), seit mehreren Jahren damit beschäftigt, und das Endergebnis war nicht sehr einfach [ Ols93 ] und überlebte in der Praxis nicht.

Einige Jahre später kämpfte Inversion Bill Gates in WinFS gegen „dieselben Windmühlen“ - ein Versuch, das weltweit am häufigsten verwendete Dateisystem über das Back-End einer relationalen Datenbank wiederherzustellen. WinFS wurde in Entwicklungsversionen von Windows ausgeliefert, kam jedoch nie auf den Markt. Gates nannte es später seine größte Enttäuschung bei Microsoft.

Ein weiterer Forschungsschwerpunkt auf diesem Gebiet war die Aufnahme eines tertiären Repositorys in den Stapel typischerer relationaler Datenbanken, der Gegenstand einer Doktorarbeit von Sunita Sarawagi war. Das Hauptthema bestand darin, den Maßstab zu ändern, in dem Sie Speicherplatz (d. H. Daten im Speicher und die Hierarchie des Speichers) und Zeit (Koordination der Abfrageplanung und des Cache zur Minimierung unerwünschter E / A) verwalten möchten. Eines der Hauptprobleme in dieser Arbeit bestand darin, große mehrdimensionale Arrays in einem Tertiärspeicher zu speichern und abzurufen, was die Arbeit auf dem Gebiet der mehrdimensionalen Indizierung widerspiegelt. Zu den Schlüsselideen gehörten das Teilen des Arrays in Teile und das Zusammenspeichern der Teile, die zusammen ausgewählt wurden, sowie das Replizieren der Teile, so dass der Datenteil mehrere physische „Nachbarn“ haben kann. Das zweite Problem besteht darin, darüber nachzudenken, wie die Festplatte zu einem Cache für den tertiären Speicher wird. Schließlich sollten bei der Abfrageoptimierung und -planung die lange Ladezeit von Daten aus dem Tertiärspeicher und die Bedeutung von Treffern (Treffern) des Plattencaches berücksichtigt werden. Dies wirkt sich sowohl auf den vom Abfrageoptimierer ausgewählten Plan als auch auf die Zeit aus, die zum Abschließen des Plans erforderlich ist.

Roboter auf Bändern und optischen Discs sind derzeit nicht weit verbreitet. Tertiäre Speicherprobleme sind jedoch in der Cloud sehr häufig, die 2018 eine tiefe Speicherhierarchie aufweist: von angeschlossenen SSDs über zuverlässige festplattenähnliche Speicherdienste (z. B. AWS EBS) bis hin zu Archivspeicher (z. B. in AWS S3) und Deep Storage (z. B.) , AWS-Gletscher). Diese Speicherebenen sind heute noch relativ getrennt, und Überlegungen zur End-to-End-Speicherung, die diese Ebenen umfasst, werden von der Datenbank praktisch nicht unterstützt. Es würde mich nicht wundern, wenn die an dieser Front in Postgres untersuchten Fragen bald überprüft werden.

2.5. Multiprozessor-Unterstützung: XPRS

Stonebreaker hat nie ein großes paralleles Datenbanksystem erstellt, aber er hat viele herausfordernde Diskussionen in diesem Bereich geführt. Sein Artikel „Case for Shared Nothing“ [ Sto86 ] dokumentierte großmodulare Architekturlösungen in diesem Bereich. Er popularisierte die in der Branche verwendete Terminologie und verwirrte die Unterstützung von Architekturen ohne gemeinsame Ressourcen wie Gamma und Teradata, die in den 2000er Jahren von der Big-Data-Community wiederentdeckt wurden.

Ironischerweise war Stonebreakers wichtigster Beitrag auf dem Gebiet der parallelen Datenbanken die "Shared Memory" -Architektur namens XPRS, was "eXtended Postgres on RAID and Sprite" bedeutete. In den frühen neunziger Jahren war XPRS die „Liga der Gerechtigkeit“ für Berkeley-Systeme: Es kombiniert das abgekürzte Postgres Stonebreaker-System, John Ousterhout, das verteilte Sprite-Betriebssystem sowie die RAID-Architektur von Dave Patterson und Randy Katz ) Wie bei vielen fakultätsübergreifenden Jobs wurde die Umsetzung des XPRS-Projekts tatsächlich von den Doktoranden bestimmt, die daran gearbeitet haben. Es stellte sich heraus, dass der Hauptbeitrag von Wei Hong geleistet wurde, der seine Doktorarbeit über die Optimierung paralleler Abfragen in XPRS verfasste. Daher bestand der Hauptbeitrag von XPRS zur Literatur und Industrie darin, gleichzeitige Anforderungen zu optimieren, ohne die mit RAID oder Sprite verbundenen Probleme wesentlich anzugehen.

Von diesen drei Projekten hatten Postgres und RAID einen großen Einfluss auf die Zukunft. Sprite wird am besten von Mendel Rosenblums Dissertation über log strukturierte Dateisysteme (LFS) in Erinnerung behalten, die nichts Bemerkenswertes mit verteilten Betriebssystemen zu tun hatte. Alle drei Projekte enthielten neben der Änderung einzelner Kopien neue Ideen für die Speicherung von Datenträgern. LFS und der Postgres-Repository-Manager sind sich in ihrer neuen Behandlung des Journals als primäres Repository und der Notwendigkeit einer kostspieligen Hintergrundreorganisation ziemlich ähnlich. Einmal habe ich den Steinbrecher sorgfältig nach der Rivalität zwischen LFS und Postgres oder den akademischen "gebratenen Fakten" über ihre Beziehung untersucht, aber ich habe nie etwas Interessantes von ihm gelernt. Vielleicht rührte damals in Berkeley jemand "Wasser auf".

Im Prinzip "explodiert" die Parallelität den Raum der Abfrageoptimierungspläne und multipliziert die traditionellen Entscheidungen, die während der Abfrageoptimierung getroffen wurden (Datenzugriff, Verbindungsalgorithmen, Verbindungsreihenfolge), mit allen möglichen Möglichkeiten zur Parallelisierung jeder Auswahl. Die Hauptidee des von Stonebreaker aufgerufenen „Wei Hong-Optimierers“ bestand darin, das Problem in zwei Teile aufzuteilen: Starten Sie den herkömmlichen Abfrageoptimierer im Geiste von System R für einen Knoten und „parallelisieren“ Sie den resultierenden Plan, indem Sie den Grad der Parallelität und Platzierung jedes Operators basierend auf der Darstellung planen Daten- und Systemkonfiguration. Dieser Ansatz ist heuristisch, aber gleichzeitig erhöht die Parallelität die Kosten der herkömmlichen Abfrageoptimierung eher additiv als multiplikativ.

Obwohl der Optimierer von Wei Hong im Kontext von Postgres entwickelt wurde, ist er zum Standardansatz für viele Optimierer für gleichzeitige Abfragen in der Branche geworden.

2.6. Unterstützung für verschiedene Sprachmodelle

Zu den Interessen von Stonebreaker, die seit Ingres wiederholt erneuert wurden, gehörte die API (Application System Programming Interface) des Datenbanksystems. In seinen Vorlesungen in der Reihe "Datenbanksysteme" bezog er häufig die GEM-Sprache Carlo Zaniolo als ein Thema ein, das für Befürworter von Datenbanksystemen wichtig ist. Dieses Interesse an der Sprache führte ihn zweifellos zu einer Partnerschaft mit Larry Rowe in Postgres, was wiederum das Design des Postgres-Datenmodells und seinen objektrelationalen Ansatz stark beeinflusste. Ihre Arbeit konzentrierte sich hauptsächlich auf Anwendungen für die Arbeit mit einem großen Datenvolumen aus dem kommerziellen Bereich, einschließlich der Verarbeitung von Geschäftsinformationen und neuer Anwendungen wie CAD / CAM und GIS.

Eines der Probleme, die Stonebreaker zu dieser Zeit auferlegt wurden, war die Idee, die Grenzen zwischen den Programmiersprachenkonstrukten und dem Datenbank-Repository zu „verbergen“. Verschiedene konkurrierende Forschungsprojekte und Unternehmen, die objektorientierte Datenbanken (OODBs) erforschen, haben den sogenannten „Konformitätsverlust“ zwischen imperativen objektorientierten Programmiersprachen wie Smalltalk, C ++ und Java und deklarativen relationalen Daten zum Ziel Modell. Die Idee von OODB war es, die Objekte der Programmiersprache auf Wunsch als "permanent" zu markieren und vom eingebauten DBMS automatisch zu verarbeiten. Postgres unterstützte die Speicherung verschachtelter Objekte und abstrakter Datentypen, aber seine Schnittstelle, die auf deklarativen Abfragen in einem relationalen Stil basierte, nahm für den Programmierer einen unnatürlichen Zugriff auf die Datenbank an (es erforderte die Verwendung deklarativer Abfragen), die ebenfalls teuer waren (Parsing und Optimierung). Um mit OODB-Anbietern zu konkurrieren, stellte Postgres die sogenannte Fast Path-Schnittstelle zur Verfügung: im Wesentlichen die C / C ++ - API für die interne Datenbankspeicherung. Dies ermöglichte es Postgres, eine durchschnittliche Leistung im akademischen OODB-Benchmark zu erzielen, löste jedoch nie das Problem, dass Programmierer in verschiedenen Sprachen das Problem des Verlusts der Compliance vermeiden konnten. Stattdessen bezeichnete Stonebreaker Postgres als „objektrelationales“ Label und umging einfach die Verwendung objektorientierter Datenbanken als Null-Milliarden-Dollar-Markt. Heutzutage sind fast alle kommerziellen relationalen Datenbanksysteme "objektrelationale" Datenbanksysteme.

Dies stellte sich als vernünftige Lösung heraus. Heute existiert keines der OODB-Produkte in seiner beabsichtigten Form, und die Idee von "persistenten Objekten" in Programmiersprachen wurde weitgehend verworfen. Im Gegensatz dazu ist die Verwendung von ORM-Ebenen (Object Relational Mapping) weit verbreitet, was auf frühe Arbeiten wie Java Hibernate und Ruby on Rails zurückzuführen ist, die es ermöglichen, deklarative Datenbanken relativ reibungslos an nahezu jedes zwingende Objekt anzupassen. -orientierte Programmiersprache als Bibliotheken. Dieser Ansatz auf Anwendungsebene unterscheidet sich sowohl von objektrelationalen OODB- als auch von Stonebreaker-Datenbanken. Darüber hinaus werden leichte Schlüsselwertspeicher sowohl in nicht-transaktionaler als auch in transaktionaler Form erfolgreich eingesetzt. Ihre Entdeckerin war die Stonebreaker-Doktorandin Margo Seltzer, die im Rahmen ihrer Doktorarbeit gleichzeitig mit der Postgres-Gruppe an der Berkeley DB-Datenbank arbeitete und das Wachstum verteilter NoSQL-Schlüsselwert-Repositories wie Dynamo vorwegnahm , MongoDB und Cassandra.

3. Auswirkungen auf die Software

3.1. Open Source

Postgres war schon immer ein Open-Source-Projekt mit konsistenten Veröffentlichungen, aber am Anfang sollte es eher für die Forschung als für die Produktion verwendet werden.

Als das Postgres-Forschungsprojekt eingeschränkt wurde, modifizierten zwei Stonebreaker-Studenten, Andrew Yu und Jolly Chen, den Systemparser, um die ursprüngliche Postquel-Sprache durch eine erweiterbare SQL-Variante zu ersetzen. Die erste Postgres-Version, die SQL unterstützt, war Postgres95, und die nächste hieß PostgreSQL.

Ein Open-Source-Entwicklungsteam interessierte sich für PostgreSQL und „akzeptierte“ es, obwohl sich die Interessen des restlichen Berkeley-Teams änderten. Das PostgreSQL-Kernteam ist im Laufe der Zeit relativ stabil geblieben, und das Open Source-Projekt hat sich stark entwickelt. Ursprünglich konzentrierten sich die Bemühungen auf die Stabilität des Codes und der Funktionalität, die für den Benutzer sichtbar sind. Im Laufe der Zeit hat die Open-Source-Software-Community den Kern des Systems erheblich verändert und verbessert, vom Optimierer über die Zugriffsmethoden bis hin zum Haupttransaktions- und Speichersystem. Seit Mitte der neunziger Jahre stammte ein sehr kleiner Teil der internen Komponenten von PostgreSQL aus dem akademischen Team von Berkeley. Ihr letzter Beitrag mag meine Implementierung von GiST in der zweiten Hälfte der neunziger Jahre gewesen sein, aber selbst er wurde von Freiwilligen aus der Open-Source-Community (in diesem Fall Russland) grundlegend umgeschrieben und freigegeben. Der Teil der Open Source-Community, der an PostgreSQL arbeitet, verdient das größte Lob für seinen optimierten Prozess, der seit Jahrzehnten dazu dient, ein hocheffizientes und langfristiges Projekt zu erstellen.

Obwohl sich in 25 Jahren viel geändert hat, ist die zugrunde liegende PostgreSQL-Architektur den Veröffentlichungen der Postgres-Universität in den frühen neunziger Jahren sehr ähnlich, und Entwickler, die mit dem aktuellen PostgreSQL-Quellcode vertraut sind, werden es leicht finden, den Postgres 3.1-Quellcode (1991) zu lesen. Alles von der Quellcode-Verzeichnisstruktur bis zu den Prozessstrukturen und Datenstrukturen bleibt überraschend ähnlich. Der Code des Postgres-Teams in Berkeley hatte ein großartiges Rückgrat.

Heute ist PostgreSQL ohne Zweifel das leistungsstärkste Open-Source-Datenbankverwaltungssystem und unterstützt Funktionen, die in kommerziellen Produkten häufig nicht zu finden sind. Es ist auch (laut einer einflussreichen Bewertungsseite) das beliebteste unabhängige Open-Source-DBMS der Welt, und sein Einfluss wächst weiter: In den Jahren 2017 und 2018 war es die Datenbank mit der am schnellsten wachsenden Popularität der Welt [ DE19c ]. PostgreSQL wird in einer Vielzahl von Branchen und Aufgaben eingesetzt, was angesichts des Fokus auf zahlreiche Möglichkeiten nicht überraschend ist.

Laut DB-Engines ist PostgreSQL heute nach Oracle, MySQL und MS SQL Server die viertbeliebteste Datenbank der Welt, die alle drei von bestimmten Unternehmen angeboten werden (MySQL wurde vor vielen Jahren von Oracle übernommen) [ DE19a ]. Die Ranking-Regeln werden in der Beschreibung der Ranking-Methodik DB-Engines [ DE19b ] diskutiert .

Heroku ist der SaaS-Cloud-Anbieter, der jetzt Teil von Salesforce ist. Postgres wurde 2010 in Heroku als Standarddatenbank für seine Plattform eingeführt. Heroku entschied sich aus Gründen der Zuverlässigkeit für Postgres. Mit Heroku-Unterstützung empfahlen größere Anwendungsentwicklungsplattformen wie Ruby on Rails und Python for Django Postgres als Standarddatenbank.

Heute unterstützt PostgreSQL eine Erweiterungsinfrastruktur, die es einfach macht, dem System zusätzliche Funktionen durch benutzerdefinierte Funktionen und damit verbundene Änderungen hinzuzufügen. Jetzt gibt es ein Ökosystem von PostgreSQL-Erweiterungen, ähnlich dem llustra-Konzept von DataBlade-Erweiterungspaketen, jedoch mit Open Source-Code. Zu den interessantesten Erweiterungen gehören beispielsweise die Apache MADlib-Bibliothek für maschinelles Lernen in der SQL-Schnittstelle und die Citus-Bibliothek für die parallele Ausführung von Abfragen.

Eine der interessantesten Open-Source-Anwendungen, die auf Postgres basieren, ist das geografische PostGIS-Informationssystem, das viele der Postgres-Funktionen verwendet, die Stonebreaker ursprünglich zum Start des Projekts inspiriert haben.

3.2. Kommerzielle Implementierung

PostgreSQL ist seit langem ein attraktiver Ausgangspunkt für die Erstellung kommerzieller Datenbanksysteme, da es unter der Open-Source-Softwarelizenz „Allzulässig“, zuverlässigem Code, Flexibilität und umfassender Funktionalität verwendet wird. Zusammenfassend sehen wir, dass Postgres Akquisitionskosten in Höhe von mehr als 2,6 Milliarden US-Dollar erhalten hat.

Bitte beachten Sie, dass dies ein Maß für reale Finanztransaktionen in US-Dollar ist und viel wichtiger ist als die Werte, die in der Hochtechnologie häufig verwendet werden. Zahlen in Milliarden werden häufig verwendet, um den geschätzten Wert von Aktienblöcken zu beschreiben, werden jedoch in der Hoffnung auf ihre zukünftige Bedeutung häufig um das Zehnfache oder mehr gegenüber dem Barwert überbewertet. Die Akquisitionstransaktionsdollar des Unternehmens messen den tatsächlichen Marktwert zum Zeitpunkt der Akquisition. Man kann mit Recht sagen, dass Postgres einen realen kommerziellen Wert von mehr als 2,6 Milliarden US-Dollar geschaffen hat.

Viele der mit PostgreSQL verbundenen kommerziellen Bemühungen haben sich auf die wahrscheinlich größte Einschränkung konzentriert: die Möglichkeit, auf eine parallele Architektur zu skalieren, ohne Ressourcen gemeinsam zu nutzen.

Die Parallelisierung von PostgreSQL erfordert eine Menge Arbeit, ist jedoch für ein kleines, erfahrenes Team sehr gut möglich. Heute bieten PostgreSQL-Open-Source-Branchen wie Greenplum und CitusDB eine solche Möglichkeit. Es ist bedauerlich, dass PostgreSQL in Open Source viel früher nicht richtig parallelisiert wurde. Wenn PostgreSQL in den frühen 2000er Jahren in Open Source mit Unterstützung für eine Architektur ohne gemeinsame Nutzung von Ressourcen erweitert worden wäre, hätte sich die Open Source-Richtung für Big Data möglicherweise auf eine völlig andere und effizientere Weise entwickelt.

Illustra war Stonebreakers zweitgrößtes Startup, das 1992 gegründet wurde, um Postgres zu kommerzialisieren, als RTI Ingres auf den Markt brachte.

Illustra war eigentlich der dritte Name, der für das Unternehmen vorgeschlagen wurde. Illustra setzte das Thema Malerei unter dem Namen Ingres fort und hieß ursprünglich Miro. Aufgrund von Markenproblemen wurde der Name in Montage geändert, es traten jedoch auch Markenprobleme auf.

Das Gründungsteam bestand aus einigen Mitgliedern des Postgres-Teams, darunter der jüngste Absolvent der Graduiertenschule Wei Hong und der damalige Senior-Programmierer Jeff Meredith sowie Absolventen der Ingres Paula Hawthorn und Michael Ubell. Der Postgres-Doktorand Mike Olson trat kurz nach der Gründung bei und ich arbeitete bei Illustra, um im Rahmen meiner Promotion teure Funktionen zu optimieren. Illustra : SQL92 , Postquel, Postgres DataBlade — . Illustra Informix 1997 400 . . [ Mon96 ], DataBlade Informix Informix Universal Server.
Netezza , 1999 , PostgreSQL FPGA. Netezza , 2007 . IBM 1,7 . . [ IBM10 ].
Greenplum PostgreSQL . 2003 , Greenplum PostgreSQL, API PostgreSQL, API . , Greenplum PostgreSQL , , Orca. Greenplum EMC 2010 300 . . [ Mal10 ], 2012 EMC Greenplum Pivotal. 2015 Pivotal Greenplum Orca . Greenplum Postgres API MADlib SQL [ HRS+12 ]. MADlib Apache. , Greenplum, Apache HAWQ, Pivotal, « » Greenplum (. . PostgreSQL) , Hadoop.
EnterpriseDB 2004 , PostgreSQL , . EnterpriseDB Advanced Server Oracle, Oracle.
Aster Data 2005 , . PostgreSQL. Aster , SQL MapReduce. Aster Data Teradata 2011 263 . . [ Sho11 ]. Teradata Aster , - Aster Teradata.
ParAccel 2006 , PostgreSQL . ParAccel Postgres . 2011 Amazon ParAccel, 2012 AWS Redshift — ParAccel. 2013 ParAccel Actian ( Ingres) , , Actian. AWS Redshift Amazon — Amazon, , , Teradata Oracle Exadata. Postgres .
CitusDB (CitusDB — ; Citus Data. — . .) 2010 , PostgreSQL . PostgreSQL, 2016 CitusDB API PostgreSQL PostgreSQL. 2016 CitusDB .

4.

Postgres, .

, , , Postgres « » (Second System Effect) (Fred Brooks) [ Bro75 ]. , , - . Postgres , , , . , , . — Postgres , . : , . , « » . , , . «-» , «-» .

, , « », , . ( 2001 (). — . .) 2000- « ». , Postgres. , , .

(Ralph Waldo Emerson), « — ».

, « » ( ), , , , , . , . , , - . , . , .

, Postgres, — , . « » PostgreSQL, , . , :

, , , 1995 . Postgres, , . , , , . [ Sto14 ]

, , , , « » . « ». , , , , Postgres. - , : « - ». ( ), .

5.

Postgres , , (Craig Kerstiens) PostgreSQL.

Literatur

[Bro75] Frederick P Brooks. The mythical man-month, 1975.
[Bro19] Michael L. Brodie, editor. Making Databases Work. Morgan & Claypool, 2019.
[DE19a] DB-Engines. DB-Engines ranking, 2019. db-engines.com/en/ranking . (Last accessed January 4, 2019).
[DE19b] DB-Engines. Method of calculating the scores of the DB-Engines ranking, 2019. db-engines.com/en/ranking_definition (Last accessed January 4, 2019).
[DE19c] DB-Engines. PostgreSQL is the DBMS of the year 2018, January 2019. db-engines.com/en/blog_post/79 (Last accessed January 4, 2019).
[DS08] David DeWitt and Michael Stonebraker. Mapreduce: A major step backwards. The Database Column, 1:23, 2008.
[Gut84] Antonin Guttman. R-trees: A dynamic index structure for spatial searching. In Proceedings of the 1984 ACM SIGMOD International Conference on Management of Data, SIGMOD '84, pages 47–57, New York, NY, USA, 1984. ACM.
[HKM ⁺ 02] Joseph M. Hellerstein, Elias Koutsoupias, Daniel P. Miranker, Christos H. Papadimitriou, and Vasilis Samoladas. On a model of indexability and its bounds for range queries. J. ACM, 49(1):35–55, January 2002.
[HNP95] Joseph M. Hellerstein, Jeffrey F. Naughton, and Avi Pfeffer. Generalized search trees for database systems. In Proceedings of the 21th International Conference on Very Large Data Bases, VLDB '95, pages 562–573, San Francisco, CA, USA, 1995. Morgan Kaufmann Publishers Inc.
[HRS ⁺ 12] Joseph M Hellerstein, Christoper Re, Florian Schoppmann, Daisy Zhe Wang, Eugene Fratkin, Aleksander Gorajek, Kee Siong Ng, Caleb Welton, Xixuan Feng, Kun Li, et al. The MADlib analytics library: or MAD skills, the SQL. Proceedings of the VLDB Endowment, 5(12):1700–1711, 2012.
[IBM10] IBM to acquire Netezza, September 2010. www-03.ibm.com/press/us/en/pressrelease/32514.wss#release (Last accessed January 22, 2018).
[KMH97] Marcel Kornacker, C. Mohan, and Joseph M. Hellerstein. Concurrency and recovery in generalized search trees. In Proceedings of the 1997 ACM SIGMOD International Conference on Management of Data, SIGMOD '97, pages 62–72, New York, NY, USA, 1997. ACM.
[Mal10] Om Malik. Big Data = Big Money: EMC Buys Greenplum. In GigaOm, July 2010. gigaom.com/2010/07/06/emc-buys-greenplum .
[Mon96] John Monroe. Informix acquires illustra for complex data management. In Federal Computer Week, January 1996.
[OFS83] James Ong, Dennis Fogg, and Michael Stonebraker. Implementation of data abstraction in the relational database system ingres. ACM Sigmod Record, 14(1):1–14, 1983.
[Ols93] Michael A. Olson. The design and implementation of the inversion file system. 1993.
[SAHR84] Michael Stonebraker, Erika Anderson, Eric Hanson, and Brad Rubenstein. Quel as a data type. In Proceedings of the 1984 ACM SIGMOD International Conference on Management of Data, SIGMOD '84, pages 208–214, New York, NY, USA, 1984. ACM.
[Sho11] Erick Shonfeld. Big pay day for big data. teradata buys aster data for $263 million. In TechCrunch, May 2011. techcrunch.com/2011/03/03/teradata-buys-aster-data-263-million (Last accessed January 22, 2018).
[SHWK76] Michael Stonebraker, Gerald Held, Eugene Wong, and Peter Kreps. The design and implementation of ingres. ACM Transactions on Database Systems (TODS), 1(3):189–222, 1976.
[SK91] Michael Stonebraker and Greg Kemnitz. The postgres next generation database management system. Commun. ACM, 34(10):78–92, October 1991.
[SR86] Michael Stonebraker and Lawrence A. Rowe. The design of postgres. In Proceedings of the 1986 ACM SIGMOD International Conference on Management of Data, SIGMOD '86, pages 340–355, New York, NY, USA, 1986. ACM.
[SRG83] M Stonebraker, B Rubenstein, and A Guttman. Application of abstract data types and abstract indices to cad bases. IEEE Trans, on Software Engineering, 1983.
[Sto86] Michael Stonebraker. The case for shared nothing. IEEE Database Eng. Bull., 9(1):4–9, 1986.
[Sto87] Michael Stonebraker. The design of the postgres storage system. In Proceedings of the 13th International Conference on Very Large Data Bases, VLDB '87, pages 289–300, San Francisco, CA, USA, 1987. Morgan Kaufmann Publishers Inc.
[Sto95] Michael Stonebraker. An overview of the sequoia 2000 project. Digital Technical Journal, 7(3):39–49, 1995.
[Sto14] Michael Stonebraker. The land sharks are on the squawk box, 2014. www.acm.org/turing-lecture-stonebraker (Last accessed January 4, 2019).

Postgres im Nachhinein