Using the Redis NoSql database with .NET Part 18: Redis as a cache engine in .NET

Introduction

In the previous post we looked briefly at data persistence in Redis. We know that the principal storage for Redis is the memory. It also offers two modes of persistence. The first option is called snapshotting which means that the database is saved to disk periodically. The periodicity can be configured in the Redis config file and we can define multiple options depending on the number of new items in memory. The drawback of snapshotting is that if the Redis service abruptly goes down then some unsaved data in memory will be lost. If you cannot afford any data loss then the append-only persistence mode can be for you. It saves the commands in an append-only file which is processed when Redis starts up to restore the database based on the saved commands. Note that append-only will make write operations slower.

In this post we’ll look at caching in the ServiceStack.Redis client. This post also concludes the series on Redis with .NET.

Read more of this post

Using the Redis NoSql database with .NET Part 17: persistence

Introduction

In the previous post we looked at the security features of Redis. We saw that Redis doesn’t come with the highly granular security features of a full-fledged relational database like SQL Server or Oracle. It offers password passed authentication where the client needs to authenticate with a password before issuing commands. There’s no separate username and we cannot set granular rules like userA can only access this and this resource. Another security feature is command obfuscation where we can change how a command is called. The CONFIG command can be a “dangerous” one that we don’t want just any user to be able to call. We can instead provide another name, possibly a cryptic one, for it so that CONFIG must be called by that name instead.

In this post we’ll discuss the persistence options in Redis.

Read more of this post

Using the Redis NoSql database with .NET Part 16: security

Introduction

In the previous post we looked at how to log slow queries in Redis. We can declare the limit using the slowlog-log-slower-than flag that accepts an integer. If a query whose execution time exceeds this limit expressed in microseconds is logged to the slow log. The slow log is persisted only in memory and we can set an upper limit to the number of commands stored there. If this limit is reached then the oldest stored command is removed.

In this post we’ll see what Redis has to offer by way of security.

Read more of this post

Using the Redis NoSql database with .NET Part 15: logging slow queries

Introduction

In the previous post we looked at how to use the Redis messaging feature in the ServiceStack.Redis .NET client. We saw that it was in fact very easy to both send and receive messages with a couple of lines of code. The most important thing to keep in mind is that the subscriber application has a blocking call to the SubscribeToChannels function. It will prevent all other code after it from executing and start watching the declared Redis channel.

In this post we’ll look at how we can log slow queries in Redis.

Read more of this post

Using the Redis NoSql database with .NET Part 14: messaging in the .NET client

Introduction

In the previous post we saw how to execute transactions in the ServiceStack.Redis client. We could conclude that it was in fact extremely easy using the CreateTransaction, QueueCommand and Commit functions.

In this post we’ll look at how to use the Redis messaging function in the .NET client. You’ll see that it’s just as easy as executing transactions.

Read more of this post

Using the Redis NoSql database with .NET Part 13: transactions in the .NET client

Introduction

In the previous post we looked at a simple monitoring tool we can use to check which commands are executed on the Redis server. Running MONITOR in a production system might not make sense since there’s no filtering and the commands will just fly by in the command window in quick succession. Also, the monitor slows down the server performance. The command monitor is most useful in an alpha server with not much traffic or for debugging a Redis-based application locally where the target database sits on the localhost. We then took this monitoring tool and checked what commands the .NET client generates while working with the various client interfaces. The most interesting case was to see how it handles objects with various keys and sets to keep track of the object IDs.

In this post we’ll look at how to execute transactions in the .NET client.

Read more of this post

Using the Redis NoSql database with .NET Part 12: monitoring the database commands

Introduction

In the previous post we saw how to work with custom objects using the ServiceStack Redis client. The generic IRedisTypedClient works with the supplied type parameter and provides a large number functions to handle our objects in the Redis database. With this interface it almost feels like we’re working with a “traditional” database with its methods like Store, GetById, DeleteById, PopItemFromList etc. Redis may at first give the impression that it can only be used as a cache server with its keys and values. However, with proper usage of its data types Redis also serves as a “proper” database for modern applications.

In this post we’ll look at the question of how our objects are stored in Redis. After all when we went through the Redis commands before we didn’t see any command like GETBYID or STORE. Monitoring the calls sent to the Redis database will give us a hint.

Read more of this post

Using the Redis NoSql database with .NET Part 11: working with objects in the .NET client

Introduction

In the previous post we looked at the IRedisClient interface to communicate with Redis. We saw that it provides a more convenient way of dealing with Redis commands in code. It’s especially useful when working with lists, hashes, sets and sorted sets since those data types are exposed through properties. We can then process those variables almost like we do with their .NET equivalent objects, i.e. dictionaries, lists and hashsets. We also briefly looked at the two Redis client manager classes that provide access to a new Redis clients.

We still cannot seamlessly work with our custom objects. We’re still responsible for serialising and deserialising them through e.g. JSON. This is where the generic IRedisTypedClient enters the scene. We’ll look at that in this post.

Read more of this post

Using the Redis NoSql database with .NET Part 10: a higher level of abstraction in the .NET client

Introduction

In the previous post we started looking into a Redis .NET client from ServiceStack. At this point of time there are two recommended .NET clients for Redis with ServiceStack being one and StackExchange.Redis being the other. The single biggest difference between the two is that ServiceStack.Redis requires a paid licence above a certain usage limit. The free-of-charge limit is more than enough for evaluation and testing purposes but you’ll most certainly need to buy a licence for your production environment. Otherwise if your application exceeds the free limits you’ll start to see some exception messages.

ServiceStack.Redis provides three interfaces to communicate with Redis. In the previous post we looked at the most basic one, i.e. IRedisNativeClient. It provides a wide range of low level database operations.
Most of these operations map to Redis commands like GET, SET, SMEMBERS, ZADD etc. one to one. However, the methods require string and byte array inputs and the programmer is responsible for all data conversion back and forth which results in a lot of code to achieve simple stuff.

In this post we’ll go slightly higher with the IRedisClient interface. We’ll also see how to get hold of a Redis client from Redis client manager.

Read more of this post

Using the Redis NoSql database with .NET Part 9: starting with the Redis .NET client

Introduction

In the previous post we looked at how Redis can be used as a message broker. Messaging is a technique to enable two disparate systems to communicate with each other. Communication usually happens via data types that most systems understand: strings, bytes and the like. The party sending a message to a channel is called a publisher or sender and the ones consuming the messages are called subscribers or consumers. Any Redis client can subscribe to a channel and get the messages registered on a certain channel. A system that sits in between the publishers and subscribers, i.e. that can create channels, accept messages to those channels and funnel them out to the subscribers is called a message broker. Redis offers a basic but very efficient messaging service. If you see a need for a simple messaging solution in your system without the more complex features of other message brokers then Redis may be all you need, especially if you already use it as a database.

In this post we’ll start looking at using Redis through .NET.

Read more of this post