Meu mecanismo de armazenamento atual é WiredTigere seu nível de compactação é padrão, rápido. Eu me deparei com a documentação do MongoDB e foi mencionado que usar o zlib compacta melhor, mas precisa de mais CPU.
Eu quero saber vai zlibarmazenar mais dados na memória em comparação com snappycomo comprimir os dados? Eu tenho um servidor com 16 núcleos de CPU. Como a RAM é mais cara, prefiro economizar na memória caso ela mantenha mais dados.
Isso está correto? Posso mudar cegamente para zlib para armazenar mais dados em cache e melhorar o desempenho de leitura?
NOTA: Nosso servidor é de leitura intensiva.
A documentação em https://docs.mongodb.com/manual/core/wiredtiger/#memory-use diz que os dados de coleta são compactados apenas no disco, portanto, descompactados na memória. Os índices mantêm sua compactação de prefixo na memória, mas não a compactação em nível de bloco.
Portanto, alterar os algoritmos de compactação não reduzirá diretamente a quantidade de memória necessária para manter uma carga de trabalho de leitura pesada eficiente (ou seja, para garantir que seu conjunto de trabalho permaneça na RAM), a menos que você já esteja com falta de memória, caso em que uma melhor compactação pode ajudar reduzindo a E/S à medida que o sistema de armazenamento é prejudicado porque todos os dados do banco de dados nos buffers e cache do sistema operacional serão compactados. A única maneira de saber com certeza é comparar uma carga de trabalho realista em dados semelhantes à produção em um ambiente de teste com cada combinação de opções que você está considerando.
O "a menos que você já esteja com falta de memória" é significativo aqui: uma vez que você esteja nesse estado, o melhor que a compactação provavelmente fará é melhorar seu desempenho de muito, muito lento para muito lento.
Uma exceção ao acima seria qualquer consulta que precise ler um conjunto de dados muito grande para caber em qualquer quantidade prática de memória; nesse caso, você poderá ver melhorias significativas: todos os dados de que a consulta precisa precisarão ser lidos do subsistema de E/S de qualquer maneira, e a compactação provavelmente ajudará nisso. Precisaríamos saber muito mais sobre os dados e cargas de trabalho do seu aplicativo para fornecer dicas específicas sobre se isso teria um efeito perceptível no seu caso e, mesmo assim, a única maneira de ter certeza é, novamente, executar benchmarks.
NOTA: este não é o caso para todos os bancos de dados. Por exemplo, com as opções de compactação do MS SQL Server, os dados nas páginas na RAM são compactados exatamente como estão no disco. Isso reduz o uso de RAM pelo pool de buffers em detrimento do tempo de CPU em cada leitura de cada página. Quando os dados são descompactados na RAM, a descompactação da CPU ocorre apenas quando os dados são carregados do disco, portanto, não afetará as leituras subsequentes até que a página/bloco/documento seja despejado porque não foi referido recentemente.
A resposta curta é não.
Uma resposta mais longa é: Nnnnnooooooooooooooooooooooooooooooooooooooooooooooooooooooo...
Menos jocoso: fazer qualquer coisa cegamente em um banco de dados e/ou aplicativo de produção é perigoso, portanto, nunca é um curso de ação recomendado. Nunca faça isso se você valoriza seus usuários e sua própria sanidade. Sempre teste em um ambiente de desenvolvimento/teste primeiro, não importa o quanto você confie em qualquer fonte de aconselhamento que sugira o contrário. Pode parecer uma perda de tempo quando você testa e não encontra efeitos nocivos, mas em algum momento de sua carreira ficará muito feliz por ter aplicado a devida diligência e se salvado de um evento desagradável e embaraçoso em um aplicativo em produção! Se você não seguir a devida diligência dessa maneira, poderá enfrentar eventos de atualização de CV não planejados.