sagte Antirez, siehe https://news.ycombinator.com/item?id=1171423
Dafür gibt es einige Gründe:
- Sie sind nicht sehr speicherintensiv. Es liegt im Grunde an Ihnen. Das Ändern von Parametern über die Wahrscheinlichkeit, dass ein Knoten eine bestimmte Anzahl von Ebenen hat, wird dann weniger speicherintensiv als btrees.
- Eine sortierte Menge ist oft das Ziel vieler ZRANGE- oder ZREVRANGE-Operationen, d. h. das Durchlaufen der Skip-Liste als verkettete Liste. Mit dieser Operation ist die Cache-Lokalität von Skip-Listen mindestens so gut wie bei anderen Arten von balancierten Bäumen.
- Sie sind einfacher zu implementieren, zu debuggen und so weiter. Zum Beispiel habe ich dank der Einfachheit der Skip-Liste einen Patch (bereits im Redis-Master) mit erweiterten Skip-Listen erhalten, die ZRANK in O(log(N)) implementieren. Es waren kleine Änderungen am Code erforderlich.
In Bezug auf die Haltbarkeit und Geschwindigkeit von Append Only halte ich es nicht für eine gute Idee, Redis auf Kosten von mehr Code und mehr Komplexität für einen Anwendungsfall zu optimieren, der meiner Meinung nach für das Redis-Ziel selten sein sollte (fsync() bei jedem Befehl). . Selbst bei ACID SQL-Datenbanken verwendet fast niemand diese Funktion, da der Leistungshinweis sowieso groß ist.
Über Threads:Unsere Erfahrung zeigt, dass Redis hauptsächlich I/O-gebunden ist. Ich verwende Threads, um Dinge aus dem virtuellen Speicher bereitzustellen. Die langfristige Lösung, um alle Kerne auszunutzen, vorausgesetzt, Ihre Verbindung ist so schnell, dass Sie einen einzelnen Kern sättigen können, besteht darin, mehrere Instanzen von Redis auszuführen (keine Sperren, fast vollständig linear mit der Anzahl der Kerne skalierbar) und den „Redis Cluster " Lösung, die ich in Zukunft entwickeln möchte.
