Если погулить в интернете что-либо про Redis, то можно найти исключительно восторженные отзывы об этом сервере, что само по себе и нормально, в принципе, ибо кому Redis не подошёл, тот просто будет использовать что-то другое и ничего про Redis писать не будет.
Можно заметить, что многие считают, что Redis работает поразительно быстро. Чтобы понять, поразительно быстро он работает или нет, надо его с чем-то сравнить. Сравнивать с чем-то отличным от Redis, с тем, что делает что-то абсолютно иное, чем то, что делает сам Redis, возможно и не имеет смысла, так как разница в скорости может быть обусловлена тем, что Redis не делает того, что делает сравниваемая с ним реализация или, наборот, сравниваемое не делает то, что делает Redis.
А вот сравнить Redis с самим Redis'ом интересно в плане того, насколько эффективно сделана та реализация, что есть в самом Redis'e.
К счастью, протокол Redis'а задокументирован и доступен в открытом виде всем желающим, поэтому каждый может написать свою версию Redis.
Казалость бы - Redis написать сложно, однако, по большому счёту, это уровень лабораторной работы на первых курсах института и новая реализация основных возможностей протокола RESP (а именно так называется протокол, по которому сервер Redis'а общается с клиентским приложением) может быть создана буквально за 2-3 часа.
Если поискать на github то можно найти несколько реализация протокола RESP. Некоторые их них работают, некоторые нет. Интересна в этом плане реализация Redis на файлах в операционке, называемая Bigdis, которая с одной стороны, наглядно может показать разницу в скорости между реализацией словаря на каталоге в файловой системе и реализацией в пользовтельской специально написанной программе, а, с другой стороны, он код из этого проекта совершенно не работает - если выкачать Bigdis из github, запустить и потом обратиться к нему, например, из питона, то будет получена ошибка о неверной команде.
С третьей же стороны, Bigdis написан 12 лет назад автором Redis'а и, за это время никто не обнаружил то, что Bigdis не работает, несмотря на 11 форков, 75 звёзд и 4 наблюдателя за репозиторием. То есть, все эти люди просто поставили звёзды, форкнули и стали наблюдателями просто так, ни разу не запуская и не проверяя того, что же такого автор Redis выложил в новый репозиторий.
Как ни странно, ошибка в Bigdis достаточно очевидна - в протокле RESP Redis'а команды дожны посылаться в верхнем регистре, а таблица поиска команд для Bigdis задана в нижнем регистре, поэтому, команды не находятся.
Поэтому, исправляется такая ошибка достаточно просто - добавлением строки приведения к нижнему регистру имени команды, после чего его можно запсукать и проврять в работе.
Итак, мы видим, что установка значения при реализации словаря на каталоге операционки может быть выполнена почти 5 тысяч раз в секунду, а чтение значения из каталога чуть более 2 тысяч раз в секунду (в 2 раза медленее, чем запись)
Теперь сравним родную реализацию Redis и простую реализацию "в лоб" на Scala и Berkeley DB без каких-либо заморочек
Получили примерно одинаковый результат. Команда SET выполняется чуть дольше, потому что там два параметра, а не один, как в команде GET.
Таким образом, производительность Redis равна производительности простейшей реализации на Scala, очевидно, что если потратить время и её оптимизировать, то можно добиться значительно более лучшего результата, чем сейчас есть у Redis.
Исходя из этого не следует считать быстродействие Redis чем-то выдающимся - это обычное быстродействие для приложений, реализующих функционал словаря данных. Да, Redis работает в 50 раз быстрее реализации на каталогах, но много что работает в 50 раз быстрее этой реализации!
В то же время, это ещё одно подтверждение тому, что на Scala можно реализовать алгоритмы с эффектиностью, не меньшей, чем эффективность реализации алгоритмов на c и с гораздо меньшими усилиями.
Понятно, что на Питоне так не получится.
Ссылки по теме:
1. Bigdis: https://github.com/antirez/Bigdis
2. Redis: https://github.com/redis/redis
3. Brkldbis: https://github.com/alphapone/brkldbis
Написано на Dotty и Wicket
!без Web 2.0!
Адаптировано для работы в Lynx
канал в Дзен