-
Notifications
You must be signed in to change notification settings - Fork 3
Compressão
O algoritmo LZFSE oferece resultados "positivos" em termos de compressão e, ao mesmo tempo, desempenho. Naturalmente, torna-se uma escolha a ser investigada para "empacotar" dados antes de serem transferidos ou mesmo para armazenamento. Convém ressaltar a análise de cenários, muitos deles baseados em uso de dados esporadicamente, o que sugere possibilidade de "alta" compressão, mesmo na presença de "demora" para descompressão.
O objetivo do presente trabalho é investigar implementações disponíveis e orientar processo de decisão com compromissos baseados no desempenho e taxa de compressão. Por exemplo, para a saúde a compressão deve prevalecer sobre o desempenho ou o inverso? Como decidir corretamente? Qual o algoritmo a ser utilizado? Consultar TurboBench (aqui). Qual a orientação que o estudo estabelece em termos do tamanho dos "pacotes" a serem transferidos? Há alguma sugestão para o desenvolvimento do healthdb? O SGBDs fazem nesse sentido? O que sistemas operacionais fazem? O que middlewares estão fazendo? Experimentar https://github.com/lzfse/lzfse ou outra implementação para "verificar" resultados.
- Identificação e definição de cenários de usos de dados.
- Seleção de algoritmos "compatíveis" com os cenários (acima).
- Análise de implementação de pelo menos dois algoritmos selecionados.
- Snappy usado por CouchStore sempre.
- Infoq Lzfse
- lz4
- WiredTiger uses block compression with snappy.