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

Using the Redis NoSql database with .NET Part 8: messaging

Introduction

In the previous post we looked at transactions in Redis. A transaction is a collection of database operations that are executed as a unit. The commands of a transaction are executed atomically, meaning that the process is not interrupted by an external operation. The commands either pass or fail together. Redis has at least partial implementation of transactions. We can start and execute transactions but if one or more commands fail then the other members are still executed. In other words there is no rollback mechanism. Redis also offers a concurrency check through the WATCH command if we want to perform the transaction on an unchanged set of resources.

Redis also offers a basic messaging system which will be the topic of this post.

Read more of this post

Using the Redis NoSql database with .NET Part 7: transactions

Introduction

In the previous post we looked at the hash data type in Redis. Hashes are key-value collections like dictionaries in .NET or maps in Java. For a given Redis key hashes can store multiple key-value pairs. Hashes offer a certain degree of object-oriented design where an object, such as a product or customer can be described by key-values like “id”: 23, “name”: “Unknown LTD” and so on. We can use the string data type to store the properties of an object as a JSON string as we saw before in this series. However, if you need to access the individual properties of an object then a hash can be a more suitable option.

We’ve now discussed all available data types in Redis. We’ll now turn our attention to transactions.

Read more of this post

Using the Redis NoSql database with .NET Part 6: the hash data type in C#

Introduction

In the previous post we looked at the sorted set data type in Redis. A sorted set is not simply a set where the values are sorted. It is a container of unique strings where each member also has a score. The members in the sorted set are sorted by their scores. Sorted sets can be applicable for scores reached in a competition, the time it took to complete various activities, the energy lost during a physical exercise etc., i.e. anywhere where a member also has a numeric value attached to it. We also discussed the basics of persistence and how it is configured for the Windows Redis service through a configuration file.

In this post we’ll look at one remaining data type in Redis, namely hashes.

Read more of this post

Using the Redis NoSql database with .NET Part 5: the sorted set data type

Introduction

In the previous post we looked at the set data type in Redis. Sets are similar to list but they only store unique strings. Duplicates are discarded and the items are case sensitive. This means that we can add “monday” and “MONDAY” in the same set. Another difference compared to lists is that sets are not guaranteed to hold the items in the same order as they were entered. Redis has commands to perform a couple of common set-related actions such as calculating the union, difference and intersection of two or more sets. We also looked at two techniques to extract the key names from the Redis database: KEY and SCAN where SCAN is a cursor based iterator and is the recommended method since it’s a lighter operation for the database.

In this post we’ll first talk a little bit about persistence to disk in Redis. Then we’ll move onto a discussion of the sorted set data type.

Read more of this post

Using the Redis NoSql database with .NET Part 4: key name searches and the set data type

Introduction

In the previous post we looked at the list data type in Redis. Lists are implemented as linked lists in Redis meaning that each item has a link to its immediate neighbours, i.e. the previous and the next items. It’s efficient to operate on the first or last item in a linked list: add to and retrieve from the head or tail of a linked list is very fast. Redis lists therefore lend themselves very well to queues and stacks. Index-based operations, e.g. getting the 3rd item in the list, are not as efficient. We then looked at a couple of list-related Redis commands such as LINSERT, RPOP and LRANGE. We also looked at how to add the Redis folder to the environment variables on Windows so that we can call upon the Redis executables without having to navigate to the folder in a command prompt.

In this post we’ll first look at how to retrieve the key names in our Redis database. Then we’ll continue our discussion of the Redis data types with sets.

Read more of this post