Порой, когда мы разрабатываем какой-то продукт, нам надо что-то простое, незамысловатое. Например, это может быть тупая, как пробка Java, а не Scala вместе с Cats. Понятный всем Docker Compose, а не Kubernetes. И вот как раз таки Redis в качестве in-memory базы данных, вместо местами переусложнённого Apache ignite.
На самом деле, хочется сразу сказать Safe harbor. Простота — это не всегда плохо. Посмотрите на самый главный подтверждающий это пример — язык Golang. Он стал таким популярным в том числе из-за своей специально сделанной простоты. Простота позволяет уменьшить порог входа в техологию, а также не допустить серьезных ошибок, которые легко сделать в большом и сложном программном продуте.
Почему я называю Redis — простым? Достаточно просто посмотреть на описание RESP (REdis Serialization Protocol), а также на общий список доступных команд этой Базы данных — https://redis.io/commands/. Как вы можете видеть, тут действительно нет ничего хитрого. Можно просто садиться и писать свою реализацию клиента. Не многие промышленные СУБД могут таким похвастаться: обычно написание драйвера к БД — это довольно долгая и относительно сложная задача.
Однако не стоит бежать впереди парозова. Для всех современных языков программирования уже есть написанные Redis-клиенты, которые старательно переводят спеку БД в API вашего языка. Например, для Java есть клиент — Jedis. Это простая обёртка над командами редиса, которую можно брать и тупо использовать.
К сожалению, у любого подхода в инженерии есть свои минусы. Осознанная простота — это, конечно же, тоже инженерный прием. Главная проблема тут — если вам не хватает от технологии чего-то, то добавить это может быть крайне сложно. Например, вернемся к языку Go. До тех пор, пока вы просто используете встроенные коллекции данных — все замечательно, Дженерики вам не нужны. Однако если вы хотите написать свою структуру данных, то это сделать уже не так просто: вам придется заняться кодогенерацией, или воспользоваться не совсем приятным Рефлекшеном.
Какие же есть проблемы у Redis? Изначально эта база данных представляла собой очень тупой Key-Value кэш, который никак не масштабировался. Естественно, после того, как на эту базу данных подсела куча людей, High Availability и Scalability всем вдруг стали резко нужны. И тут появился Redis Sentinel. В этот момент начинаешь думать, возможно стоило взять GridGain, или Hazelcast?
Теперь вернемся к клиентам для Redis, а именно к Jedis. Так как этот клиент практически один в один реализует команды базы данных, то он такой же простой. К сожалению, если вы хотите что-то хитрое (например, распределенные локи, или очередь обработки задач), то вам придется всё это реализовывать самому. Пахнет велосипедами, непорядок.
К счастью, есть невероятно крутая Java-надстройка над Redis, реализованная в виде клиента — Redisson. Тут есть буквально всё, что вы только могли бы хотеть от in-memory базы данных. Это и распределенные коллекции, и распределенные локи, и разнообразные очереди и планировщики задач. Тут же присутствует отличная интеграция со спрингом. В общем, надо брать.
Подводя итоги, можно лишь еще раз проговорить понятные всем истены. Простота в инженерии — это очень круто. Делайте так просто, как только можете. Однако, если вы на этапе проектирования уже знаете требования к продукту, которые вряд ли можно будет реализовать на данной технологии, то, пожалуй, лучше сразу смотреть на больших игроков.
Категории: Программирование