O dimensionamento de bancos de dados PostgreSQL ficou mais barato: o armazenamento em camadas do Timescale atinge a disponibilidade geral

Produtos como o Amazon RDS para PostgreSQL são adequados para implantações menores, mas dimensionar o PostgreSQL é uma história diferente. Quando o projeto atinge muitos terabytes, esses bancos de dados gerenciados ficam lentos e caros, tornando o gerenciamento de dados muito mais complexo.

O desempenho é prejudicado quando as tabelas atingem bilhões de linhas e, embora existem maneiras de melhorá -lo , os dados continuarão crescendo. Sem o gerenciamento de dados adequado, os desenvolvedores só podem observar o aumento de tamanho de seus discos (e contas).

Mas não mais. Hoje, temos o prazer de anunciar a disponibilidade geral do armazenamento em camadas, uma arquitetura de armazenamento em várias camadas projetada para permitir escalabilidade infinita e de baixo custo para suas séries temporais e bancos de dados analíticos na plataforma Timescale. Agora você pode armazenar seus dados mais antigos e acessados com pouca frequência em um nível de armazenamento de baixo custo e ainda poder acessá-los, sem nunca sacrificar o desempenho dos dados acessados com frequência.

Isto é o que acontece quando você insere dados em um banco de dados de série temporal de escala temporal com nosso novo back-end de armazenamento multicamadas:

1. Seus dados mais recentes serão gravados em um nível de armazenamento de alto desempenho otimizado para consultas rápidas e altas ingestões.

   
   

2. Uma vez que você não acessa esses dados com frequência, você pode colocá-los automaticamente em camadas para uma camada de armazenamento de objetos de custo mais baixo , configurando uma política de camadas. Os dados na camada de armazenamento de baixo custo permanecem totalmente consultáveis em seu banco de dados e não há limite para a quantidade de dados que você pode armazenar – até centenas de TB ou mais. Nosso nível de armazenamento de baixo custo tem um preço fixo de US$ 0,021 por GB/mês para dados – mais barato que o Amazon S3.

Os desenvolvedores precisam de uma maneira barata de dimensionar seus grandes bancos de dados PostgreSQL na AWS sem comprometer o desempenho. Embora os armazenamentos de objetos sejam incrivelmente escaláveis e acessíveis, eles não são os mais rápidos, e os desenvolvedores também precisam obter respostas de consulta em milissegundos para seus aplicativos.

No entanto, quando os dados se tornam mais antigos e raramente acessados, o desempenho em tempo real muitas vezes não é tão essencial. Os desenvolvedores ainda precisam acessar esses dados históricos para consultas ad hoc, análise de dados ou conformidade regulatória, mas podem assumir alguma latência para esses tipos de consultas. Agora, o que os desenvolvedores desejam é a capacidade de armazenar esses dados históricos da maneira mais econômica e eficiente possível.

Essa nova arquitetura de armazenamento em camadas libera os desenvolvedores de escolher entre custos de armazenamento e compensações de desempenho para aplicativos em tempo real. Ao manter seus dados recentes e acessados com frequência na camada de alto desempenho, eles aproveitarão a velocidade de consulta em milissegundos e os recursos de ingestão do Timescale e, ao hierarquizar seus dados mais antigos, poderão manter quantos TBs forem necessários em seus bancos de dados PostgreSQL para menos.

Gerenciamento de dados PostgreSQL com armazenamento em camadas: o que você precisa saber

A arquitetura Tiered Storage do Timescale aproveita a flexibilidade do PostgreSQL e hipertabelas para um gerenciamento de dados eficaz. Ao criar uma hipertabela, ela agora pode se estender perfeitamente pelas duas camadas de armazenamento; quando você executa uma consulta , o Timescale descobre perfeitamente quais níveis de armazenamento acessar para gerar a resposta, aumentando o desempenho dos dados mais recentes e reduzindo os custos de armazenamento dos dados mais antigos. Não há cobrança extra por consulta ou leitura de dados nem taxas ocultas, permitindo um gerenciamento de dados simples e econômico.

Essa arquitetura de armazenamento também elimina quaisquer limitações de armazenamento nos serviços Timescale: como nosso nível de armazenamento de baixo custo é infinito, você pode armazenar quantos TB desejar. Por exemplo, estamos aproveitando o Tiered Storage internamente para armazenar o enorme banco de dados Timescale que alimenta nosso produto Insights.

Esse banco de dados do Insights coleta e analisa constantemente estatísticas de consulta de toda a nossa frota de clientes e já ultrapassou 350 TB hoje e está crescendo rapidamente. Desses 350 TB, 250 TB são escalonados para armazenamento de baixo custo.

Vamos fazer as contas:

• Armazenamos 5 TB em nosso nível de armazenamento de alto desempenho após a compactação. Claro, temos a compactação habilitada e estamos obtendo taxas de compactação de 20x – o que significa que o que originalmente eram 100 TB de dados do Postgres agora cabe em um disco de 5 TB graças à compactação (!)

  
  

• Os 250 TB restantes de dados são armazenados na camada de armazenamento de baixo custo. Essa hierarquização acontece automaticamente quando os dados atingem uma determinada idade, que atualmente tem várias semanas.

  
  

Nossos clientes com grandes implantações também já estão utilizando o Tiered Storage:

"Realizamos muitas análises de dados de mercado, e o grande volume de dados que precisamos armazenar torna inviável uma solução normal de banco de dados baseada em disco (é muito caro). O Tiered Storage da Timescale nos permite mover perfeitamente grandes volumes de dados para a camada de armazenamento de objetos. Esta é uma ótima solução para armazenar grandes volumes de dados históricos e realizar pós-análise. Sem isso, seríamos forçados a desenvolver uma solução internamente."

- Diretor de Tecnologia em uma empresa proprietária de comércio de ativos digitais

Simplicidade é o principal recurso do Tiered Storage. Para mover seus dados da camada de alto desempenho para a camada de objeto de baixo custo, tudo o que você precisa fazer é usar nosso API simples para definir políticas para hierarquizar seus dados à medida que envelhecem em uma hipertabela específica. As políticas de hierarquização de dados funcionam com base em blocos (a política irá hierarquizar blocos completos quando atingirem a idade definida pela política). Não há necessidade de processos ETL (extrair-transformar-carregar) ou alterações de infraestrutura.

Por exemplo, esta política moveria todos os dados com mais de um mês para o armazenamento de objetos na sua hipertabela events :

 SELECT add_tiering_policy('events', INTERVAL '1 month');

Isso é tudo que você precisa! Todo o resto acontece automaticamente, incluindo o planejamento inteligente de consultas que executa apenas consultas SQL na camada apropriada.

Para descartar dados atualmente armazenados na camada de armazenamento de baixo custo, você pode definir uma política de retenção de dados para que os dados sejam excluídos automaticamente após um determinado período (por exemplo, após cinco anos). Você também pode excluir manualmente pedaços específicos .

Além disso, se você quiser “retroceder” um pedaço específico da camada de armazenamento de baixo custo para a camada de alto desempenho ( por exemplo, se você precisar preencher ou atualizar dados ), você pode facilmente “desmontá-lo”.

 -- Untier a particular chunk CALL untier_chunk('_hyper_1_1_chunk');

Você pode acompanhar quantos dados foram hierarquizados (e quanto custarão no final do mês) no console Timescale:

E falando em estimativas de faturamento…

Quanto posso economizar com o armazenamento em camadas?

Nosso nível de armazenamento de alto desempenho tem um preço efetivo de US$ 0,177 por GB/mês de dados após compressão (considerando a taxa de compressão esperada que vemos em toda a nossa frota). A isso agora se junta uma camada de armazenamento de baixo custo com uma taxa fixa de US$ 0,021 por GB/mês de dados, com o mesmo preço em todas as regiões de nuvem.

Ao hierarquizar os dados, você pagará apenas pelos dados armazenados , não pelas consultas executadas ou pela quantidade de dados verificados: esse é realmente um preço fixo. Nosso objetivo com essa estrutura de preços era fornecer uma maneira transparente, inequívoca e simples de calcular o custo total de armazenamento de dados, facilitando o gerenciamento de seus dados.

Como um exemplo rápido, digamos que você tenha uma hipertabela com 5,2 TB de armazenamento, com pedaços recentes da hipertabela e outras tabelas do Postgres ocupando aproximadamente 200 GB e cerca de 5 TB de dados da hipertabela com mais de um mês. Você não acessa ou consulta esses dados mais antigos com frequência, o que significa que não precisa deles para as operações diárias do seu aplicativo. Ainda assim, você gostaria de mantê-lo acessível em seu banco de dados para consultas ad hoc ou requisitos de conformidade (vemos muitos casos assim entre nossos clientes).

Como uma estratégia de gerenciamento de dados econômica, você pode nivelar todos os blocos com mais de um mês para o nível de baixo custo e diminuir o custo de armazenamento desses 5 TB de dados de cerca de US$ 478/mês para cerca de US$ 105/mês, uma redução de 78%. em sua conta de armazenamento. ( Para esta estimativa, presumimos que você ativou a compactação para sua hipertabela e consideramos a compactação geral mediana em todos os serviços de escala de tempo).

A economia aumentará junto com seus dados: ao mover vários terabytes para esse nível de baixo custo, sua conta de armazenamento diminuirá de milhares de dólares para algumas centenas. A tabela de referência a seguir ilustra o quão acessível é realmente nosso nível de armazenamento de baixo custo.

Você entendeu!

O efeito multiplicador da economia do Tiered Storage

Há mais uma coisa que torna o armazenamento em camadas ainda mais incrível: quando você mantém os dados na camada de armazenamento de baixo custo, você paga por esses dados apenas uma vez, independentemente de ter uma réplica de alta disponibilidade ou réplicas de leitura em execução no seu serviço. .

O mesmo se aplica aos garfos. No Timescale, você pode criar cópias do seu banco de dados primário (nós os chamamos de forks) clicando em um botão da UI, por exemplo, para executar testes ou criar ambientes de desenvolvimento. Ao criar uma (ou mais) bifurcações, você não será cobrado pelos dados compartilhados com o primário no armazenamento de baixo custo . Se decidir hierarquizar mais dados que não estão no primário, você pagará para armazená-los no nível de baixo custo, mas ainda se beneficiará de economias substanciais ao movê-los do nível de alto desempenho do fork para o nível mais barato. .

Para deixar isso bem claro, vamos apresentar um exemplo. Imagine que você tem um serviço primário com 6,5 TB de dados e que também configurou:

• Uma réplica de alta disponibilidade para reduzir significativamente o risco de tempo de inatividade e perda de dados devido a falhas

  
  

• Uma réplica de leitura para atender suas consultas de leitura e permitir que o primário se dedique totalmente às gravações

  
  

• Uma bifurcação desse serviço para fins de desenvolvimento e teste

  
  

De uma perspectiva de faturamento, se você mantivesse os 6,5 TB de dados em seu serviço primário na camada de armazenamento de alto desempenho, você veria refletido [6,5 TB x 4] em sua fatura de armazenamento para contabilizar as duas réplicas, a bifurcação e o serviço primário – 26 TB no total. Assumindo nossa taxa de compressão média, isso seria caro: cerca de US$ 4.602/mês.

Mas o que acontece se o seu aplicativo precisar acessar ativamente apenas os 500 GB de dados mais recentes? Você poderia nivelar 6 TB para armazenamento de baixo custo e manter apenas 500 GB em seu nível de armazenamento de alto desempenho. E como você paga apenas uma vez pelos dados em seu nível de armazenamento de baixo custo, sua nova fatura de armazenamento seria assim:

• [500 GB x 4] = 2 TB em armazenamento de alto desempenho (em vez de 26 TB)

  
  

• [6 TB x 1] no nível de armazenamento de baixo custo

  
  

A conta de armazenamento acima chegaria a aproximadamente US$ 480/mês: você economizaria mais de US$ 4.000/mês! Este é o efeito multiplicador da economia do Tiered Storage. Especialmente se você estiver executando réplicas ou bifurcações, é uma ótima ideia aproveitar as vantagens do nível de armazenamento de baixo custo – a economia que você verá na sua conta geral será muito significativa.

Nossa jornada de armazenamento em camadas

Lançamos uma versão inicial de nossa funcionalidade Tiered Storage na plataforma Timescale como Early Access em março. Depois de muitas melhorias, atingiu agora a Disponibilidade Geral. Desde seu primeiro lançamento, trabalhamos duro para tornar o Tiered Storage estável, confiável e mais rápido.

Também pensamos muito sobre nosso modelo de precificação, repetindo consistentemente diversas maneiras de precificar nosso nível de armazenamento de baixo custo. Por fim, optamos pelo mais simples: uma taxa fixa sobre a pré-compressão do volume de dados. Já mencionamos como valorizamos preços simples e previsíveis, mas também era importante para nós fornecer um preço por GB/mês o mais baixo possível. Nosso preço chegou a US$ 0,021 – como comparação, o armazenamento de arquivos no Amazon S3 custa US$ 0,023 por GB/mês .

Pessoalmente, eu (Yannis) devo admitir que, depois de liderar equipes construindo soluções nativas da nuvem por mais de uma década, ainda tenho que voltar atrás e, ocasionalmente, verificar novamente várias tabelas de taxas em várias páginas de preços da nuvem, especialmente em busca de taxas extras, sempre que isso acontece. Quero calcular com precisão os custos totais dos nossos serviços.

Na Timescale, acreditamos que você não deveria ter que criar uma planilha complicada para poder executar um serviço de banco de dados ou fazer escolhas informadas sobre camadas de armazenamento.

Nosso compromisso de facilitar a vida dos desenvolvedores nos levou à taxa fixa de US$ 0,021 por GB/mês — sem suposições, custos ocultos ou cobranças por consulta ou leitura de dados.

Como funciona o armazenamento em camadas: nos bastidores

Todos os dados inseridos no Timescale são inicialmente gravados em nossa camada de armazenamento de alto desempenho. Usar discos mais rápidos para seus dados mais recentes proporcionará o melhor desempenho de inserção e consulta para seus valores mais recentes, um padrão de uso que atende às necessidades de aplicativos com uso intensivo de dados.

Pelo contrário, a camada de armazenamento de baixo custo é um armazenamento de objetos criado no Amazon S3. Esse armazenamento de objetos é muito mais do que um depósito externo para arquivar seus dados: é parte integrante do seu banco de dados. Quando você move dados para essa camada de armazenamento de objetos, seu banco de dados permanecerá totalmente ciente de toda a semântica e metadados, e você poderá continuar consultando normalmente com SQL padrão (embora com desempenho mais lento).

Nos bastidores, armazenamos os dados em um formato colunar compactado (especificamente, Apache Parquet ). Quando os dados são hierarquizados, os pedaços armazenados no formato de banco de dados interno nativo do Timescale (normalmente em nosso compressão colunar nativa ) são convertidos de forma assíncrona para o formato Parquet e armazenados no objeto S3 subjacente. Construímos vários mecanismos para garantir que os pedaços em camadas sejam armazenados de forma durável na camada de armazenamento de baixo custo antes de removê-los transacionalmente da camada de alto desempenho.

Quando você executa sua consulta SQL, ela extrai dados de forma transparente da camada de armazenamento de alto desempenho, da camada de armazenamento de objetos ou de ambas, conforme necessário. Quando dizemos transparente, queremos dizer transparente: o Timescale oferece suporte a consultas arbitrariamente complexas em seus dados padrão e em camadas, incluindo predicados complexos, JOINs, CTEs, janelas, hiperfunções e muito mais.

No exemplo de consulta abaixo (com uma cláusula EXPLAIN ), você pode ver como o plano de consulta inclui uma Foreign Scan quando o banco de dados está acessando dados da camada de armazenamento de objetos. Neste exemplo, devices e sites são tabelas Postgres padrão (que residem apenas em armazenamento de alto desempenho), enquanto metrics são uma hipertabela que se estende por ambas as camadas de armazenamento. Ao executar esta consulta na hipertabela metrics , três de seus pedaços foram lidos do armazenamento padrão e cinco pedaços foram lidos do armazenamento de objetos.

 EXPLAIN SELECT time_bucket('1 day', ts) as day, max(value) as max_reading, device_id FROM metrics JOIN devices ON metrics.device_id = devices.id JOIN sites ON devices.site_id = sites.id WHERE sites.name = 'DC-1b' GROUP BY day, device_id ORDER BY day; QUERY PLAN ---------------------------------------------------------- GroupAggregate Group Key: (time_bucket('1 day'::interval, _hyper_5666_706386_chunk.ts)), _hyper_5666_706386_chunk.device_id -> Sort Sort Key: (time_bucket('1 day'::interval, _hyper_5666_706386_chunk.ts)), _hyper_5666_706386_chunk.device_id -> Hash Join Hash Cond: (_hyper_5666_706386_chunk.device_id = devices.id) -> Append -> Seq Scan on _hyper_5666_706386_chunk -> Seq Scan on _hyper_5666_706387_chunk -> Seq Scan on _hyper_5666_706388_chunk -> Foreign Scan on osm_chunk_3334 -> Hash -> Hash Join Hash Cond: (devices.site_id = sites.id) -> Seq Scan on devices -> Hash -> Seq Scan on sites Filter: (name = 'DC-1b'::text)

No plano de consulta acima, a Foreign Scan on osm_chunk_3334 corresponde à busca de dados da camada de armazenamento de objetos sem fundo.

Para evitar que os pedaços de processamento fiquem fora da janela de tempo da consulta, realizamos a exclusão de pedaços para tocar apenas nos pedaços necessários para satisfazer a consulta. O banco de dados armazena várias formas de metadados para construir um “mapa” de grupos de linhas e deslocamentos de colunas no armazenamento de objetos.

Além disso, quando uma consulta é executada, ela é ainda mais seletiva quanto aos dados que lê. Se sua consulta afetar apenas um intervalo de linhas e algumas colunas, apenas esse subconjunto de dados será lido no objeto S3 atrás da camada de armazenamento de baixo custo.

Acima, por exemplo, apenas as colunas device_id e value são lidas na camada de armazenamento de objetos. Se um filtro WHERE baseado em tempo adicional tivesse sido incluído, o banco de dados usaria primeiro seus metadados (armazenados em armazenamento de alto desempenho e armazenados em cache na memória) para reduzir ainda mais quais arquivos Parquet e grupos de linhas precisam ser lidos para executar a consulta. Tudo para reduzir a latência de consulta mesmo ao acessar esse armazenamento sem fundo de forma transparente através do PostgreSQL.

Experimente o armazenamento em camadas

As decisões de armazenamento relacionadas a dados históricos não precisam ser caras. No Timescale, agora você tem acesso a um nível de armazenamento infinito e de baixo custo, sem problemas de preço, que permite dimensionar o armazenamento do seu banco de dados por um preço acessível, sem comprometer o desempenho do seu aplicativo.

Se você está se perguntando se esta é uma boa solução para seu caso de uso, confira nossos documentos para obter mais informações e ajustes de caso de uso. Se você está procurando uma perspectiva mais prática, você também pode experimentar Tiered Storage gratuitamente na plataforma Timescale por meio de nosso teste gratuito (sem necessidade de cartão de crédito) .

- Escrito por Yannis Roussos, Carlota Soto e Ana Tavares.