What is the best object lifetime strategy for Redis in web application

Question

• I will plan to use Redis (ServiceStack) as whole database for web application.
• I can insert 76000 records in 7.4 seconds.
• But using single connection (RedisClient object-life-time is Application),
• I used Set generic method not Store (huge performance difference)

I had used Per-Request object-life-time for Entity Framework ObjectContext.

So what is the best strategy for object-life-time in web application (Asp.Net MVC) for Redis (ServiceStack)..

Or Redis is not mature project for 100 Sql Server Tables (related to each other in various)

I'm totally confused.. I'm thinking to store entities in DB4O (I'm scare 'DB4o is Embedded-Java Db' slogan also ), relations in Redis ?!

And to support Include Concept in EF4.

My total project will have 1.000.000 entities, 100.000.000 relations ! (I have 3 years Entity Framework 1-4 experience)

Wimberly

Answer 1

The ServiceStack Redis Client includes 2 Thread-Safe Connection managers:

• PooledRedisClientManager - Is the connection pool implementation where RedisClient's are pooled. Recommended when accessing redis-server remotely.

• BasicRedisClientManager - Returns a new RedisClient instance each time, recommended if redis-server is on the same server as your ASP.NET web application.

Note Redis is not an RDBMS, it's a data structures server providing atomic access to server-side Key-Values, Sets, Sorted Sets, Hashes and Lists. You need to maintain your own relationships using Custom Indexes you can see an example of this in the source code of the RedisStackOverflow demo application.

You should also check out Designing a simple blog application with Redis.

Otherwise the ServiceStack C# RedisClient wiki is the best place for documentation on ow to use the C# Redis Client.

Endorsed

Answer 2

You don't want to be using a single redis client object for everything - that produces really interesting results if you have more than one page loading at once. You can use some sort of connection pooling if the overhead of creating connections is a problem, but it probably isn't necessary.

Store and the related methods are a part of ServiceStack designed to make certain simple scenarios easier by storing type information as well as the actual data - if that isn't what you need, don't use it.

Redis can support a dataset of that size quite nicely, but remember that it is in no way a relational database - everything will be modeled quite differently to what you are used to in SQL, and abstraction layers like EF won't help. You need to really understand your data, what you need to do with it, and how the required tasks map to the low level operations that redis can do really fast.

Smacker