4

My scenario is I prefer to stay in a relational database storage system like SQL Server because I would need to work with complex queries.

And then, because some calculations would be better to be done overtime and just store the results into something like Redis or maybe a more traditional NoSQL solution.

That's the point where I thought: and what happened with the second-level cache on NHibernate?.

I did a very small research and I found that there's a Redis second-level cache provider, and now I got "confused".

I mean, if I use NHibernate's second-level cache most of object access should be very fast as it should be no database roundtrip, thus most accessed objects would be retrieved from the in-memory Redis store.

Why I'm considering this instead of just using Redis directly? Because I need actual atomic transactions within my solution's domains.

Ok, the question?

Is relying on NHibernate's second-level cache Redis provider a good idea in order to get the best of relational and schema-less worlds?

What's your advice?

viggity
  • 15,039
  • 7
  • 88
  • 96
Matías Fidemraizer
  • 63,804
  • 18
  • 124
  • 206

1 Answers1

8

I see two different things as a summary of your view:

  1. Use redis as second level cache above NHB. This make perfect sense as SLC stores separated fields of objects and redis is key/value store. As I remember, SLC contain results of scalar queries or mapped and fetched objects but what's important, the data are taken (cached) from performed queries.

    IMHO if you would use redis this way, all cached values must result from NHB queries. This brings you some kind of transaction atomicity, how did you already described, but as far as I know, we found couple bugs when SCL returned stale data or data from uncommitted transactions.

    Note that this approach says that someone (NHB) still needs to somehow guarantee business transaction between RDBMS and Redis, which is not simple and buggy.

    Also note that SLC itself is not incredibly fast pattern. As SLC contain field of object and not object itself, every hit results into new object creation. So what happen is fetching data from Redis instead of resultset obtained from executed SQL query. So, when you use prepared statements and RDBMS typically makes caching for you, you can find out that this does not bring very large performance improvement for you.

  2. Redis as a separated business store. You managed data completely on you own, you can make their computation within native (C#) code (contrary to SQL query or mapped object). You need to guarantee fresh data and some transaction approach.

What I would choose? Separated redis. Why?

  1. Second level cache along with mapping puts some contract to you as the content results from queries or mapped objects. You can't manage or use Redis on your own. Especially your cached data are coupled/tight to those queries, not to some API (interfaces) and some kind of service (as I would design it)
  2. You can make computation of you data in your own code.
  3. SLC approach seems buggy for me and often it was very hard to find these bugs.
Martin Podval
  • 1,097
  • 1
  • 7
  • 16
  • Maybe I'm wrong, but one of your conclusions would be that the point of using Redis as SCL would be because its distributed nature: a lot of instances of the same app which also use NHib would work with the same distributed SCL. But as you state in your answer, the point wouldn't be performance at all. Am I wrong? – Matías Fidemraizer Sep 25 '13 at 18:24
  • Well, I've to admit that I didn't realize it but your point is correct. Redis allows to work in distributed nature but I dont think that it could somehow work like more Nhibernate instances and one Redis. I think more instances would overwrite values in one Redis. The performance depends on way of calculation. Redis itself is faster than similar operations on RDBMS. – Martin Podval Sep 25 '13 at 19:32
  • You've convinced me :) – Matías Fidemraizer Sep 28 '13 at 11:34