Antirez sagde, se i https://news.ycombinator.com/item?id=1171423
Der er et par grunde:
- De er ikke særlig hukommelsesintensive. Det er dybest set op til dig. Ændring af parametre om sandsynligheden for, at en node har et givet antal niveauer, vil gøre det mindre hukommelsesintensivt end btrees.
- Et sorteret sæt er ofte målet for mange ZRANGE- eller ZREVRANGE-operationer, det vil sige at krydse overspringslisten som en sammenkædet liste. Med denne operation er cache-lokaliteten for overspringslister mindst lige så god som med andre slags balancerede træer.
- De er nemmere at implementere, fejlfinde og så videre. For eksempel takket være overspringslistens enkelhed modtog jeg en patch (allerede i Redis master) med udvidede overspringslister, der implementerede ZRANK i O(log(N)). Det krævede små ændringer af koden.
Om Append Only holdbarhed og hastighed, tror jeg ikke, det er en god idé at optimere Redis på bekostning af mere kode og mere kompleksitet for en use case, at IMHO skulle være sjælden for Redis-målet (fsync() ved hver kommando) . Næsten ingen bruger denne funktion selv med ACID SQL-databaser, da tippet om ydeevne er stort alligevel.
Om tråde:vores erfaring viser, at Redis for det meste er I/O-bundet. Jeg bruger tråde til at servere ting fra virtuel hukommelse. Den langsigtede løsning til at udnytte alle kernerne, forudsat at dit link er så hurtigt, at du kan mætte en enkelt kerne, kører flere forekomster af Redis (ingen låse, næsten fuldt skalerbar lineært med antallet af kerner) og bruger "Redis Cluster" " løsning, som jeg planlægger at udvikle i fremtiden.