Conheça o PostgreSQL Dinâmico: a evolução natural dos bancos de dados em nuvem

Começando hoje, você pode criar bancos de dados PostgreSQL dinâmicos em escala de tempo .

O PostgreSQL Dinâmico é a evolução natural dos bancos de dados em nuvem, resolvendo os problemas dos bancos de dados provisionados e dos bancos de dados sem servidor. Ele é apoiado por computação dinâmica, uma inovação de escala de tempo que dimensiona instantaneamente sua computação disponível dentro de um intervalo mínimo/máximo predefinido de acordo com sua carga. Em vez de provisionar para o seu pico (e pagar por isso sempre), agora você pode escolher um intervalo de computação: seu banco de dados operará na capacidade básica e acessará instantaneamente até o pico somente quando necessário. Compre a base, alugue o pico.

Isso resulta em um desempenho de preço incomparável: os clientes que executam cargas de trabalho de produção economizarão de 10 a 20% ao migrar do AWS RDS para PostgreSQL e de 50 a 70% ao migrar do AWS Aurora Serverless.

Você pode experimentar o Dynamic PostgreSQL hoje. Oferecemos uma avaliação gratuita – sem necessidade de cartão de crédito – que lhe dá acesso total à plataforma por 30 dias.

Para criar um serviço PostgreSQL Dinâmico, basta selecionar a opção PostgreSQL ao fazer login no Timescale:

Sua aplicação está sempre ativa, por que seu banco de dados não deveria estar?

Bem vindo ao futuro.

Problema 1: os desenvolvedores fornecem muito mais computação do que precisam

Nos últimos anos, desde que lançamos o Timescale, temos tido uma posição privilegiada sobre como os desenvolvedores usam os bancos de dados. Por exemplo, apenas nos últimos meses, analisamos mais de um trilhão de consultas como parte do nosso produto Insights.

Uma coisa que aprendemos é que os desenvolvedores geralmente fornecem muito mais computação do que realmente precisam.

Por um lado, isso faz sentido: você nunca vai querer se preocupar com seu banco de dados. A maioria das cargas de trabalho de banco de dados são contínuas, normalmente com alguma variabilidade ou intermitência. Por exemplo, um jogo que é mais utilizado à noite, um aplicativo comercial que é mais utilizado durante o dia ou um dispositivo doméstico conectado que é mais utilizado nos finais de semana do que durante a semana.

Você nunca quer que seu banco de dados fique sem recursos. Se o seu banco de dados estiver na capacidade máxima, isso levará a uma péssima experiência do cliente (ou nenhuma experiência do cliente!). Assim, a maioria dos desenvolvedores acaba provisionando o pico, além de um buffer. Isso faz com que os desenvolvedores paguem por muito mais computação do que realmente precisam.

Por outro lado, isso nos parece loucura. Que outros recursos de negócios as organizações estariam bem em gastar muito mais do que precisam? Computação desperdiçada é igual a dinheiro desperdiçado.

Problema 2: bancos de dados sem servidor são insuficientes para cargas de trabalho de produção

Alguns de vocês podem estar se perguntando: “E os bancos de dados sem servidor?”

O conceito de serverless originou-se de cargas de trabalho sem estado. Após o sucesso das máquinas virtuais na nuvem, onde os usuários puderam parar de se preocupar com hardware, eles perguntaram em seguida: por que se preocupar com a execução de servidores de aplicativos? Afinal, muitos usuários queriam apenas executar funções e serem cobrados apenas pelo tempo em que essas funções estavam em execução. E é fácil e contínuo ativar funções conforme necessário, quase precisamente porque elas não têm estado. Sem servidor – e função como serviço ou FaaS – se tornou um sucesso, com o AWS Lambda assumindo o controle.

Os desenvolvedores então se perguntaram: “Por que pagar pelo meu banco de dados quando não o estou usando?” A questão real é boa: recursos desperdiçados são um enorme problema de banco de dados. E a prática de provisionar um banco de dados AWS RDS em uma instância de servidor específica (digamos, um db.m6gd.2xlarge) certamente não parece moderna ou flexível: CPU fixa, memória fixa, disco local fixo. A maior parte é subutilizada na maior parte do tempo.

Mas é aqui que as coisas ficam complicadas: os bancos de dados são muito diferentes das funções Lambda.

Os bancos de dados sem servidor hoje são errados para a maioria das cargas de trabalho de produção por dois motivos principais:

• Os bancos de dados sem servidor concentram-se nos extremos para aumentar ou diminuir a escala, até mesmo até zero.

• Os bancos de dados sem servidor introduzem preços muito mais altos para compensar o “espaço” de recursos reservado para atender às demandas em constante mudança (e pior, muitas vezes com modelos de preços que são difíceis de entender ou prever).

  
  

Vamos começar discutindo o tema quente de “escalar até zero”. A realidade é que a maioria dos bancos de dados de produção não precisa e não se beneficiará da escalabilidade até zero.

Agora, existem alguns casos de uso em que “escalar até zero” faz sentido. Por exemplo, demonstrações de prova de conceito ou aplicações mais amadoras. A capacidade de executar ocasionalmente uma consulta ad-hoc em seu conjunto de dados (AWS Athena e Google BigQuery apresentam um forte argumento para um data warehouse em nuvem de baixo custo e sem servidor para uso muito intermitente). Outro caso de uso adequado seria evitar o esquecimento de desativação de uma instância de desenvolvimento em nuvem depois de concluída. Há valor em “pausar automaticamente” um banco de dados que não seja de produção (embora isso exija uma funcionalidade muito mais simples do que a prevista pelo serverless).

Mas para o seu banco de dados de produção e em ambientes mais operacionais? Você não quer escalar para zero.

Escalar para zero significa uma “inicialização a frio” na reinicialização: buffers compartilhados de banco de dados vazios, cache de sistema operacional vazio, caches de catálogo vazios (no caso do PostgreSQL).

(Sim, alguns bancos de dados sem servidor reduzem o tempo necessário para iniciar a execução do banco de dados, mas o fazem a partir de um estado vazio. Em um banco de dados relacional como o PostgreSQL, pode levar minutos (ou mais!) para construir um conjunto de trabalho quente novamente, especialmente para bancos de dados maiores.)

O impacto no desempenho da inicialização a frio é ainda maior, pois muitos bancos de dados sem servidor adotam diferentes arquiteturas de armazenamento em nuvem, onde o custo e a latência de buscar páginas de banco de dados do armazenamento remoto para a memória são ainda maiores. Essas sobrecargas levam novamente a um pior desempenho ou forçam os provedores de plataforma a compensar usando maiores recursos físicos (por exemplo, os bancos de dados Amazon Aurora têm o dobro da memória do RDS), um custo que, em última análise, é repassado aos usuários.

Assim, em muitos cenários, os bancos de dados sem servidor acabam tendo preços mais altos e imprevisíveis.

Por exemplo, se você comparar o Aurora Serverless com o Amazon RDS, verá que a computação de 8 vCPU e o armazenamento de 500 GB no Serverless são 85% mais caros que o RDS (US$ 1.097 versus US$ 593). E isso está usando o Aurora I/O Optimized e seus preços de armazenamento mais previsíveis, lançados há apenas seis meses. (Embora, mesmo aqui, ainda tenhamos que inferir sua capacidade de computação real, já que o preço do Aurora Serverless confundindo “unidades de capacidade Aurora” opacas, que, de acordo com nossas estimativas mais bem informadas, são 1 ACU = 0,25 vCPU.)

Anteriormente, com o Aurora Standard, os usuários também pagariam por cada operação de E/S interna, o que era quase impossível de prever ou orçamentar. Muitos bancos de dados sem servidor continuam cobrando por essas leituras e gravações. Na verdade, quando comparamos o AWS Timestream sem servidor, vimos custos que acabaram sendo mais de 100 vezes maiores do que com o Timescale devido a todos esses custos marginais mais elevados. A imprevisibilidade e a variabilidade dos custos eram o oposto da ausência de preocupações.

Resumindo, os bancos de dados sem servidor estão sujeitos a desempenho inferior, contas imprevisíveis e custos elevados à medida que as cargas de trabalho aumentam. Eles são adequados apenas para cargas de trabalho intermitentes que são ativadas apenas ocasionalmente e podem tolerar inicializações a frio devido à falta de cache de dados na memória.

O dilema do desenvolvedor

Foi aqui que acabamos:

• Muitos desenvolvedores ainda escolhem serviços DBaaS tradicionais com provisionamento para aplicações de produção devido ao seu desempenho confiável, controle e compreensão, mas odeiam o desperdício que surge da necessidade de provisionamento excessivo.

  
  

• Alguns desenvolvedores escolhem bancos de dados sem servidor por sua aparente economia de custos, flexibilidade e facilidade de uso, mas odeiam o impacto no desempenho e os preços imprevisíveis e obscuros (que muitas vezes resultam em contas misteriosamente mais altas do que uma instância provisionada).

  
  

Como desenvolvedores, nenhuma dessas opções é muito atraente! Existe uma oportunidade para melhor.

Solução: Apresentando o PostgreSQL Dinâmico

É por isso que desenvolvemos o PostgreSQL Dinâmico.

O PostgreSQL dinâmico oferece suporte consistente à sua linha de base e dimensiona perfeitamente a computação quando você precisa, até um valor máximo definido. Isso o torna perfeito para a variedade de cargas de trabalho contínuas que você normalmente vê em ambientes de produção (sejam uniformes, variáveis ou intermitentes).

O PostgreSQL Dinâmico é 100% PostgreSQL, com todos os benefícios da comunidade e do ecossistema PostgreSQL, além do maturidade da plataforma de banco de dados da Timescale . Para construir o PostgreSQL Dinâmico, inovamos na forma como operamos nossa infraestrutura PostgreSQL, em vez de modificar a parte interna do PostgreSQL. Isso lhe dá acesso a tudo o que o PostgreSQL — e a plataforma Timescale — oferece, sem o medo de executar uma consulta ou mecanismo de armazenamento bifurcado do PostgreSQL.

Com o Dynamic PostgreSQL, você escolhe um intervalo de computação (CPU mínima e máxima) correspondente às necessidades de sua carga de trabalho. Essa faixa de computação também vem com memória efetiva equivalente ao que a maioria dos serviços DBaaS tradicionalmente oferece na extremidade “máxima” da faixa de computação.

A base (mínima) do seu intervalo de CPU atua exatamente como o modelo DBaaS provisionado: a CPU mínima é sempre dedicada ao seu serviço para executar seu aplicativo. À medida que sua carga aumenta, seja devido à demanda do seu aplicativo externo ou mesmo devido a tarefas internas ocasionais do banco de dados, como backups incrementais ou aspiração automática de tabelas, seu banco de dados pode usar até o pico (máximo) da faixa de sua CPU sem atraso.

Como alcançamos atraso zero? A computação dinâmica funciona de maneira diferente de algumas outras ofertas de banco de dados sem servidor ou com escalonamento automático, portanto, não envolve o escalonamento lento (e o impacto no desempenho) que você normalmente vê em migrações remotas. Em vez disso, nossos algoritmos de configuração de infraestrutura e posicionamento de carga de trabalho garantem que os bancos de dados possam ser ampliados em seu nó subjacente sem reinicializações ou reconfigurações. Sua instância sempre tem acesso ao cálculo máximo conforme necessário.

E o melhor é que você paga apenas pela base mais o que usar acima dela. Chamamos esse modelo de escolha de uma faixa de computação e escalonamento entre ela de “ compre a base, alugue o pico ”.

Por exemplo, se você escolher uma opção de 4 a 8 CPUs, você sempre terá 4 CPUs dedicadas ao seu serviço e 32 GB de memória efetiva. Isso garante um bom desempenho de base em todos os momentos. Quando sua carga aumenta, seu aplicativo pode usar até 8 CPUs instantaneamente conforme necessário — medido e cobrado com base em CPU fracionada — e nunca mais de 8 CPUs se esse for seu limite máximo.

O modelo dinâmico permite “dimensionar” seu banco de dados de maneira mais econômica e sem preocupações. Você pode escolher um intervalo de computação onde sua demanda padrão atenda ao mínimo, mas você pode aumentar ou aumentar até o pico (máximo), conforme necessário. Esse máximo cria um limite inerente para qualquer uso acima da sua computação base, levando a um teto de custo fácil de entender. Além disso, cobramos a mesma taxa por hora de CPU (fracionária) tanto para sua base quanto para qualquer uso medido acima dela: não há cobrança adicional pelo uso acima de sua base e, portanto, nenhuma penalidade de preço pelo escalonamento.

Por fim, se você perceber que provisionou um intervalo de tamanho muito baixo ou muito alto, poderá ajustar facilmente o intervalo de computação para um tamanho que melhor atenda às necessidades do seu aplicativo.

Projetado para economizar seu dinheiro

Atualmente, oferecemos cinco intervalos de computação diferentes com base no tamanho da sua carga de trabalho, com memória efetiva correspondente que você recebe para o intervalo, independentemente do seu uso instantâneo.

O Dynamic PostgreSQL também usa o armazenamento baseado em uso do Timescale, onde você paga apenas pelo volume de dados armazenados (em GB-hora), não pelo tamanho do disco provisionado. Não se preocupe em desperdiçar dinheiro com um disco superprovisionado ou com a possibilidade de ficar sem espaço em disco. A infraestrutura de nuvem dinâmica do Timescale garante que você tenha capacidade de armazenamento suficiente, quando precisar, e que pague apenas pelo que usar.

Desenvolvemos o Dynamic PostgreSQL intencionalmente para economizar seu dinheiro. Os clientes que executam cargas de trabalho de produção normalmente economizam de 10 a 20% ao migrar do AWS RDS para PostgreSQL e de 50 a 70% ao migrar do AWS Aurora Serverless.

No final do mês, sua fatura consiste em duas métricas simples e fáceis de entender: (1) seus custos de computação, cobrados como sua computação base por hora mais qualquer uso fracionário de CPU acima dele, mas não mais do que seu pico; e (2) seus custos de armazenamento, cobrados como consumo de dados em GB-hora. Não existem novas métricas ou unidades derivadas para medir ou compreender.

Pague apenas pelo que você usa. Zero custos extras ou taxas ocultas.

• Computação: previsível, com base em um intervalo definido

• Armazenamento: pague apenas pelo que você armazena

  
  

Sem desperdício de recursos. Sem pagar a mais. Não perca o sono à noite. Uma conta que você pode explicar ao seu chefe.

Experimente hoje

Você pode experimentar o Dynamic PostgreSQL hoje! Timescale oferece um teste gratuito —sem necessidade de cartão de crédito—que lhe dá acesso total à plataforma por 30 dias. Para criar um serviço PostgreSQL Dinâmico, basta selecionar a opção PostgreSQL ao fazer login no Timescale:

A plataforma agora oferece dois tipos de serviços para atender às necessidades específicas de seus bancos de dados:

• Os serviços de série temporal são projetados para aumentar a velocidade de consulta e a escalabilidade para suas cargas de trabalho mais exigentes, oferecendo recursos importantes de escala de tempo, como hipertabelas, compactação colunar, agregações contínuas e armazenamento em camadas. Use-os para hospedar dados de sensores, métricas de energia, dados financeiros, eventos e outras cargas de trabalho com uso intensivo de dados.

  
  

• Os serviços PostgreSQL são serviços Postgres dinâmicos otimizados para economia e facilidade de uso. Use-os para seus bancos de dados somente relacionais, por exemplo, registros comerciais.

  
  

Depois de selecionar “PostgreSQL”, configurar seu serviço Dynamic PostgreSQL é muito simples. Selecione sua região, seu intervalo de computação dinâmica e suas opções de alta disponibilidade e pooling de conexões – boom! 💥 Agora você tem um banco de dados PostgreSQL dinâmico pronto para uso em produção.

Se você tiver quaisquer perguntas, entre em contato conosco . Adoraríamos ouvir seus comentários e ajudá-lo com seu caso de uso do PostgreSQL (série temporal ou não)!

Isto é apenas o começo. Estamos no meio de três semanas consecutivas de lançamento e este é apenas o começo da Semana 2: Semana de Infra Dinâmica. Fique ligado para mais nesta semana, neste mês, neste ano e nos muitos anos que virão. 🙂

- Escrito por Mike Freedman e Grant Godeke.