Antirez ha detto, vedi in https://news.ycombinator.com/item?id=1171423
Ci sono alcuni motivi:
- Non richiedono molta memoria. Dipende da te fondamentalmente. La modifica dei parametri sulla probabilità che un nodo abbia un determinato numero di livelli renderà quindi meno intensivo di memoria rispetto a btrees.
- Un set ordinato è spesso l'obiettivo di molte operazioni ZRANGE o ZREVRANGE, ovvero attraversare l'elenco da saltare come un elenco collegato. Con questa operazione la posizione della cache delle skip list è almeno buona come con altri tipi di alberi bilanciati.
- Sono più semplici da implementare, eseguire il debug e così via. Ad esempio grazie alla semplicità della skip list ho ricevuto una patch (già in Redis master) con skip list aumentate che implementano ZRANK in O(log(N)). Richiedeva piccole modifiche al codice.
Riguardo alla durabilità e alla velocità di Append Only, non penso che sia una buona idea ottimizzare Redis al costo di più codice e più complessità per un caso d'uso che IMHO dovrebbe essere raro per il target Redis (fsync() ad ogni comando) . Quasi nessuno utilizza questa funzione anche con i database ACID SQL, poiché il suggerimento sulle prestazioni è comunque grande.
Informazioni sui thread:la nostra esperienza mostra che Redis è principalmente legato all'I/O. Sto usando i thread per servire cose dalla memoria virtuale. La soluzione a lungo termine per sfruttare tutti i core, supponendo che il tuo collegamento sia così veloce da poter saturare un singolo core, è l'esecuzione di più istanze di Redis (nessun blocco, scalabile quasi completamente linearmente con il numero di core) e l'utilizzo del "Cluster Redis " soluzione che ho intenzione di sviluppare in futuro.
