Traemos a su atención una traducción del artículo de Joseph Hellerstein "Mirando hacia atrás en Postgres" , publicado bajo la afirmación de copyright internacional Creative Commons versión 4.0 (CC-BY 4.0). Los autores se reservan el derecho de distribuir este trabajo en sitios web personales y corporativos con un enlace adecuado a la fuente.

Traducción realizada por Elena Indrupskaya. Agregaré por mi cuenta que "un programador que quería desesperadamente construir un sistema con múltiples versiones" parece ser Vadim Mikheev, pero todos conocemos a los "voluntarios de Rusia" que reescribieron GiST.

Anotación

Este es un recuerdo del proyecto Postgres, llevado a cabo en la Universidad de California en Berkeley y dirigido por Mike Stonebraker desde mediados de los años ochenta hasta mediados de los noventa. Como una de las muchas memorias personales e históricas, este artículo fue solicitado para un libro [ Bro19 ] sobre el Premio Turing de Stonebreaker. Por lo tanto, el enfoque del artículo está en el papel principal de Stonebreaker y sus pensamientos sobre el diseño. Pero Stonebreaker nunca fue un programador y no interfirió con su equipo de desarrollo. La base del código de Postgres fue el trabajo de un equipo de estudiantes brillantes y ocasionalmente programadores universitarios de tiempo completo que tenían un poco más de experiencia (y solo un salario ligeramente mayor) que los estudiantes. Tuve la suerte de unirme a este equipo como estudiante en los últimos años del proyecto. Recibí material útil para este artículo de algunos de los estudiantes mayores involucrados en el proyecto, pero cualquier error u omisión es mío. Si observa alguno de ellos, comuníquese conmigo e intentaré solucionarlo.

1. Introducción

Postgres fue el proyecto más ambicioso de Michael Stonebreaker: su intento serio de crear un sistema de base de datos universal. Durante una década, el proyecto ha generado más artículos, doctorados, profesores y empresas que cualquier otra actividad de Stonebreaker. El proyecto también cubrió más del campo técnico que cualquier otro sistema que él construyó. A pesar del riesgo inherente de esta magnitud, Postgres también se convirtió en el artefacto de software más exitoso que surgió de los equipos de investigación de Stonebreaker, y su principal contribución al código abierto. Este es un ejemplo de un "segundo sistema" [ Bro75 ] que ha tenido éxito. En el momento de la redacción, más de treinta años después del inicio del proyecto, el sistema de código abierto PostgreSQL es el sistema de base de datos de código abierto independiente más popular del mundo y el cuarto sistema de base de datos más popular. Mientras tanto, las compañías creadas a partir de Postgres generaron un total de más de $ 2.6 mil millones (en costos de adquisición). En cualquier medida, la visión del Rompepiedras Postgres tuvo una enorme resonancia duradera.

1.1. Antecedentes

Stonebreaker fue un gran éxito al principio de su carrera con el proyecto de investigación Ingres Berkeley [ SHWK76 ] y la posterior startup, que fundó con Larry Rowe y Eugene Wong: Relational Technology, Inc. (RTI)

A medida que RTI se desarrolló a principios de la década de 1980, Stonebreaker comenzó a trabajar en el soporte DBMS para tipos de datos que iban más allá de las filas y columnas tradicionales del modelo relacional original de Codd (Edgar Frank Codd). Un ejemplo motivador en ese momento era la necesidad de bases de datos para admitir herramientas de diseño asistido por computadora (CAD) para la industria microelectrónica. En un artículo de 1983 de Stonebreaker y estudiantes, Brad Rubenstein y Antonin Guttman explicaron cuánto necesita esta industria para admitir "nuevos tipos de datos como polígonos, rectángulos, cadenas de texto, etc.", " búsqueda espacial efectiva "," restricciones de integridad complejas ", así como" jerarquías de diseño y representaciones múltiples "en las mismas estructuras físicas [ SRG83 ]. Con esta motivación, el grupo comenzó a trabajar en la indexación (incluido el uso de árboles R de Guttman para la indexación espacial [ Gut84 ]) y en la adición de tipos de datos abstractos (ADT) al sistema de base de datos relacional. En ese momento, los ADT eran una nueva construcción popular de lenguajes de programación, que fue presentada por primera vez por Barbara Liskov, más tarde ganadora del Premio Turing, e investigada en la programación de aplicaciones de bases de datos por un nuevo colaborador de Stonebreaker, Larry Rowe. Un artículo en un registro SIGMOD de 1983 [ OFS83 ] Stonebreaker y los estudiantes James Ong y Dennis Fogg describen un estudio de este concepto en la extensión Ingres llamado ADT-Ingres, que incorpora muchos de los conceptos de presentación estudiados más profundamente y con un mejor soporte del sistema en Postgres.

2. Postgres: información general

Como su nombre lo indica, Postgres es Post-Ingres: un sistema diseñado para tomar lo que Ingres podría hacer e ir más allá. Una característica distintiva de Postgres fue la introducción de lo que finalmente llamó las propiedades relacionales de objetos de la base de datos: soporte para el concepto de programación orientada a objetos en el modelo de datos y el lenguaje de consulta declarativa del sistema de base de datos. Pero Stonebreaker también planeó resolver una serie de otros problemas tecnológicos independientes del soporte orientado a objetos en Postgres, como las reglas de bases de datos activas, datos versionados, almacenamiento terciario y concurrencia.

Se escribieron dos artículos sobre el diseño de Postgres: una descripción del diseño inicial en 1986 SIGMOD [ SR86 ] y una descripción intermedia en CACM 1991 [ SK91 ]. El proyecto de investigación de Postgres gradualmente quedó en nada en 1992 con la fundación de Illustra, una startup que involucró a Stonebreaker, el estudiante graduado principal Wei Hong y luego se convirtió en el programador jefe Jeff Meredith. En la lista a continuación, las oportunidades mencionadas en el artículo de 1986 están marcadas con un asterisco *, y las oportunidades del artículo de 1991, que no estaban en el artículo de 1986, están marcadas con una daga ^† . Las otras tareas enumeradas a continuación se tomaron en el sistema y en la literatura de investigación, pero no se encuentran en ninguna especificación de diseño. Muchos de estos temas fueron abordados en Postgres mucho antes de que otros los estudiaran o reinventaran. En muchos casos, Postgres se adelantó demasiado a su tiempo, y el interés en los temas surgió más tarde, desde una perspectiva moderna.

Soporte ADT en el sistema de base de datos.
- Objetos complejos (es decir, datos anidados o datos de forma no primera normal (forma no primera normal - NF2)) *
- Tipos de datos abstractos personalizados y funciones *
- Métodos de acceso extensible para nuevos tipos de datos *
- Procesamiento de consultas optimizado con características costosas definidas por el usuario
Bases de datos activas y sistemas de reglas (disparadores, advertencias) *
- Reglas implementadas como reescritura de solicitudes ^†
- Reglas implementadas como disparadores de nivel de grabación ^†
Almacenamiento y recuperación basados en registros
- Código de recuperación de complejidad reducida que trata el registro como datos *, utilizando memoria no volátil para el estado de confirmación ^†
- Almacenamiento no reescrito y consultas temporales ^†
Soporte para nuevas tecnologías de almacenamiento profundo, especialmente discos ópticos *
Soporte para multiprocesadores y procesadores especializados *
Soporte para varios modelos de idiomas.
- Cambios mínimos en el modelo relacional y soporte para consultas declarativas *
- Acceso a la "vía rápida" desde API internas sin pasar por el lenguaje de consulta ^†
- Multilingüismo ^†

Discutiremos brevemente la contribución de Postgres para cada uno de estos elementos en relación con el trabajo posterior en el campo de la informática.

2.1. Soporte ADT en el sistema de base de datos.

El objetivo claro de Postgres era admitir nuevas propiedades relacionales de objetos: expandir la tecnología de base de datos para proporcionar los beneficios tanto del procesamiento de consultas relacionales como de la programación orientada a objetos. Con el tiempo, el concepto de relación de objetos que apareció por primera vez en Postgres se convirtió en una funcionalidad estándar en la mayoría de los sistemas de bases de datos modernos.

2.1.1 Objetos complejos

Muy a menudo, los datos se representan como entidades anidadas u "objetos". Un ejemplo clásico es una orden de compra, que tiene un conjunto integrado de productos, sus cantidades y precios. La religión del modelado relacional dictaba que dichos datos debían reestructurarse y guardarse en un formato sin anidamiento, utilizando varias tablas planas de objetos (pedidos, productos) con tablas planas de relaciones conectadas (product_in_order). Una razón típica de este aplanamiento es que reduce la duplicación de datos (porque el producto se describe de forma redundante en muchas órdenes de compra), lo que, a su vez, evita la complejidad o los errores al actualizar todas las copias redundantes. Pero en algunos casos, desea mantener la subvista, porque es natural para la aplicación (por ejemplo, el mecanismo de diseño del circuito en CAD), y las actualizaciones son raras. Este debate sobre el modelado de datos es al menos tan antiguo como el modelo relacional.

El enfoque clave de Postgres fue "sentarse en dos sillas" en términos de modelado de datos: Postgres guardó las tablas como el tipo de datos "más externo", pero permitió que las columnas tuvieran tipos "complejos", incluidas tuplas o tablas anidadas. Una de sus implementaciones menos comunes, investigada por primera vez en el prototipo ADT-Ingres, era permitir que una columna de tipo de tabla se declarara declarativamente como una definición de consulta: "Quel como tipo de datos" [ SAHR84 ] (Quel - lenguaje de consulta Ingres. - Aprox. Per. .) .

El tema de soporte "post-relacional" para consultas declarativas y datos incrustados ha reaparecido a lo largo de los años, a menudo generado por disputas sobre cuál es mejor. Durante la época de Postgres en las décadas de 1980 y 1990, algunos grupos involucrados en bases de datos orientadas a objetos recogieron esta idea y la desarrollaron en el lenguaje OQL estándar, que luego dejó de usarse.

A comienzos del milenio, las consultas declarativas sobre objetos anidados se convirtieron en una obsesión con la investigación para el segmento de la comunidad de desarrolladores de bases de datos en forma de bases de datos XML. El lenguaje XQuery resultante (dirigido por Don Chamberlin, la persona de SQL) es necesario para admitir objetos complejos en el lenguaje Postgel de Postgres. XQuery es ampliamente utilizado y ampliamente utilizado en la industria, pero nunca ha sido popular entre los usuarios. Hoy, estos conceptos están siendo reexaminados en proyectos de lenguaje de consulta para el modelo de datos JSON, popular en aplicaciones basadas en navegador. Al igual que OQL, en grupos que inicialmente rechazaron las consultas declarativas a favor de la programación orientada al desarrollador (el movimiento "NoSQL"), estos lenguajes a menudo emergen como una adición tardía solo por el deseo de agregar consultas nuevamente al sistema. Al mismo tiempo, a medida que Postgres creció a lo largo de los años (y pasó del lenguaje de consulta de Postquel a las versiones SQL que cumplen muchos de los objetivos considerados), incluyó soporte para datos incrustados, como XML y JSON, en DBMS de uso general, sin requerir ningún o rediseño significativo. La controversia se está ejecutando con diversos grados de éxito, y el enfoque de Postgres para expandir la estructura relacional usando extensiones para datos anidados ha demostrado repetidamente ser un estado final natural para todas las partes después de que los argumentos remiten.

2.1.2. Tipos de datos abstractos personalizados y funciones

Además de sugerir tipos anidados, Postgres propuso la idea de introducir ADT opacos y extensibles que se almacenan en la base de datos pero que el núcleo no interpreta. Básicamente, esto siempre ha sido parte del modelo relacional de Codd: los enteros y las cadenas eran tradicionales, pero de hecho el modelo relacional abarca cualquier tipo de datos atómicos con predicados. La tarea consistía en proporcionar tal flexibilidad matemática en el software. Para utilizar consultas que interpretan estos objetos y los manipulan, un programador de aplicaciones debe poder registrar funciones definidas por el usuario (UDF) para estos tipos en el sistema y llamar a estas funciones en consultas. También es deseable que las funciones de agregado definido por el usuario (UDA) resuman las colecciones de estos objetos en consultas. El sistema de base de datos de Postgres ha sido innovador y ha sido totalmente compatible con estas características.

¿Por qué poner tal funcionalidad en un DBMS, en lugar de en aplicaciones de alto nivel? La respuesta típica a esta pregunta fue una ventaja significativa en el rendimiento del código colocado en los datos sobre la "extracción" de los datos al código. Postgres demostró que esto es bastante natural dentro de un entorno relacional: solo se requirieron cambios menores en el catálogo de metadatos relacionales y se crearon mecanismos de llamada de código de terceros, pero la sintaxis de consulta, la semántica y la arquitectura del sistema funcionaron de manera simple y elegante.

Postgres está un poco adelantado a su tiempo para explorar esta funcionalidad. En particular, en ese momento, la comunidad de investigación de bases de datos no estaba particularmente preocupada por las implicaciones de seguridad de descargar código inseguro al servidor. Esto comenzó a percibirse como un problema cuando se notó la tecnología en la industria. Stonebreaker llevó a Postgres al mercado en su startup Illustra, que Informix adquirió en gran medida por su capacidad de soportar paquetes de extensión DataBlade, incluido UDF. Informix, con su tecnología basada en Postgres y sus sólidas ofertas de bases de datos paralelas, se ha convertido en una amenaza importante para Oracle. Oracle ha invertido mucho en marketing negativo de los riesgos asociados con la capacidad de Informix para ejecutar código C de usuario "inseguro". Algunos atribuyen la muerte de Informix a esta campaña, aunque el fraude financiero de Informix (y el posterior enjuiciamiento federal de su entonces CEO) ciertamente presentaron problemas más serios. Ahora, décadas después, todos los principales proveedores de bases de datos admiten funciones personalizadas en uno o más idiomas, utilizando nuevas tecnologías para protegerse contra fallas del servidor o corrupción de datos.

Mientras tanto, las pilas tecnológicas de los grandes datos de la década de 2000, incluido el fenómeno MapReduce, que "echó a perder mucha sangre" por Stonebreaker y David DeWitt [ DS08 ], son una re-implementación de la idea de Postgres: código de usuario publicado como parte de la solicitud. Parece que MapReduce combina en gran medida las ideas de desarrollo de software de Postgres con ideas de concurrencia de sistemas como Gamma y Teradata, con algunas innovaciones menores en torno a reiniciar el proceso de consulta para cargas de trabajo con escalabilidad extrema. Las startups basadas en Postgres, Greenplum y Aster, alrededor de 2007, mostraron que la paralelización de Postgres podría conducir a algo mucho más funcional y práctico que MapReduce para la mayoría de los clientes, pero en 2008 el mercado aún no estaba listo para esta tecnología. . En este momento, en 2018, casi todas las grandes pilas de datos básicamente manejan la carga de trabajo de SQL paralelo con UDF, que es muy similar al diseño que Stonebreaker y el equipo usaron por primera vez en Postgres.

2.1.3. Métodos de acceso extensible para nuevos tipos de datos

Las bases de datos relacionales se desarrollaron casi al mismo tiempo que los árboles B a principios de la década de 1970, y los árboles B ayudaron a darle a Codd un sueño de "independencia del almacenamiento de datos físicos": la indexación con árboles B proporciona un nivel de indirección que Reorganiza de forma adaptativa el almacenamiento físico sin requerir cambios en la aplicación. La principal limitación de los árboles B y sus estructuras asociadas fue que solo admiten búsquedas y consultas de igualdad en el rango unidimensional. Pero, ¿qué sucede si tiene consultas de rango bidimensional típicas de aplicaciones de mapeo y CAD? Este problema se conoció durante Postgres, y el árbol R [ Gut84 ], desarrollado por Antonin Guttman en el grupo Stonebreaker, fue uno de los nuevos índices más exitosos diseñados para resolver este problema en la práctica. Sin embargo, la invención de la estructura de índice no resuelve el problema de soportar rangos multidimensionales en un DBMS para sistemas complejos. Hay muchas preguntas ¿Puede agregar fácilmente un método de acceso, como R-trees, a su DBMS? ¿Puede enseñarle al optimizador a comprender que el método de acceso especificado será útil para ciertas consultas? ¿Se puede lograr la recuperación correcta y el acceso simultáneo? Este fue un punto muy audaz en el plan de acción de Postgres: un problema de arquitectura de software que afecta a la mayoría del motor de base de datos, desde el optimizador hasta el nivel de almacenamiento, así como el sistema de registro y recuperación. Los árboles R de Postgres se han convertido en una poderosa fuerza impulsora y un excelente ejemplo de la elegante extensibilidad de la capa del método de acceso y su integración en el optimizador de consultas. Postgres mostró, utilizando un ADT opaco, cómo registrar un método de acceso descrito de manera abstracta (en este caso, un árbol R), y cómo un optimizador de consultas puede reconocer un predicado de selección abstracta (en este caso, una elección de rango) y compararlo con este método de acceso descrito de manera abstracta. Se prestó menos atención al control de acceso concurrente en el trabajo inicial: la falta de ordenamiento unidimensional de las llaves hizo que la cerradura utilizada en los árboles B en este caso fuera inaplicable.

Las características prometedoras de los métodos de acceso extensible de Postgres inspiraron uno de mis primeros proyectos de investigación al final de la escuela de posgrado: Árboles de búsqueda generalizada - GiST [ HNP95 ] y el concepto posterior de teoría de indexación [ HKM ⁺ 02 ]. Implementé GiST en Postgres durante un semestre después de completar mi doctorado, lo que facilitó aún más la adición de la nueva lógica de indexación a Postgres. La disertación de Marcel Kornacker de Berkeley (Marcel Kornacker) resolvió los complejos problemas de recuperación y acceso simultáneo establecidos por el tipo de "plantilla" extensible de índice GiST [ KMH97 ].

Hoy, PostgreSQL combina favorablemente la arquitectura de software original de los métodos de acceso extensible (tiene índices B-tree, GiST, SP-GiST y Gin) con la extensibilidad y el acceso competitivo intenso de la interfaz del Árbol de búsqueda generalizada (GiST). Los índices GiST son compatibles con el popular sistema de geoinformación PostGIS basado en PostgreSQL. Los índices Gin proporcionan soporte interno de indexación de texto en PostgreSQL.

2.1.4. Optimizador de consultas con UDF costosos

En la optimización tradicional de consultas, la tarea consistía en minimizar la cantidad de flujo de tuplas (y, por lo tanto, las operaciones de E / S) creadas al procesar la solicitud. Esto significaba que las declaraciones que filtran las tuplas (búsqueda) son buenas al comienzo del plan de consulta, mientras que las declaraciones que pueden generar nuevas tuplas (unión) deben ejecutarse más tarde. Como resultado, los optimizadores de consultas "empujarán" a los operadores de búsqueda debajo de las conexiones y los organizarán al azar, enfocándose en cambio en la optimización inteligente de las conexiones y los accesos a disco. Las UDF han cambiado el enfoque: si tiene UDF costosas en sus declaraciones de muestra, el orden de ejecución de las UDF puede ser crítico para optimizar el rendimiento. Además, si el UDF en el operador de selección realmente toma mucho tiempo, es posible que la selección se realice después de las conexiones (es decir, la selección debe ser "pull up" - selección "pullup"). Tener en cuenta estos factores ha complicado el espacio de búsqueda para el optimizador. Tomé este problema como la primera tarea difícil en la escuela de posgrado, y terminó siendo el tema de mi trabajo de maestría con Stonebreaker en Berkeley y mi doctorado en Wisconsin bajo la dirección de Jeff Naughton, pero con la ayuda constante de los consejos de Stonebreaker. Postgres fue el primer DBMS en almacenar el costo y la selectividad de las funciones definidas por el usuario en un directorio de base de datos. Abordamos el problema de optimización, habiendo llegado al orden óptimo de las operaciones de muestreo, y luego a la alternancia óptima de las operaciones de muestreo a lo largo de las ramas de cada árbol de conexión considerado en la búsqueda del plan. 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.

En medio del proyecto Postgres, Stonebreaker se inscribió como uno de los ejecutivos para una gran subvención digital de ciencias de la tierra llamada Proyecto Sequoia. Parte de la propuesta de subvención fue el procesamiento de cantidades sin precedentes de imágenes satelitales digitales, que requieren hasta 100 terabytes de memoria, es decir, una cantidad de datos mucho mayor de lo que sería conveniente almacenar en discos magnéticos en ese momento. La base de la solución propuesta fue investigar la idea de crear un DBMS (es decir, Postgres), que facilite el acceso al almacenamiento "terciario" semiautónomo proporcionado por unidades robóticas con reemplazo automático de discos para administrar bibliotecas de discos ópticos o cintas.

Esto condujo a varios estudios diferentes. Uno de ellos fue el sistema de archivos Inversion, un intento de proporcionar una abstracción del sistema de archivos UNIX a través de un DBMS relacional. En un artículo de revisión para Sequoia, Stonebreaker lo describió en su estilo habitual de patrocinar "ejercicio simple" [ Sto95 ]. De hecho, Mike Olson, un estudiante de Stonebreaker (y el posterior fundador de Cloudera), ha estado ocupado con esto durante varios años, y el resultado final no fue muy sencillo [ Ols93 ] y no sobrevivió en la práctica.

Unos años más tarde, Inversion Bill Gates "luchó contra los mismos molinos de viento" en WinFS, un intento de recrear el sistema de archivos más utilizado en el mundo a través de una base de datos relacional. WinFS se envió en versiones de desarrollo de Windows, pero nunca ingresó al mercado. Gates más tarde lo llamó su mayor decepción en Microsoft.

Otra área principal de investigación en este frente fue la inclusión de un repositorio terciario en la pila de bases de datos relacionales más típicas, que fue el tema de una tesis doctoral de Sunita Sarawagi. El tema principal fue cambiar la escala en la que piensa administrar el espacio (es decir, los datos almacenados y la jerarquía de la memoria) y el tiempo (coordinar la programación de consultas y la memoria caché para minimizar las E / S no deseadas). Uno de los problemas clave en este trabajo fue almacenar grandes matrices multidimensionales en un almacenamiento terciario y recuperarlas, lo que hace eco del trabajo en el campo de la indexación multidimensional. Las ideas clave incluyeron dividir la matriz en porciones y almacenar juntas las porciones que se seleccionan juntas, así como replicar las porciones para que la porción de datos pueda tener varios "vecinos" físicos. El segundo problema es pensar en cómo el disco se convierte en un caché para el almacenamiento terciario. Finalmente, la optimización y la programación de consultas deben tener en cuenta el largo tiempo de carga de datos del almacenamiento terciario y la importancia de los hits (hits) de la memoria caché del disco. Esto afecta tanto el plan elegido por el optimizador de consultas como el tiempo que lleva completar el plan.

Los robots en cintas y discos ópticos actualmente no se usan ampliamente. Pero los problemas de almacenamiento terciario son muy comunes en la nube, que en 2018 tiene una jerarquía de almacenamiento profundo: desde SSD conectados a servicios de almacenamiento confiables similares a un disco (por ejemplo, AWS EBS), al almacenamiento de archivos (por ejemplo, en AWS S3), al almacenamiento profundo (por ejemplo , Glaciar AWS). Hoy en día, estos niveles de almacenamiento aún están relativamente separados, y la base de datos prácticamente no admite el razonamiento sobre el almacenamiento de extremo a extremo que abarca estos niveles. No me sorprendería si las preguntas investigadas en este frente en Postgres se revisaran pronto.

2.5. Soporte multiprocesador: XPRS

Stonebreaker nunca creó un gran sistema de base de datos paralela, pero dirigió muchas discusiones desafiantes en esta área. Su artículo "Caso para nada compartido" [ Sto86 ] documentó soluciones arquitectónicas modulares grandes en esta área. Él popularizó la terminología utilizada en la industria y desconcertó el soporte de arquitecturas sin recursos compartidos, como Gamma y Teradata, que fueron redescubiertos en la década de 2000 por la comunidad de Big Data.

Irónicamente, la contribución más importante de Stonebreaker al campo de las bases de datos paralelas fue la arquitectura de "memoria compartida" llamada XPRS, que significaba "Postgres extendidos en RAID y Sprite". A principios de la década de 1990, XPRS era la "liga de la justicia" para los sistemas Berkeley: combina el sistema abreviado Postgres Stonebreaker, John Ousterhout, el sistema operativo Sprite distribuido y la arquitectura RAID de Dave Patterson y Randy Katz ) Al igual que con muchos trabajos interprofesionales, la implementación del proyecto XPRS en realidad fue determinada por los estudiantes graduados que trabajaron en él. Resultó que la contribución principal fue hecha por Wei Hong, quien escribió su tesis de doctorado sobre optimización de consultas paralelas en XPRS. Por lo tanto, la principal contribución de XPRS a la literatura y la industria fue optimizar las solicitudes concurrentes sin abordar significativamente los problemas asociados con RAID o Sprite.

De estos tres proyectos, Postgres y RAID tuvieron un gran impacto en el futuro. Sprite es mejor recordado por la tesis doctoral de Mendel Rosenblum sobre Log Structured File Systems (LFS), que no tuvo nada que ver con los sistemas operativos distribuidos. Los tres proyectos contenían nuevas ideas para el almacenamiento en disco, además de modificar copias individuales en su lugar. LFS y el administrador del repositorio de Postgres son bastante similares en su nuevo tratamiento de la revista como el repositorio principal y la necesidad de una costosa reorganización en segundo plano. Una vez, examiné cuidadosamente al Rompepiedras sobre la rivalidad entre LFS y Postgres o los "hechos fritos" académicos sobre su relación, pero nunca aprendí nada interesante de él. Quizás en ese momento en Berkeley alguien estaba "removiendo agua".

En principio, la concurrencia "explota" el espacio de los planes del optimizador de consultas, multiplicando las elecciones tradicionales realizadas durante la optimización de consultas (acceso a datos, algoritmos de conexión, orden de conexión) por todas las formas posibles de paralelizar cada opción. La idea principal del "optimizador Wei Hong" llamado por Stonebreaker era dividir el problema en dos: lanzar el optimizador de consultas tradicional en el espíritu del Sistema R para un nodo, y luego "paralelizar" el plan resultante, planificar el grado de paralelismo y la ubicación de cada operador en función de la representación datos y configuración del sistema. Este enfoque es heurístico, pero en él la concurrencia aumenta el costo de la optimización de consultas tradicionales de forma aditiva, en lugar de multiplicativa.

Aunque el optimizador de Wei Hong se desarrolló en el contexto de Postgres, se ha convertido en el enfoque estándar para muchos optimizadores de consultas concurrentes en la industria.

2.6. Soporte para varios modelos de idiomas.

Entre los intereses de Stonebreaker, renovado en repetidas ocasiones desde la época de Ingres, estaba la interfaz de programación de aplicaciones (API) del sistema de base de datos. En sus conferencias en la serie Sistemas de bases de datos, a menudo incluía el lenguaje GEM Carlo Zaniolo como un tema que es importante de entender para los defensores del sistema de bases de datos. Este interés en el lenguaje indudablemente lo llevó a asociarse con Larry Rowe en Postgres, lo que a su vez influyó profundamente en el diseño del modelo de datos de Postgres y su enfoque de relación de objetos. Su trabajo se centró principalmente en aplicaciones para trabajar con un gran volumen de datos de la esfera comercial, incluido el procesamiento de información comercial y nuevas aplicaciones como CAD / CAM y GIS.

Uno de los problemas que se impuso a Stonebreaker en ese momento fue la idea de "ocultar" los límites entre las construcciones del lenguaje de programación y el repositorio de la base de datos. Varios proyectos de investigación competitivos y compañías que investigan bases de datos orientadas a objetos (OODB) se han enfocado en la llamada "pérdida de conformidad" entre los lenguajes de programación orientados a objetos imperativos como Smalltalk, C ++ y Java, y los relacionales declarativos modelo La idea de OODB era hacer que los objetos del lenguaje de programación, si se desea, se marcaran como "permanentes" y se procesaran automáticamente por el DBMS incorporado. Postgres admitió el almacenamiento de objetos anidados y tipos de datos abstractos, pero su interfaz, basada en consultas declarativas en un estilo relacional, asumió el acceso no natural a la base de datos para el programador (requería el uso de consultas declarativas), que también eran costosas (requerían análisis y optimización). Para competir con los proveedores de OODB, Postgres proporcionó la llamada interfaz Fast Path: esencialmente la API C / C ++ para el almacenamiento interno de la base de datos. Esto permitió a Postgres tener un rendimiento académico de referencia OODB promedio, pero nunca resolvió el problema de permitir que los programadores en diferentes idiomas eviten el problema de perder el cumplimiento. En cambio, Stonebreaker etiquetó a Postgres como una etiqueta "relacional de objetos" y simplemente evitó el uso de bases de datos orientadas a objetos como un mercado de cero mil millones de dólares. Hoy en día, casi todos los sistemas de bases de datos relacionales comerciales son sistemas de bases de datos "relacionales con objetos".

Esto resultó ser una solución razonable. Hoy en día, ninguno de los productos OODB existe en su forma prevista, y la idea de "objetos persistentes" en los lenguajes de programación se ha descartado en gran medida. Por el contrario, el uso de capas de mapeo relacional de objetos (ORM) está muy extendido, impulsado por trabajos iniciales, como Java Hibernate y Ruby on Rails, lo que permite "adaptar" bases de datos declarativas a casi cualquier objeto imperativo de manera relativamente fluida. lenguaje de programación orientado como bibliotecas. Este enfoque a nivel de aplicación difiere de las bases de datos relacionales de objetos OODB y Stonebreaker. Además, los almacenamientos ligeros de valor-clave también se utilizan con éxito en formas no transaccionales y transaccionales. Su descubridor fue la estudiante graduada de Stonebreaker Margo Seltzer, quien trabajó en la base de datos de Berkeley DB como parte de su tesis doctoral al mismo tiempo que el grupo Postgres, que anticipó el crecimiento de repositorios distribuidos de valores clave NoSQL como Dynamo , MongoDB y Cassandra.

3. Impacto en el software

3.1. Código abierto

Postgres siempre ha sido un proyecto de código abierto con lanzamientos consistentes, pero al principio estaba destinado a ser utilizado para la investigación en lugar de la producción.

A medida que se acortaba el proyecto de investigación de Postgres, dos estudiantes de Stonebreaker, Andrew Yu y Jolly Chen, modificaron el analizador del sistema para reemplazar el lenguaje original de Postquel con una variante SQL extensible. La primera versión de Postgres que admite SQL fue Postgres95, y la siguiente se llamó PostgreSQL.

Un equipo de desarrollo de código abierto se interesó en PostgreSQL y lo "aceptó" incluso cuando cambiaron los intereses del resto del equipo de Berkeley. El equipo central de PostgreSQL se ha mantenido relativamente estable con el tiempo, y el proyecto de código abierto se ha desarrollado altamente. Inicialmente, los esfuerzos se centraron en la estabilidad del código y la funcionalidad visible para el usuario, pero con el tiempo, la comunidad de software de código abierto ha cambiado y mejorado significativamente el núcleo del sistema, desde el optimizador hasta los métodos de acceso y el sistema principal de transacciones y almacenamiento. Desde mediados de la década de 1990, una fracción muy pequeña de los componentes internos de PostgreSQL provino del equipo académico de Berkeley. Su última contribución puede haber sido mi implementación de GiST en la segunda mitad de la década de 1990, pero incluso fue sustancialmente reescrita y aprobada por voluntarios de la comunidad de código abierto (en este caso, Rusia). La parte de la comunidad de código abierto que trabaja en PostgreSQL merece los mayores elogios por su proceso simplificado, que durante décadas ha servido para crear un proyecto altamente eficiente y a largo plazo.

Aunque mucho ha cambiado durante 25 años, la arquitectura subyacente de PostgreSQL sigue siendo muy similar a las versiones universitarias de Postgres a principios de la década de 1990, y los desarrolladores familiarizados con el código fuente actual de PostgreSQL encontrarán fácil leer el código fuente de Postgres 3.1 (1991). Todo, desde la estructura del directorio del código fuente hasta las estructuras del proceso y las estructuras de datos, sigue siendo sorprendentemente similar. El código del equipo de Postgres en Berkeley tenía una gran columna vertebral.

Hoy, PostgreSQL es sin duda el sistema de gestión de bases de datos de código abierto de más alto rendimiento, y admite funcionalidades que a menudo no se encuentran en productos comerciales. También es (según un sitio de calificación influyente) el DBMS de código abierto independiente más popular del mundo, y su influencia continúa creciendo: en 2017 y 2018, fue la base de datos con la popularidad de más rápido crecimiento en el mundo [ DE19c ]. PostgreSQL se usa en una amplia variedad de industrias y tareas, lo cual no es sorprendente, dado su enfoque en amplias oportunidades.

Según DB-Engines, PostgreSQL hoy es la cuarta base de datos más popular del mundo, después de Oracle, MySQL y MS SQL Server, los cuales son ofrecidos por compañías específicas (MySQL fue adquirido por Oracle hace muchos años) [ DE19a ]. Las reglas de clasificación se discuten en la descripción de la metodología de clasificación DB-Engines [ DE19b ].

Heroku es el proveedor de la nube SaaS que ahora forma parte de Salesforce. Postgres se introdujo en Heroku en 2010 como la base de datos predeterminada para su plataforma. Heroku eligió Postgres por su fiabilidad. Con el soporte de Heroku, las plataformas de desarrollo de aplicaciones más grandes como Ruby on Rails y Python para Django comenzaron a recomendar Postgres como la base de datos predeterminada.

Hoy, PostgreSQL admite una infraestructura de extensión que facilita la adición de funciones adicionales al sistema a través de funciones definidas por el usuario y modificaciones relacionadas. Ahora hay un ecosistema de extensiones PostgreSQL, similar al concepto más completo de los paquetes de extensión DataBlade, pero con código fuente abierto. Las extensiones más interesantes incluyen, por ejemplo, la biblioteca Apache MADlib para aprendizaje automático en la interfaz SQL y la biblioteca Citus para la ejecución de consultas paralelas.

Una de las aplicaciones de código abierto más interesantes desarrolladas en Postgres es el sistema de información geográfica PostGIS, que utiliza muchas de las características de Postgres que originalmente inspiraron a Stonebreaker para comenzar el proyecto.

3.2. Implementación comercial

PostgreSQL ha sido durante mucho tiempo un punto de partida atractivo para crear sistemas de bases de datos comerciales, dado su uso bajo la licencia de software de código abierto "todo permitido", código confiable, flexibilidad y amplia funcionalidad. Resumiendo los costos de adquisición enumerados a continuación, vemos que Postgres recibió más de $ 2.6 mil millones en costos de adquisición.

Tenga en cuenta que esta es una medida en dólares de transacciones financieras reales y es mucho más importante que los valores que a menudo se utilizan en alta tecnología. Las cifras en miles de millones a menudo se usan para describir el valor estimado de bloques de acciones, pero a menudo se exageran 10 veces o más en comparación con el valor presente con la esperanza de su importancia futura. Los dólares de transacción de adquisición de la compañía miden su valor de mercado real en el momento de la adquisición. Es justo decir que Postgres ha creado más de $ 2.6 mil millones de valor comercial real.

Muchos de los esfuerzos comerciales asociados con PostgreSQL se han centrado en lo que probablemente sea su principal limitación: la capacidad de escalar a una arquitectura paralela sin compartir recursos.

Paralelizar PostgreSQL requiere una buena cantidad de trabajo, pero es muy factible por un equipo pequeño y experimentado. Hoy en día, las ramas de la industria de código abierto de PostgreSQL como Greenplum y CitusDB brindan esta oportunidad. Es lamentable que PostgreSQL no se haya paralelo correctamente en código abierto mucho antes. Si PostgreSQL se hubiera expandido en código abierto con soporte para una arquitectura sin recursos compartidos a principios de la década de 2000, es posible que la dirección de big data de código abierto se hubiera desarrollado de una manera completamente diferente y más eficiente.

Illustra fue la segunda startup más grande de Stonebreaker, fundada en 1992 para comercializar Postgres, cuando RTI lanzó Ingres en el mercado.

Illustra fue en realidad el tercer nombre propuesto para la empresa. Continuando con el tema de la pintura, dado el nombre de Ingres, Illustra originalmente se llamaba Miro. Debido a problemas con la marca registrada, el nombre se cambió a Montage, pero también encontró problemas con la marca registrada.

El equipo fundador incluyó parte del núcleo del equipo de Postgres, incluido el reciente estudiante graduado Wei Hong y luego el programador jefe Jeff Meredith, así como los graduados de Ingres Paula Hawthorn y Michael Ubell. El estudiante graduado de Postgres Mike Olson se unió poco después de su fundación, y trabajé en Illustra para optimizar funciones costosas como parte de mi doctorado. 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.

Literatura

[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 en retrospectiva