banco de dados de 100 terabytes no PostgreSQL sem sharding

Question

É realista configurar um banco de dados de 100 TB (na verdade, cerca de 90 TB) no PostgreSQL sem compartilhamento de dados entre um número de nós? Existem histórias / exemplos de sucesso sobre configurações semelhantes?

    

Answer 1

50 mil gravações por segundo que precisam ser absorvidas são mais do que um desafio normalmente. Mesmo em benchmarks sintéticos com inserções bastante simples, os limites do PostgreSQL tendem a aumentar em torno de 10 K / s - e lá você nem tem uma grande fera em termos de tamanho de banco de dados.

Além disso, o sistema de E / S para esse único nó do PostgreSQL será interessante, mesmo com o RAID 10 e assumindo que as inserções de 50K serão iguais a apenas 50K IOPS (o que provavelmente está errado, mas depende do banco de dados esquema e índices), você precisará de aproximadamente uma centena de discos emparelhados com uma matriz muito boa que evita que você compre centenas de discos para atender as gravações de maneira oportuna.

Se o sharding for fácil e você espera uma carga de gravação tão grande, vá para sharding. As gravações podem ser muito difíceis de escalar.

    

Answer 2

Peço desculpas pela minha franqueza

Se você tem o dinheiro ou até mesmo a necessidade de 90 TB de armazenamento de dados, então é exatamente onde você NÃO deveria perguntar. Existem muitas empresas por aí que vendem esse tipo de produto e habilidades (EMC) e, para isso, você obtém um produto sólido. Você está enganando a si mesmo, se você acha que esta é uma área que você pode economizar dinheiro fazendo você mesmo. Especialmente se você tiver que perguntar à comunidade.

Isso não é algo em que você tenta economizar dinheiro; isso é algo que você acertar a primeira vez. Vá ligar para a HP, Dell, EMC, etc ... E pergunte a eles sobre isso; eles ficarão mais felizes em lhe dar conselhos PROFISSIONAIS e também vender um produto. Se algo assim acontecer, você ou a empresa provavelmente não terão uma segunda chance.

Uma empresa pode ir à falência a partir de uma única unidade de backup de fita quebrada; imagine o custo de 90 TB de dados sendo perdidos! Isso não é algo que você queira viver.

Obtenha um produto profissional e, se você achar que não é algo que possa pagar, reconsidere seriamente as prioridades da sua empresa.

    

Answer 3

É realista e funcionará. O desempenho depende em grande parte de quanto você tem de RAM. Quanto maior a RAM, maior o cache e mais o PostgreSQL pode armazenar dados em cache antes de descarregar para o disco.

O PostgreSQL grava dados no cache e descarrega o cache de tempos em tempos. Portanto, 50k INSERTs por segundo não serão convertidos para 50k IOPS. Será bem menos, porque agrupará registros e os escreverá todos ao mesmo tempo.

Um banco de dados tão grande não é um problema se a maioria do trabalho for INSERT. O PostgreSQL terá que alterar os índices aqui e ali, mas isso é realmente uma tarefa fácil. Se você tivesse muitos SELECTs em um banco de dados desse tamanho, seria necessário fragmentar.

Uma vez trabalhei em um Oracle DB (Oracle 10g) com 400 TB em um servidor de 16 GB, apenas uma instância. A carga de trabalho do banco de dados também era de INSERTs primários, portanto, alguns SELECTs por dia e milhões de INSERTs todos os dias. O desempenho estava longe de ser um problema.

    

Answer 4

Em 100 TB, você tem alguns desafios importantes. Se vai funcionar para você ou não, depende de como você quer resolver isso.

1. Você precisa de maneiras suficientes para absorver a carga de gravação. Isso depende da carga de gravação. Mas com armazenamento suficientemente impressionante, isso pode ser resolvido. A velocidade é um grande problema aqui. Da mesma forma, o acesso de leitura deve ser analisado com cuidado.

2. A maioria dos bancos de dados não consiste em um monte de pequenas tabelas, mas geralmente tem uma ou duas realmente grandes, que podem ter até a metade do tamanho do banco de dados. O PostgreSQL tem um limite rígido de 32 TB por tabela. Depois disso, o tipo de letra fica sem contadores de páginas. Isso pode ser feito por uma compilação personalizada do PostgreSQL ou pelo particionamento de tabelas, mas é um desafio sério que precisa ser resolvido inicialmente.

3. O PostgreSQL tem limites reais em quanto de RAM ele pode usar para várias tarefas. Então, ter mais memória RAM pode ou não ajudá-lo além de um certo ponto.

4. Backups .... Os backups são interessantes nessa escala. O banco de dados de 60 TB que eu conheço teve que usar backups instantâneos de fs e depois falsificar os backups para o barman para arquivamento wal. Esses backups falsos eram proxies para backups de snapshots de fs. Como eu disse "Eles não são backups falsos. Eles são backups alternativos!"

Existem pessoas com bancos de dados que se aproximam desse intervalo. Eu conheci pelo menos um indivíduo que trabalhou para um banco na Holanda que tinha um banco de dados PostgreSQL de 60 TB. No entanto, realmente, realmente depende de sua carga de trabalho e tamanho por si só não é o problema.