O que é o REDIS? Um banco de dados NoSQL baseado em chave/valor e disparado um dos mais usados no mundo! Essa resposta está certa, embora incompleta. Há uma infinidade de recursos legais que deveriam ser levados em consideração na hora de explicar o projeto/produto.
Nesse post, que tentarei fazê-lo bem curto, vou apontar diversos links para a documentação do Redis. Sim, isso é um RTFM!!!
Vamos começar desmistificando algumas coisas, a começar pelo quesito confiabilidade. A definição do produto, segundo seus criadores é:
Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. It supports data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs and geospatial indexes with radius queries. Redis has built-in replication, Lua scripting, LRU eviction, transactions and different levels of on-disk persistence, and provides high availability via Redis Sentinel and automatic partitioning with Redis Cluster.
Vamos começar pela principal característica: In-Memory. Isso significa que quedas de energia fazem com que seus dados sejam perdidos. Sua persistência em disco #RTFM, acontece ou em jobs que de tempos em tempos realizam os ciclos de persistência, ou em no modelo AOF temos um modelo de persistência por escrita. A persistência é opcional e as duas podem estar ativas simultaneamente. Lendo esse post, do próprio Redis, eu particularmente não me encorajo a ligar nenhuma dessas persistências. Ambas são frágeis e isso é relevante pois muitas vezes vejo o uso inadequado do redis como message broker, quando na verdade a melhor alternativa para o cenário deveria ser o RabbitMQ, por exemplo.
O fato de não ser tolerante a catástrofes(lemos nos textos acima que não é bem assim) significa que você precisa ter algum tipo de controle ou desvio de fluxo, para que seu Redis possa ser repopulado em caso de shutdown, seja por demanda, chave-a-chave, ou em lote.
Outro ponto muito relevante é que o Redis tem uma infinidade de features legais, veja os comandos divididos em categorias:
- Cluster: Gestão do servidor Redis, e viabiliza a criação e gestão de um cluster.
- Connection: Gerencia sua conexão com o Redis, permitindo autenticar-se, realizar ping, verificar e até dropar sua conexão com o Redis.
- Geo: Dedicado a manipulação de dados geoespaciais. Possui comandos para criação, cálculo e manipulação desse tipo de estrutura.
- Hashes: Permite a criação de um segundo nível de elementos abaixo de uma chave, como uma hashtable.
- HyperLogLog: Se você não sabe o que é HyperLogLog (assim como eu não sabia até começar a escrever esse post, leia)
- Keys O mais tradicional e comum conjunto de comandos destinados à gestão de chaves.
- Lists: Permite operações com listas que podem se comportarem como Stacks ou Queues (Leia mais em Stack e Queue também são seus amigos)
- Pub/Sub: Permite operações de assinatura, publicação e processamento.
- Scripting (Sim, procedures!)
- Server: Comandos de gestão do servidor redis. Somado aos comandos da categoria Cluster e Connection permitem a você gerenciar de forma completa sua instância Redis.
- Sets: Enquanto a Categoria Lists implementa Stack e Queue, a categoria Set faz o trabalho com o que conhecemos no .NET como listas. Operações tradicionais de adição e remoção e manipulação de listas de elementos.
- Sorted Sets: Assim como a anterior, mas dedicada a listas ordenadas
- Strings: A categoria Strings dedica-se a string e números, onde podemos, com números, podemos facilmente implementar um contador de visitas, semelhante ao contador do Youtube. No que diz respeito às strings, manipulações básicas como append, position entre outras operações bem básicas.
- Transactions: Em transações gerenciamos um contexto transacional.
Todos esses comandos estão disponíveis na plataforma para oferecer formas eficientes de trabalhar com o conteúdo armazenado no Redis. Novidade? Não. Se você já usou o Provedor de estado de sessão ASP.NET para Cache Redis do Azure e teve o mínimo de curiosidade para olhar seu fonte, vai perceber que a última coisa que ele faz é usar usar os comandos mais comuns o que fica claro na classe RedisConnectionWrapper presente no github do projeto.
Agora que vimos todas as categorias de comandos do Redis, já apresentei algumas características relevantes sobre o projeto, vamos falar sobre padrões. Dá para se fazer muita coisa legal com o Redis além de armazenar dados de cache, como por exemplo:
Bom, a intenção era sair do trivial get/set de chaves com TTL. A dinâmica era apresentar algo que pudesse estar escondido o suficiente nos tutoriais e apresentações sobre Redis. Assim como qualquer decisão, é preciso ponderar entre benefícios e gaps na utilização de qualquer tecnologia. O Redis é um excelente produto, fundamental para muitos cenários, mas nunca será bala de prata! Balas de prata não existem!
0 comentários