Disse Antirez, veja em https://news.ycombinator.com/item?id=1171423


Há algumas razões:

• Eles não consomem muita memória. Depende basicamente de você. Alterar parâmetros sobre a probabilidade de um nó ter um determinado número de níveis fará com que a memória seja menos intensiva do que btrees.
• Um conjunto ordenado é frequentemente alvo de muitas operações ZRANGE ou ZREVRANGE, ou seja, percorrendo a lista de saltos como uma lista encadeada. Com esta operação, a localidade do cache das listas de salto é pelo menos tão boa quanto com outros tipos de árvores balanceadas.
• Eles são mais simples de implementar, depurar e assim por diante. Por exemplo, graças à simplicidade da lista de pulos, recebi um patch (já no mestre Redis) com listas de pulos aumentadas implementando ZRANK em O(log(N)). Exigiu pequenas alterações no código.
  

Sobre a durabilidade e velocidade do Append Only, não acho uma boa ideia otimizar o Redis ao custo de mais código e mais complexidade para um caso de uso em que o IMHO deve ser raro para o destino do Redis (fsync() em cada comando) . Quase ninguém está usando esse recurso mesmo com bancos de dados ACID SQL, pois a dica de desempenho é grande de qualquer maneira.

Sobre encadeamentos:nossa experiência mostra que o Redis é principalmente vinculado a E/S. Estou usando threads para servir coisas da memória virtual. A solução de longo prazo para explorar todos os núcleos, supondo que seu link seja tão rápido que você possa saturar um único núcleo, é executar várias instâncias do Redis (sem bloqueios, quase totalmente escalável linearmente com o número de núcleos) e usar o "Redis Cluster " solução que pretendo desenvolver no futuro.