Antirez dijo, ver en https://news.ycombinator.com/item?id=1171423
Hay algunas razones:
- No requieren mucha memoria. Depende de usted básicamente. Cambiar los parámetros sobre la probabilidad de que un nodo tenga un número determinado de niveles hará que la memoria sea menos intensiva que los btrees.
- Un conjunto ordenado suele ser el objetivo de muchas operaciones ZRANGE o ZREVRANGE, es decir, recorrer la lista de omisión como una lista vinculada. Con esta operación, la localidad de caché de las listas de omisión es al menos tan buena como con otro tipo de árboles equilibrados.
- Son más simples de implementar, depurar, etc. Por ejemplo, gracias a la simplicidad de la lista de saltos, recibí un parche (ya en el maestro de Redis) con listas de saltos aumentadas que implementan ZRANK en O(log(N)). Requería pequeños cambios en el código.
Acerca de la durabilidad y velocidad de Append Only, no creo que sea una buena idea optimizar Redis a costa de más código y más complejidad para un caso de uso que en mi humilde opinión debería ser raro para el objetivo de Redis (fsync() en cada comando) . Casi nadie usa esta función, incluso con bases de datos ACID SQL, ya que la sugerencia de rendimiento es importante de todos modos.
Acerca de los subprocesos:nuestra experiencia muestra que Redis está principalmente vinculado a E/S. Estoy usando subprocesos para servir cosas desde la memoria virtual. La solución a largo plazo para explotar todos los núcleos, suponiendo que su enlace sea tan rápido que pueda saturar un solo núcleo, es ejecutar varias instancias de Redis (sin bloqueos, casi completamente escalable linealmente con la cantidad de núcleos) y usar el "Clúster de Redis " solución que planeo desarrollar en el futuro.
