Antirez zei, zie in https://news.ycombinator.com/item?id=1171423
Er zijn een paar redenen:
- Ze zijn niet erg geheugenintensief. Het is in principe aan jou. Het wijzigen van parameters over de waarschijnlijkheid dat een knooppunt een bepaald aantal niveaus heeft, zal dan minder geheugenintensief maken dan btrees.
- Een gesorteerde set is vaak het doelwit van veel ZRANGE- of ZREVRANGE-bewerkingen, dat wil zeggen, het doorlopen van de skip-lijst als een gekoppelde lijst. Met deze operatie is de cachelocatie van skip-lijsten minstens zo goed als bij andere soorten uitgebalanceerde bomen.
- Ze zijn eenvoudiger te implementeren, te debuggen, enzovoort. Dankzij de eenvoud van de skip-lijst ontving ik bijvoorbeeld een patch (al in Redis-master) met uitgebreide skip-lijsten die ZRANK implementeren in O(log(N)). Er waren kleine wijzigingen in de code nodig.
Over de append Alleen duurzaamheid en snelheid, ik denk niet dat het een goed idee is om Redis te optimaliseren ten koste van meer code en meer complexiteit voor een use case die IMHO zeldzaam zou moeten zijn voor het Redis-doel (fsync() bij elke opdracht) . Bijna niemand gebruikt deze functie, zelfs niet met ACID SQL-databases, omdat de prestatiehint sowieso groot is.
Over threads:onze ervaring leert dat Redis grotendeels I/O-gebonden is. Ik gebruik threads om dingen uit het virtuele geheugen te bedienen. De langetermijnoplossing om alle kernen te exploiteren, ervan uitgaande dat uw verbinding zo snel is dat u een enkele kern kunt verzadigen, is het uitvoeren van meerdere exemplaren van Redis (geen vergrendelingen, bijna volledig lineair schaalbaar met het aantal kernen) en het gebruik van de "Redis Cluster " oplossing die ik in de toekomst wil ontwikkelen.