Антирез каза, вижте в https://news.ycombinator.com/item?id=1171423
Има няколко причини:
- Те не изискват много памет. По принцип зависи от вас. Промяната на параметри за вероятността възел да има определен брой нива ще направи паметта по-малко интензивна от btrees.
- Сортираният набор често е цел на много операции ZRANGE или ZREVRANGE, тоест преминаване на списъка за прескачане като свързан списък. С тази операция локализацията на кеша на списъците за пропускане е поне толкова добра, колкото при други видове балансирани дървета.
- Те са по-лесни за внедряване, отстраняване на грешки и т.н. Например, благодарение на простотата на списъка за пропускане получих корекция (вече в Redis master) с разширени списъци за пропускане, внедряващи ZRANK в O(log(N)). Това изискваше малки промени в кода.
Относно издръжливостта и скоростта само на добавяне, не мисля, че е добра идея да се оптимизира Redis с цената на повече код и повече сложност за случай на употреба, който IMHO би трябвало да е рядък за целта на Redis (fsync() при всяка команда) . Почти никой не използва тази функция дори с ACID SQL бази данни, тъй като намекването за производителност така или иначе е голямо.
Относно нишките:нашият опит показва, че Redis е предимно I/O обвързан. Използвам нишки, за да обслужвам неща от виртуална памет. Дългосрочното решение за използване на всички ядра, като приемем, че връзката ви е толкова бърза, че можете да наситите едно ядро, изпълнява множество екземпляри на Redis (без ключалки, почти напълно мащабируемо линейно с брой ядра) и използва "Redis Cluster " решение, което планирам да разработя в бъдеще.
