Reduzi um DB de 8TB para 218 GB! como? ClickHouse!

UAU. lendo seu comentario me interessei mais ainda sobre esse DB. me parece algo muito incrivel e pouco divulgado hahaha.

gostei bastante de seus exemplos, nao tinha conhecimento dessas diferenças.

em especifico sobre como deduplicar linhas. poderia me explicar como fazer isso? seria bastante util no meu cenario atual, já que os inserts volumosos sempre apresentam dados duplicados e acabo tendo que remover essas duplicações na aplicação pra nao quebrar as contagens

eu acredito que uns 30%
porque esse DB PostgreSQL foi recriado tem menos de 1 mes.
o DB anterior, também PostgreSQL, tinha 5tb mas tinha um esquema diferente, recriamos o DB e modificamos o particionamento dele pra melhorar as consultas e com isso ele saltou pra 7tb,

então imagino que só de dados seja 4-5tb em media, o restante são indices e um pouco de bloat.
mas o bloat nesse DB ate um tempo atrás era minino, pois os dados nele nao sofrem alterações, são apenas inserts e depois selects, recentemente que os deletes começaram a a ser feitos constantemente, então o bloat pode ter aumentado (mas continuo fazendo vacuum constante dele quando dá)

seria interessante mesmo. mas poderia me explicar melhor sobre o duck DB? ate vi algumas comparações dele com o clickhouse, mas o duck DB me pareceu um SQLite colunar, então nao sei se atenderia a demanda nesse meu caso.

hahaha, realmente esperava uma queda nas consultas.
e de fato inicialmente teve.

tanto que o meu primeiro teste com um DB menor (57gb) as consultas gerais ficaram em media 2x mais lentas do que em comparação com o timescale DB.
mas porque?
estudando mais a fundo, descobri que o clickhouse começa a brilhar em uma grande massa de dados, e o primeiro DB que eu testei era relativamente pequeno, então o PostgreSQL ainda estava dando conta com todos os indices e cache que ele gera (apesar de ocupar 97% mais disco).
porem, a realidade mudou nesse DB de 8tb, justamente porque nele ja temos 44bi de dados, nisso o PostgreSQL já estava dando sinais de sobrecarga e o clickhouse tirando de letra.

isso sem contar a redução de disco nos dois casos.

mas algo que ajudou bastante a velocidade nas consultas: views materializadas + tabelas de agregação.

isso tornou as consultas que ja eram rápidas, quase instantâneas.

e, pra nao dizer que ficou uma comparação injusta, eu tentei semanas atrás criar esse mesmo arranjo no PostgreSQL, mas ficou inviável, a materialização das views estava consumindo quase a CPU toda, coisa que no clickhouse é mínimo.

sobre como é possível que as consultas ficaram rápidas: o clickhouse é focado nisso, tanto que, ao criar a tabela, vc ja define um "order by" de acordo com a natureza das consultas, e isso acelera absurdamente elas.

como o sistema que trabalho sempre procura na mesma ordem de dados, foi um salto incrível de velocidade.

Cara, ate o momento, só identifiquei detalhes mínimos, como ter que refazer as consultas pra tirar máximo proveito do clickhouse e de como ele opera.

atualmente a API que fornece os dados do DB esta adaptada pra puxar linhas brutas, mas como o clickhouse se dá melhor com contagens, somas e agrupamentos de dados, estou precisando mudar algumas funções pra já esperar isso direto do DB. antes essas agregações eram feitas na aplicação (por conta de desempenho mesmo), mas agora vão ser feitas no DB (que é até o ideal de ser feito)

outra coisa que precisei fazer pra adaptar o clickhouse pra demanda do sistema:
criar Views materializdas que compilam os dados no momento do insert e adicionam em outras tabelas.

ja havia tentado fazer isso com timescale DB (plugin do PostgreSQL pra séries temporais) mas não tinha ficado bom e tava puxando demais das CPUs por conta do alto volume de inserts.
já no clickhouse isso não gerou quase nada de carga extra nos inserts.
fiz inserts de 1-2M de uma vez e o DB deu conta tranquilamente.

Dada a arquitetura do banco, ele não performa bem em deletes ou updates. Também performa pior que o postgres em escritas ou leituras de linhas individuais, por exemplo. O foco do clickhouse é análise e alto volume de dados, OLAP. Para outros casos, OLTP, melhor um banco tradicional

opa, ainda nao, seria o mesmo propósito? segui pro clickhouse por conta de um post no blog do posthog em relação a essa migração.