É realista configurar um banco de dados de 100 TB (aproximadamente 90 TB) no PostgreSQL sem compartilhamento de dados entre vários nós? Existem histórias / exemplos de sucesso sobre configurações semelhantes?
database
postgresql
lagarto
fonte
fonte
Respostas:
50 mil gravações por segundo que precisam ser absorvidas é mais do que um desafio normalmente. Mesmo em benchmarks sintéticos com inserções bastante simples, os limites do PostgreSQL tendem a atingir cerca de 10 K / s - e você nem tem uma fera tão grande em termos de tamanho do banco de dados.
Além disso, o sistema de E / S para esse único nó do PostgreSQL também 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 esquema e dos índices do banco de dados). ), você precisará de aproximadamente cem discos emparelhados com uma matriz muito boa, para evitar a compra de várias centenas de discos para atender essas gravações em tempo hábil.
Se o sharding for fácil e você espera uma carga de gravação tão grande, escolha sharding. As gravações podem ser muito difíceis de dimensionar.
fonte
É realista e vai funcionar. O desempenho depende muito da quantidade de RAM que você possui. Quanto maior a RAM, maior o cache e mais o PostgreSQL pode armazenar em cache os dados 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 traduzidos para 50k IOPS. Será muito menor, porque agrupará os registros e gravará todos eles ao mesmo tempo.
Um banco de dados desse tamanho não será um problema se a maioria do trabalho for INSERT. O PostgreSQL precisará alterar os índices aqui e ali, mas esse é realmente um trabalho fácil. Se você tivesse muitos SELECTs em um banco de dados desse tamanho, realmente precisaria fazer o shard.
Certa vez, trabalhei em um banco de dados Oracle (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 INSERTs primária, portanto, alguns SELECTs por dia e milhões de INSERTs todos os dias. O desempenho estava longe de ser um problema.
fonte
Com 100 TB, você tem alguns desafios importantes. Se funcionará ou não para você, depende de como você deseja resolvê-los.
Você precisa de maneiras suficientes para absorver a carga de gravação. Isso depende da carga de gravação. Mas com armazenamento suficientemente impressionante, ele pode ser resolvido. A velocidade é um grande problema aqui. Da mesma forma, o acesso de leitura deve ser analisado com cuidado.
A maioria dos bancos de dados não consiste em várias tabelas pequenas, mas geralmente possui 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 maré fica sem contadores de páginas. Isso pode ser tratado por uma compilação personalizada do PostgreSQL ou pelo particionamento de tabelas, mas é um sério desafio que precisa ser abordado primeiro.
O PostgreSQL possui limites reais de quanta RAM ele pode usar para várias tarefas. Portanto, ter mais memória RAM pode ou não ajudá-lo além de um certo ponto.
Backups .... Os backups são interessantes nessa escala. Os db de 60 TB que eu conheço precisavam usar backups de snapshots fs e depois falsificar os backups do barman para arquivamento wal. Esses backups falsos eram proxies para backups de instantâneo fs. Como eu disse "Eles não são backups falsos. São backups alternativos!"
Existem pessoas com bancos de dados que se aproximam desse intervalo. Eu conheci pelo menos um indivíduo que trabalhava para um banco na Holanda que tinha um banco de dados PostgreSQL de 60 TB. No entanto, depende realmente da sua carga de trabalho e o tamanho por si só não é o problema.
fonte