Trazemos a sua atenção uma tradução do artigo de Joseph Hellerstein, “Olhando para trás no Postgres” , publicado sob a afirmação internacional de direitos autorais da Creative Commons versão 4.0 (CC-BY 4.0). Os autores reservam-se o direito de distribuir este trabalho em sites pessoais e corporativos com um link adequado para a fonte.

Tradução feita por Elena Indrupskaya. Acrescentarei por conta própria que "um programador que queria desesperadamente criar um sistema com várias versões" parece ser Vadim Mikheev, mas todos conhecemos os "voluntários da Rússia" que reescreveram o GiST.

Anotação

Esta é uma lembrança do projeto Postgres, realizado na Universidade da Califórnia em Berkeley e liderado por Mike Stonebraker, de meados da década de 1980 a meados da década de 90. Como uma das muitas memórias pessoais e históricas, este artigo foi solicitado para um livro [ Bro19 ] sobre o Prêmio Turing de Stonebreaker. Portanto, o foco do artigo é o papel principal de Stonebreaker e seus pensamentos sobre design. Mas Stonebreaker nunca foi um programador e não interferiu em sua equipe de desenvolvimento. A base de código do Postgres foi o trabalho de uma equipe de estudantes brilhantes e, ocasionalmente, de programadores universitários em tempo integral que tinham um pouco mais de experiência (e apenas um salário um pouco maior) do que os estudantes. Tive a sorte de ingressar nesta equipe como estudante nos últimos anos do projeto. Recebi material útil para este artigo de alguns dos alunos mais velhos envolvidos no projeto, mas quaisquer erros ou omissões são meus. Se você notar algum deles, entre em contato comigo e tentarei consertá-los.

1. Introdução

O Postgres foi o projeto mais ambicioso de Michael Stonebreaker - sua séria tentativa de criar um sistema de banco de dados universal. Por uma década, o projeto gerou mais artigos, PhDs, professores e empresas do que qualquer outra atividade do Stonebreaker. O projeto também abrangeu mais do campo técnico do que qualquer outro sistema que ele construiu. Apesar do risco inerente dessa magnitude, o Postgres também se tornou o artefato de software mais bem-sucedido que saiu das equipes de pesquisa do Stonebreaker e sua principal contribuição para o código aberto. Este é um exemplo de um "segundo sistema" [ Bro75 ] que foi bem-sucedido. No momento da redação deste artigo, mais de trinta anos desde o início do projeto, o sistema PostgreSQL de código aberto é o sistema de banco de dados de código aberto independente mais popular do mundo e o quarto sistema de banco de dados mais popular. Enquanto isso, as empresas criadas a partir do Postgres geraram um total de mais de US $ 2,6 bilhões (em custo de aquisição). De qualquer forma, a visão do Quebra-pedras do Postgres teve uma enorme ressonância duradoura.

1.1 Antecedentes

Stonebreaker foi um grande sucesso no início de sua carreira com o projeto de pesquisa de Ingres Berkeley [ SHWK76 ] e a subsequente startup, que ele fundou com Larry Rowe e Eugene Wong: Relational Technology, Inc. (RTI).

À medida que a RTI se desenvolveu no início dos anos 80, o Stonebreaker começou a trabalhar no suporte a tipos de dados em DBMSs que iam além das linhas e colunas tradicionais do modelo relacional original do Codd (Edgar Frank Codd). Um exemplo motivador da época era a necessidade de bancos de dados para suportar ferramentas de projeto auxiliado por computador (CAD) para a indústria microeletrônica. Em um artigo de 1983 de Stonebreaker e estudantes, Brad Rubenstein e Antonin Guttman explicaram o quanto esse setor precisa para suportar "novos tipos de dados como polígonos, retângulos, seqüências de texto, etc.", " busca espacial efetiva ”,“ restrições complexas de integridade ”, bem como“ hierarquias de design e múltiplas representações ”nas mesmas estruturas físicas [ SRG83 ]. Com essa motivação, o grupo começou a trabalhar na indexação (incluindo o uso de árvores R de Guttman para indexação espacial [ Gut84 ]) e na adição de tipos de dados abstratos (ADTs) ao sistema de banco de dados relacional. Naquela época, os ADTs eram um novo design popular de linguagens de programação, que foi introduzido pela primeira vez por Barbara Liskov, mais tarde ganhadora do Prêmio Turing e explorada na programação de aplicativos de banco de dados por Lonely Rowe, uma nova colaboradora do Stonebreaker. Um artigo do SIGMOD Record [ OFS83 ] de 1983, Stonebreaker e os alunos James Ong e Dennis Fogg descrevem um estudo desse conceito na extensão de Ingres chamado ADT-Ingres, que incluía muitos dos conceitos de apresentação estudados mais profundamente e com melhor suporte ao sistema no Postgres.

2. Postgres: informações gerais

Como o nome indica, Postgres é Post-Ingres: um sistema projetado para pegar o que Ingres poderia fazer e ir além. Uma característica distintiva do Postgres foi a introdução do que chamou de propriedades relacionais a objetos do banco de dados: suporte ao conceito de programação orientada a objetos no modelo de dados e na linguagem de consulta declarativa do sistema de banco de dados. Mas o Stonebreaker também planejava resolver uma série de outros problemas tecnológicos, independentemente do suporte orientado a objetos no Postgres, como regras de banco de dados ativo, dados de versão, armazenamento de nível superior e simultaneidade.

Dois artigos foram escritos sobre o design do Postgres: uma descrição do design inicial em 1986 SIGMOD [ SR86 ] e uma descrição intermediária no CACM 1991 [ SK91 ]. O projeto de pesquisa do Postgres foi gradualmente frustrado em 1992, com a fundação da Illustra, uma startup que envolveu o Stonebreaker, o principal aluno de graduação Wei Hong e depois se tornou o programador-chefe Jeff Meredith. Na lista abaixo, as oportunidades mencionadas no artigo de 1986 são marcadas com um asterisco *, e as oportunidades do artigo de 1991, que não estavam no artigo de 1986, são marcadas com uma adaga ^† . As outras tarefas listadas abaixo foram realizadas no sistema e na literatura de pesquisa, mas não foram encontradas em nenhuma especificação de projeto. Muitos desses tópicos foram abordados no Postgres muito antes de serem estudados ou reinventados por outros. Em muitos casos, o Postgres estava muito à frente de seu tempo, e o interesse em tópicos aumentou mais tarde, de uma perspectiva moderna.

Suporte ADT no sistema de banco de dados
- Objetos complexos (ou seja, dados aninhados ou dados de formulário não-primeiro-normal (formulário não-primeiro-normal - NF2)) *
- Tipos de dados abstratos personalizados e funções *
- Métodos de acesso extensíveis para novos tipos de dados *
- Processamento de consultas otimizado com recursos caros definidos pelo usuário
Bancos de dados ativos e sistemas de regras (gatilhos, avisos) *
- Regras implementadas como reescrita de solicitação ^†
- Regras implementadas como gatilhos de nível de gravação ^†
Armazenamento e recuperação com base em log
- Código de recuperação de complexidade reduzida que trata o log como dados *, usando memória não volátil para o estado de confirmação ^†
- Armazenamento não reescrito e consultas temporais ^†
Suporte para novas tecnologias de armazenamento profundo, especialmente discos ópticos *
Suporte para multiprocessadores e processadores especializados *
Suporte para vários modelos de idiomas
- Alterações mínimas no modelo relacional e suporte para consultas declarativas *
- Acesso ao "caminho rápido" das APIs internas ignorando o idioma da consulta ^†
- Multilinguismo ^†

Discutiremos brevemente a contribuição do Postgres para cada um desses itens em relação ao trabalho subsequente no campo da computação.

2.1 Suporte ADT no sistema de banco de dados

O objetivo claro do Postgres era oferecer suporte a novas propriedades relacionais a objetos: expandir a tecnologia de banco de dados para fornecer os benefícios do processamento de consultas relacionais e da programação orientada a objetos. Com o tempo, o conceito objeto-relacional que apareceu pela primeira vez no Postgres se tornou uma funcionalidade padrão na maioria dos sistemas de banco de dados modernos.

2.1.1 Objetos complexos

Frequentemente, os dados são representados como entidades aninhadas ou "objetos". Um exemplo clássico é um pedido de compra, que possui um conjunto incorporado de produtos, suas quantidades e preços. A religião da modelagem relacional determinava que esses dados fossem reestruturados e salvos em um formato sem aninhamento, usando várias tabelas simples de objetos (pedidos, produtos) e conectando tabelas simples de relações (product_in_order). Um motivo típico para esse achatamento é que ele reduz a duplicação de dados (porque o produto é descrito de forma redundante em muitos pedidos), o que, por sua vez, evita a complexidade ou os erros ao atualizar todas as cópias redundantes. Mas, em alguns casos, você deseja manter a subvisão, porque é natural para a aplicação (por exemplo, o mecanismo de layout do circuito no CAD), e as atualizações são raras. Esse debate sobre modelagem de dados é pelo menos tão antigo quanto o modelo relacional.

A principal abordagem do Postgres foi “sentar em duas cadeiras” em termos de modelagem de dados: o Postgres salvou tabelas como o tipo de dados “mais externo”, mas permitiu que as colunas tivessem tipos “complexos”, incluindo tuplas ou tabelas aninhadas. Uma de suas implementações menos comuns, investigada pela primeira vez no protótipo ADT-Ingres, era permitir que uma coluna de tipo de tabela fosse declarada declarativamente como uma definição de consulta: "Quel como um tipo de dados" [ SAHR84 ] (Quel - linguagem de consulta Ingres. - Aprox. .) .

O tópico “pós-relacional” de suporte para consultas declarativas e dados incorporados reapareceu ao longo dos anos, geralmente gerado por disputas sobre qual é o melhor. Durante o Postgres nas décadas de 1980 e 1990, alguns grupos envolvidos em bancos de dados orientados a objetos captaram essa idéia e a desenvolveram na linguagem OQL padrão, que deixou de ser usada.

Na virada do milênio, as consultas declarativas sobre objetos aninhados tornaram-se uma obsessão pela pesquisa para o segmento da comunidade de desenvolvedores de banco de dados na forma de bancos de dados XML. A linguagem XQuery resultante (liderada por Don Chamberlin, a persona do SQL) é necessária para suportar objetos complexos na linguagem Postgel do Postgres. O XQuery é amplamente utilizado e amplamente utilizado na indústria, mas nunca foi popular entre os usuários. Hoje, esses conceitos estão sendo reexaminados em projetos de linguagem de consulta para o modelo de dados JSON, popular em aplicativos baseados em navegador. Como o OQL, em grupos que inicialmente rejeitaram consultas declarativas em favor da programação orientada a desenvolvedores (o movimento “NoSQL”), essas linguagens geralmente emergem como uma adição tardia apenas do desejo de adicionar consultas ao sistema. Ao mesmo tempo, à medida que o Postgres cresceu ao longo dos anos (e passou da linguagem de consulta Postquel para as versões SQL que atendem a muitos dos objetivos considerados), ele incluiu suporte para dados incorporados, como XML e JSON, em DBMSs de uso geral, sem a necessidade de ou redesenho significativo. A controvérsia está ocorrendo com graus variados de sucesso, e a abordagem do Postgres de expandir a estrutura relacional usando extensões para dados aninhados provou repetidamente ser um estado final natural para todas as partes após o término dos argumentos.

2.1.2 Tipos de dados abstratos personalizados e funções

Além de sugerir tipos aninhados, o Postgres propõe a idéia de introduzir ADTs opacas e extensíveis que são armazenadas no banco de dados, mas não são interpretadas pelo kernel. Basicamente, isso sempre fez parte do modelo relacional de Codd: números inteiros e seqüências de caracteres eram tradicionais, mas, na verdade, o modelo relacional abrange qualquer tipo de dado atômico com predicados. A tarefa era fornecer essa flexibilidade matemática em software. Para usar consultas que interpretam esses objetos e os manipulam, um programador de aplicativo deve poder registrar UDFs (funções definidas pelo usuário) para esses tipos no sistema e chamar essas funções nas consultas. Também é desejável que as funções agregadas definidas pelo usuário (UDA) resumam as coleções desses objetos nas consultas. O sistema de banco de dados Postgres foi inovador, oferecendo suporte abrangente a esses recursos.

Por que colocar essa funcionalidade em um DBMS, em vez de em aplicativos de alto nível? A resposta típica para essa pergunta foi uma vantagem significativa no desempenho do código colocado nos dados sobre a "extração" dos dados para o código. O Postgres mostrou que isso é bastante natural em um ambiente relacional: apenas pequenas alterações foram necessárias no catálogo de metadados relacionais e foram criados mecanismos de chamada de código de terceiros, mas a sintaxe da consulta, a semântica e a arquitetura do sistema funcionaram de maneira simples e elegante.

O Postgres está um pouco à frente do seu tempo na exploração dessa funcionalidade. Em particular, naquele momento, a comunidade de pesquisa de banco de dados não estava particularmente preocupada com as implicações de segurança do download de código não seguro no servidor. Isso começou a ser percebido como um problema quando a tecnologia foi percebida no setor. O Stonebreaker levou o Postgres ao mercado em sua startup Illustra, que a Informix adquiriu em grande parte por sua capacidade de oferecer suporte a pacotes de extensão DataBlade, incluindo UDF. O Informix, com sua tecnologia baseada no Postgres e fortes ofertas de bancos de dados paralelos, tornou-se uma ameaça significativa para a Oracle. A Oracle investiu pesadamente no marketing negativo dos riscos associados à capacidade do Informix de executar o código C do usuário "inseguro". Alguns atribuem a morte do Informix a esta campanha, embora a fraude financeira do Informix (e subsequente processo federal do seu então CEO) certamente tenha apresentado problemas mais sérios. Agora, décadas depois, todos os principais provedores de bancos de dados suportam funções personalizadas em um ou mais idiomas, usando novas tecnologias para proteger contra falhas no servidor ou corrupção de dados.

Enquanto isso, as pilhas de tecnologia dos big data dos anos 2000, incluindo o fenômeno MapReduce, que "estragou muito sangue" por Stonebreaker e David DeWitt [ DS08 ], são uma reimplementação da idéia do Postgres - código de usuário publicado como parte da solicitação. Parece que o MapReduce combina amplamente as idéias de desenvolvimento de software do Postgres com as idéias de simultaneidade de sistemas como Gamma e Teradata, com algumas pequenas inovações em torno de reiniciar o processo de consulta para cargas de trabalho com extrema escalabilidade. As startups baseadas no Postgres, Greenplum e Aster, por volta de 2007, mostraram que o paralelismo do Postgres poderia levar a algo muito mais funcional e prático do que o MapReduce para a maioria dos clientes, mas em 2008 o mercado ainda não estava preparado para essa tecnologia. . Até agora, em 2018, quase toda pilha de big data lida basicamente com a carga de trabalho SQL paralela com o UDF, que é muito semelhante ao design usado pelo Stonebreaker e pela equipe no Postgres.

2.1.3 Métodos de acesso extensível para novos tipos de dados

Bancos de dados relacionais desenvolvidos na mesma época que as árvores B no início dos anos 70, e as árvores B ajudaram a Codd sonhar com “independência do armazenamento físico de dados”: a indexação com árvores B fornece um nível de indireção que Reorganiza adaptativamente o armazenamento físico sem exigir alterações no aplicativo. A principal limitação das árvores B e de suas estruturas associadas era que elas suportam apenas pesquisas e consultas sobre igualdade no intervalo unidimensional. Mas e se você tiver consultas de intervalo bidimensional típicas de aplicativos de mapeamento e CAD? Esse problema era conhecido durante o Postgres, e o R-tree [ Gut84 ], desenvolvido por Antonin Guttman no grupo Stonebreaker, foi um dos novos índices de maior sucesso projetados para resolver esse problema na prática. No entanto, a invenção da estrutura de índice não resolve o problema de suportar faixas multidimensionais em um DBMS para sistemas complexos. Há muitas perguntas. Você pode adicionar facilmente um método de acesso, como árvores R, ao seu DBMS? Você pode ensinar o otimizador a entender que o método de acesso especificado será útil para determinadas consultas? Você consegue a recuperação correta e o acesso simultâneo? Esse foi um ponto muito ousado no programa de ação do Postgres: um problema de arquitetura de software que afeta a maior parte do mecanismo de banco de dados, do otimizador à camada de armazenamento e o sistema de registro em diário e recuperação. As árvores R do Postgres se tornaram uma força motriz poderosa e um excelente exemplo da extensibilidade elegante da camada do método de acesso e sua integração ao otimizador de consultas. O Postgres mostrou, usando um ADT opaco, como registrar um método de acesso descrito abstratamente (neste caso, uma árvore R) e como um otimizador de consulta pode reconhecer um predicado de seleção abstrata (nesse caso, uma opção de intervalo) e combiná-lo com esse método de acesso abstratamente descrito. Menos atenção foi dada ao controle de acesso simultâneo no trabalho inicial: a falta de ordem unidimensional de chaves tornou a trava usada nas árvores B neste caso inaplicável.

As características promissoras dos métodos de acesso extensível do Postgres inspiraram um dos meus primeiros projetos de pesquisa no final da pós-graduação: Árvores de Pesquisa Generalizada - GiST [ HNP95 ] e o conceito subseqüente da teoria da indexação [ HKM ⁺ 02 ]. Eu implementei o GiST no Postgres por um semestre depois de concluir meu doutorado, o que tornou ainda mais fácil adicionar a nova lógica de indexação ao Postgres. A dissertação de Marcel Kornacker de Berkeley (Marcel Kornacker) resolveu os problemas complexos de recuperação e acesso simultâneo, apresentados pelo extensível tipo "modelo" de índice GiST [ KMH97 ].

Hoje, o PostgreSQL combina favoravelmente a arquitetura original do software de métodos de acesso extensível (possui índices B-tree, GiST, SP-GiST e Gin) com a extensibilidade e intenso acesso competitivo da interface da árvore de pesquisa generalizada (GiST). Os índices GiST suportam o popular sistema de informação geográfica PostGIS baseado no PostgreSQL. Os índices Gin fornecem suporte interno à indexação de texto no PostgreSQL.

2.1.4 Otimizador de consultas com UDFs dispendiosos

Na otimização de consulta tradicional, a tarefa era minimizar a quantidade de fluxo de tupla (e, portanto, operações de E / S) criadas ao processar a solicitação. Isso significava que as instruções que filtram as tuplas (busca) são boas no início do plano de consulta, enquanto as instruções que podem gerar novas tuplas (associação) precisam ser executadas posteriormente. Como resultado, os otimizadores de consulta "empurram" os operadores de busca abaixo das conexões e os organizam aleatoriamente, concentrando-se na otimização inteligente de conexões e acessos a disco. As UDFs mudaram a abordagem: se você tiver UDFs caras em suas instruções de amostra, a ordem de execução das UDFs pode ser crítica para otimizar o desempenho. Além disso, se o UDF no operador de seleção realmente levar muito tempo, é possível que a seleção seja realizada após as conexões (ou seja, a seleção deve ser "puxada para cima" - seleção "puxada"). A consideração desses fatores complicou o espaço de pesquisa para o otimizador. Tomei esse problema como a primeira tarefa difícil na pós-graduação, e acabou sendo o assunto do trabalho de meu mestrado com Stonebreaker em Berkeley e meu Ph.D. em Wisconsin sob a direção de Jeff Naughton, mas com a ajuda constante de conselhos de Stonebreaker. O Postgres foi o primeiro DBMS a armazenar o custo e a seletividade de funções definidas pelo usuário em um diretório de banco de dados. Abordamos o problema de otimização, apresentando a ordem ideal das operações de amostragem e, em seguida, a alternância ideal das operações de amostragem ao longo dos ramos de cada árvore de conexão considerada na pesquisa do plano. 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.

No meio do projeto Postgres, o Stonebreaker se inscreveu como um dos executivos de uma grande bolsa digital de ciências terrestres chamada Project Sequoia. Parte da proposta de concessão foi o processamento de quantidades sem precedentes de imagens digitais de satélite, exigindo até 100 terabytes de memória, ou seja, uma quantidade muito maior de dados do que seria sensato armazenar em discos magnéticos naquele momento. A base da solução proposta foi investigar a idéia de criar um DBMS (ou seja, o Postgres), que facilita o acesso ao armazenamento "terciário" semi-autônomo fornecido por unidades robóticas com substituição automática de disco para gerenciar bibliotecas de discos ou fitas ópticas.

Isso levou a vários estudos diferentes. Um deles era o sistema de arquivos Inversion - uma tentativa de fornecer uma abstração do sistema de arquivos UNIX através de um DBMS relacional. Em um artigo de revisão para Sequoia, Stonebreaker o descreveu em seu estilo usual de "exercício simples" condescendente [ Sto95 ]. De fato, Mike Olson, um estudante da Stonebreaker (e o subsequente fundador da Cloudera), está ocupado com isso há vários anos, e o resultado final não foi muito direto [ Ols93 ] e não sobreviveu na prática.

Alguns anos depois, o Inversion Bill Gates “lutou contra os mesmos moinhos de vento” no WinFS - uma tentativa de recriar o sistema de arquivos mais usado no mundo através do back-end de um banco de dados relacional. O WinFS foi enviado em versões de desenvolvimento do Windows, mas nunca entrou no mercado. Mais tarde, Gates chamou sua maior decepção na Microsoft.

Outra área principal de pesquisa nessa área foi a inclusão de um repositório terciário na pilha de bancos de dados relacionais mais típicos, que foi objeto de uma tese de doutorado de Sunita Sarawagi. O tópico principal foi alterar a escala na qual você pensa em gerenciar o espaço (isto é, dados no armazenamento e a hierarquia de memória) e o tempo (coordenar o planejamento e o cache de consultas para minimizar a E / S indesejada). Um dos principais problemas deste trabalho foi armazenar grandes matrizes multidimensionais em um armazenamento terciário e recuperá-las, o que reflete o trabalho no campo da indexação multidimensional. As ideias principais incluíram dividir a matriz em partes e armazenar juntas as partes selecionadas juntas, além de replicar as partes para que a parte de dados possa ter vários "vizinhos" físicos. O segundo problema é pensar em como o disco se torna um cache para armazenamento terciário. Por fim, a otimização e o agendamento de consultas devem levar em consideração o tempo necessário para carregar dados do armazenamento terciário e a importância dos acertos no cache do disco. Isso afeta o plano escolhido pelo otimizador de consulta e o tempo necessário para concluir o plano.

Atualmente, os robôs em fitas e discos ópticos não são amplamente utilizados. Mas os problemas de armazenamento terciário são muito comuns na nuvem, que em 2018 possui uma hierarquia profunda de armazenamento: de SSDs conectados a serviços confiáveis de armazenamento semelhante a disco (por exemplo, AWS EBS), armazenamento de arquivamento (por exemplo, no AWS S3) e armazenamento profundo (por exemplo , Geleira da AWS). Hoje, essas camadas de armazenamento ainda são relativamente separadas e o raciocínio sobre o armazenamento de ponta a ponta que abrange essas camadas praticamente não é suportado pelo banco de dados. Não ficaria surpreso se as perguntas investigadas nessa frente no Postgres forem analisadas em breve.

2.5 Suporte para multiprocessador: XPRS

O Stonebreaker nunca criou um grande sistema de banco de dados paralelo, mas liderou muitas discussões desafiadoras nessa área. Seu artigo “Case for Shared Nothing” [ Sto86 ] documentou grandes soluções arquitetônicas modulares nessa área. Ele popularizou a terminologia usada na indústria e intrigou o suporte de arquiteturas sem recursos compartilhados, como Gamma e Teradata, que foram redescobertos nos anos 2000 pela comunidade de big data.

Ironicamente, a contribuição mais significativa do Stonebreaker para o campo de bancos de dados paralelos foi a arquitetura de "memória compartilhada" chamada XPRS, que significava "eXtended Postgres on RAID and Sprite". No início dos anos 90, o XPRS era a “liga da justiça” para os sistemas de Berkeley: combina o sistema abreviado do Postgres Stonebreaker, John Ousterhout, o distribuído OS Sprite e a arquitetura RAID de Dave Patterson e Randy Katz ) Como em muitos trabalhos interdisciplinares, a implementação do projeto XPRS foi realmente determinada pelos alunos de pós-graduação que trabalharam nele. Verificou-se que a principal contribuição foi feita por Wei Hong, que escreveu sua tese de doutorado sobre otimização de consultas paralelas em XPRS. Assim, a principal contribuição do XPRS para a literatura e a indústria foi otimizar solicitações simultâneas sem abordar significativamente os problemas associados ao RAID ou Sprite.

Desses três projetos, o Postgres e o RAID tiveram um enorme impacto no futuro. A Sprite é mais lembrada pela dissertação de doutorado de Mendel Rosenblum sobre Log Structured File Systems (LFS), que não tinha nada de notável a ver com sistemas operacionais distribuídos. Todos os três projetos continham novas idéias para armazenamento em disco, além de modificar cópias individuais em vigor. O LFS e o gerenciador de repositório do Postgres são bastante semelhantes em seu novo tratamento do diário como o repositório principal e a necessidade de reorganização de segundo plano dispendiosa. Certa vez, examinei cuidadosamente o Stonebreaker sobre a rivalidade entre LFS e Postgres ou os "fatos fritos" acadêmicos sobre o relacionamento deles, mas nunca aprendi nada interessante com ele. Talvez naquela época em Berkeley alguém estivesse "mexendo na água".

Em princípio, a simultaneidade “explode” o espaço dos planos do otimizador de consultas, multiplicando as opções tradicionais feitas durante a otimização de consultas (acesso a dados, algoritmos de conexão, ordem de conexão) por todas as formas possíveis de paralelizar cada opção. A principal idéia do “otimizador Wei Hong” chamado por Stonebreaker era dividir o problema em dois: iniciar o otimizador de consulta tradicional no espírito do Sistema R para um nó e depois “paralelizar” o plano resultante, planejar o grau de paralelismo e posicionamento de cada operador com base na representação configuração de dados e sistema. Essa abordagem é heurística, mas a simultaneidade aumenta o custo da otimização de consulta tradicional de maneira aditiva, e não multiplicativa.

Embora o otimizador do Wei Hong tenha sido desenvolvido no contexto do Postgres, ele se tornou a abordagem padrão para muitos otimizadores de consulta simultâneos do setor.

2.6 Suporte para vários modelos de idiomas

Entre os interesses do Stonebreaker, renovado várias vezes desde a época de Ingres, estava a interface de programação de aplicativos do sistema de banco de dados (API). Em suas palestras na série Database Systems, ele frequentemente incluía a linguagem GEM Carlo Zaniolo como um tópico que é importante entender para os defensores do sistema de banco de dados. Esse interesse na linguagem indubitavelmente o levou a fazer parceria com Larry Rowe no Postgres, o que por sua vez influenciou profundamente o design do modelo de dados do Postgres e sua abordagem objeto-relacional. Seu trabalho foi focado principalmente em aplicativos para trabalhar com um grande volume de dados da esfera comercial, incluindo o processamento de informações de negócios e novos aplicativos, como CAD / CAM e GIS.

Um dos problemas impostos ao Stonebreaker na época era a idéia de "ocultar" os limites entre as construções da linguagem de programação e o repositório de banco de dados. Vários projetos de pesquisa concorrentes e empresas que pesquisam bancos de dados orientados a objetos (OODBs) têm como alvo a chamada "perda de conformidade" entre linguagens de programação imperativas orientadas a objetos como Smalltalk, C ++ e Java e relacional declarativa modelo. A idéia do OODB era tornar os objetos da linguagem de programação, se desejado, marcados como "permanentes" e processados automaticamente pelo DBMS interno. O Postgres suportava o armazenamento de objetos aninhados e tipos abstratos de dados, mas sua interface, baseada em consultas declarativas em um estilo relacional, assumia acesso não natural ao banco de dados para o programador (exigia o uso de consultas declarativas), que também eram caras (exigiam análise e otimização). Para competir com os provedores de OODB, o Postgres forneceu a chamada interface Fast Path: essencialmente a API C / C ++ para armazenamento interno do banco de dados. Isso permitiu ao Postgres ter desempenho médio de referência acadêmica do OODB, mas nunca resolveu o problema de permitir que programadores em diferentes idiomas evitassem o problema de perder a conformidade. Em vez disso, o Stonebreaker rotulou o Postgres como um rótulo "objeto-relacional" e simplesmente ignorou o uso de bancos de dados orientados a objetos como um mercado de bilhões de dólares. Hoje, quase todos os sistemas comerciais de banco de dados relacional são sistemas de banco de dados "objeto-relacional".

Isso acabou por ser uma solução razoável. Hoje, nenhum dos produtos OODB existe na forma pretendida, e a idéia de "objetos persistentes" nas linguagens de programação foi amplamente descartada. Por outro lado, o uso de camadas ORM (Object-Relational Mapping) é generalizado, alimentado por trabalhos iniciais como Java Hibernate e Ruby on Rails, o que torna possível “customizar” bancos de dados declarativos com praticamente qualquer objeto imperativo. linguagem de programação orientada como bibliotecas. Essa abordagem no nível do aplicativo difere dos bancos de dados relacionais de objetos OODB e Stonebreaker. Além disso, os armazenamentos leves de valores-chave também são usados com sucesso em formas não transacionais e transacionais. O descobridor foi a estudante de graduação Stonebreaker Margo Seltzer, que trabalhou no banco de dados Berkeley DB como parte de sua dissertação de doutorado ao mesmo tempo que o grupo Postgres, que antecipou o crescimento de repositórios de valores-chave NoSQL distribuídos, como o Dynamo , MongoDB e Cassandra.

3. Impacto no software

3.1 Código aberto

O Postgres sempre foi um projeto de código aberto com lançamentos consistentes, mas no começo era destinado a ser usado para pesquisa e não para produção.

Quando o projeto de pesquisa do Postgres foi encerrado, dois estudantes de Stonebreaker, Andrew Yu e Jolly Chen, modificaram o analisador de sistema para substituir a linguagem original do Postquel por uma variante extensível do SQL. O primeiro lançamento do Postgres suportando SQL foi o Postgres95, e o próximo foi chamado PostgreSQL.

Uma equipe de desenvolvimento de código aberto ficou interessada no PostgreSQL e a “aceitou” mesmo quando os interesses do restante da equipe de Berkeley mudaram. A equipe principal do PostgreSQL permaneceu relativamente estável ao longo do tempo, e o projeto de código aberto tornou-se altamente desenvolvido. Inicialmente, os esforços foram focados na estabilidade do código e na funcionalidade visível ao usuário, mas, com o tempo, a comunidade de software de código aberto mudou e melhorou significativamente o núcleo do sistema, do otimizador ao acesso aos métodos e ao principal sistema de transações e armazenamento. Desde meados dos anos 90, uma fração muito pequena dos componentes internos do PostgreSQL veio da equipe acadêmica de Berkeley. Sua última contribuição pode ter sido minha implementação do GiST na segunda metade dos anos 90, mas mesmo foi substancialmente reescrita e liberada por voluntários da comunidade de código aberto (neste caso, a Rússia). A parte da comunidade de código aberto que trabalha no PostgreSQL merece os maiores elogios por seu processo simplificado, que por décadas serviu para criar um projeto altamente eficiente e de longo prazo.

Embora muita coisa tenha mudado nos últimos 25 anos, a arquitetura subjacente do PostgreSQL permanece muito semelhante às versões da universidade do Postgres no início dos anos 90, e os desenvolvedores familiarizados com o código fonte atual do PostgreSQL acharão fácil ler o código fonte do Postgres 3.1 (1991). Tudo, desde a estrutura de diretório do código-fonte às estruturas de processo e estruturas de dados, permanece surpreendentemente semelhante. O código da equipe do Postgres em Berkeley tinha uma grande espinha dorsal.

Hoje, o PostgreSQL é sem dúvida o sistema de gerenciamento de banco de dados de código aberto com melhor desempenho e suporta funcionalidades que geralmente não são encontradas em produtos comerciais. É também (de acordo com um influente site de classificação) o DBMS de código aberto independente mais popular do mundo, e sua influência continua a crescer: em 2017 e 2018, foi o banco de dados com a popularidade que mais cresce no mundo [ DE19c ]. O PostgreSQL é usado em uma ampla variedade de setores e tarefas, o que não é surpreendente, dado seu foco em amplas oportunidades.

Segundo a DB-Engines, o PostgreSQL hoje é o quarto DBMS mais popular do mundo, depois do Oracle, MySQL e MS SQL Server, todos os três oferecidos por empresas específicas (o MySQL foi adquirido pela Oracle há muitos anos) [ DE19a ]. As regras de classificação são discutidas na descrição da metodologia de classificação DB-Engines [ DE19b ].

Heroku é o provedor de nuvem SaaS que agora faz parte do Salesforce. O Postgres foi introduzido no Heroku em 2010 como o banco de dados padrão para sua plataforma. Heroku escolheu o Postgres por confiabilidade. Com o suporte do Heroku, plataformas de desenvolvimento de aplicativos maiores, como Ruby on Rails e Python para Django, começaram a recomendar o Postgres como o banco de dados padrão.

Hoje, o PostgreSQL suporta uma infraestrutura de extensão que facilita a adição de recursos adicionais ao sistema através de funções definidas pelo usuário e modificações relacionadas. Agora existe um ecossistema de extensões do PostgreSQL, semelhante ao conceito llustra de pacotes de extensão do DataBlade, mas com código-fonte aberto. As extensões mais interessantes incluem, por exemplo, a biblioteca Apache MADlib para aprendizado de máquina na interface SQL e a biblioteca Citus para execução de consultas paralelas.

Um dos aplicativos de código aberto mais interessantes criados no Postgres é o sistema de informações geográficas do PostGIS, usando muitos dos recursos do Postgres que originalmente inspiraram o Stonebreaker a iniciar o projeto.

3.2 Implementação comercial

O PostgreSQL tem sido um ponto de partida atraente para a criação de sistemas de banco de dados comerciais, devido ao seu uso sob a licença de software de código aberto "totalmente admissível", código confiável, flexibilidade e ampla funcionalidade. Resumindo os custos de aquisição listados abaixo, vemos que o Postgres recebeu mais de US $ 2,6 bilhões em custos de aquisição.

Observe que essa é uma medida em dólares das transações financeiras reais e é muito mais significativa do que os valores que são frequentemente usados em alta tecnologia. Números em bilhões são frequentemente usados para descrever o valor estimado de blocos de ações, mas geralmente são exagerados em 10 vezes ou mais em comparação com o valor presente, na esperança de seu significado futuro. Os dólares das transações de aquisição da empresa medem seu valor real de mercado no momento da aquisição. É justo dizer que o Postgres criou mais de US $ 2,6 bilhões em valor comercial real.

Muitos dos esforços comerciais associados ao PostgreSQL se concentraram no que provavelmente é sua principal limitação: a capacidade de escalar para uma arquitetura paralela sem compartilhar recursos.

A paralelização do PostgreSQL requer uma quantidade razoável de trabalho, mas é altamente viável por uma equipe pequena e experiente. Hoje, os ramos da indústria de código aberto do PostgreSQL, como Greenplum e CitusDB, oferecem essa oportunidade. É lamentável que o PostgreSQL não tenha sido adequadamente paralelizado em código aberto muito antes. Se o PostgreSQL tivesse sido expandido no código aberto com suporte para uma arquitetura sem compartilhamento de recursos no início dos anos 2000, é possível que a direção do big data de código aberto tivesse se desenvolvido de uma maneira completamente diferente e mais eficiente.

A Illustra foi a segunda maior startup do Stonebreaker, fundada em 1992 para comercializar o Postgres, quando a RTI lançou o Ingres no mercado.

Illustra era realmente o terceiro nome proposto para a empresa. Continuando o tema da pintura, chamado Ingres, Illustra foi originalmente chamado de Miro. Devido a problemas de marca comercial, o nome foi alterado para Montagem, mas também encontrou problemas de marca comercial.

A equipe fundadora incluiu parte do núcleo da equipe do Postgres, incluindo o recém-formado Wei Hong e o então programador-chefe Jeff Meredith, além de graduados de Ingres Paula Hawthorn e Michael Ubell. O aluno de pós-graduação Mike Olson ingressou logo após a fundação, e eu trabalhei na Illustra para otimizar recursos caros como parte do meu doutorado. 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 em retrospecto