4

I have a website that allows users to query for specific recipes using various search criteria. For example, you can say "Show me all recipes that I can make in under 30 minutes that will use chicken, garlic and pasta but not olive oil."

This query is sent to the web server over JSON, and deserialized into a SearchQuery object (which has various properties, arrays, etc).

The actual database query itself is fairly expensive, and there's a lot of default search templates that would be used quite frequently. For this reason, I'd like to start caching common queries. I've done a little investigation into various caching technologies and read plenty of other SO posts on the subject, but I'm still looking for advice on which way to go. Right now, I'm considering the following options:

  1. Built in System.Web.Caching: This would provide a lot of control over how many items are in the cache, when they expire, and their priority. However, cached objects are keyed by a string, rather than a hashable object. Not only would I need to be able to convert a SearchQuery object into a string, but the hash would have to be perfect and not produce any collisions.
  2. Develop my own InMemory cache: What I'd really like is a Dictionary<SearchQuery, Results> object that persists in memory across all sessions. Since search results can start to get fairly large, I'd want to be able to cap how many queries would be cached and provide a way for older queries to expire. Something like a FIFO queue would work well here. I'm worried about things like thread safety, and am wondering if writing my own cache is worth the effort here.

I've also looked into some other third party cache providers such as NCache and Velocity. These are both distributed cache providers and are probably completely overkill for what I need at the moment. Plus, it seems every cache system I've seen still requires objects to be keyed by a string. Ideally, I want something that holds a cache in process, allows me to key by an object's hash value, and allows me to control expiration times and priorities.

I'd appreciate any advice or references to free and preferably open source solutions that could help me out here. Thanks!

Mike Christensen
  • 88,082
  • 50
  • 208
  • 326

4 Answers4

6

Based on what you are saying, I recommend you use System.Web.Caching and build that into your DataAccess layer shielding it from the rest of you system. When called you can make your real time query or pull from a cached object based on your business/application needs. I do this today, but with Memcached.

rick schott
  • 21,012
  • 5
  • 52
  • 81
  • So basically option 1, and find a way to hash `SearchQuery` into a string? – Mike Christensen Jan 26 '12 at 17:02
  • Yes, we base our key on the Lib + Method + etc...to gen a unique key for the call, you could do the same based on the SearchQuery/Params. – rick schott Jan 26 '12 at 17:11
  • The ability to get a unique string hash for a `SearchQuery` definitely has a lot more flexibility. For example, if I add more web servers and want to setup a distributed cache some day, I would have a lot more options available to me. – Mike Christensen Jan 26 '12 at 17:18
  • We do exactly what Rick describes with great results - using a distributed cache was also preferred to the in-memory cache as our web servers are loadbalanced. – Mustafa Shabib Jan 27 '12 at 06:29
  • I ended up doing this, and generating the string cache key turned out to be pretty trivial. I just serialize everything to a byte array, and then return `Convert.ToBase64String(bytes)` for the key. – Mike Christensen Jan 28 '12 at 04:19
3

An in-memory cache should be pretty easy to implement. I can't think of any reason why you should have particular concerns about validating the uniqueness of a SearchQuery object versus any other - that is, while the key must be a string, you can just store the original object along with the results in the cache, and validate equality directly after you've got a hit on the hash. I would use System.Web.Caching for the benefits you've noted (expiration, etc.). If there happened to be a collision, then the 2nd one would just not get cached. But this would be extremely rare.

Also, the amount of memory needed to store search results should be trivial. You don't need to keep the data of every single field, of every single row, in complete detail. You just need to keep a fast way to access each result, e.g. an int primary key.

Finally, if there are possibly thousands of results for a search that could be cached, you don't even need to keep an ID for each one - just keep the first 100 or something (as well as the total number of hits). I suspect if you analyzed how people use search results, it's a rare person that goes beyond a few pages. If someone did, then you can just run the query again.

So basically you're just storing a primary key for the first X records of each common search, and then if you get a hit on your cache, all you have to do is run a very inexpensive lookup of a handful of indexed keys.

Jamie Treworgy
  • 23,934
  • 8
  • 76
  • 119
2

Give a quick look to the Enterprise library Caching Application Block. Assuming you want a web application wide cache, this might be the solution your looking for.

rie819
  • 1,249
  • 12
  • 19
  • Yea, I looked into this a bit as well as the AppFabric stuff. However, in my situation I don't really see a benefit to this over the `System.Web.Caching` support built into ASP.NET. – Mike Christensen Jan 26 '12 at 16:54
  • While this post goes against my suggestion, considering your situation, it's worth the read: http://stackoverflow.com/questions/21870/system-web-caching-vs-enterprise-library-caching-block. I highly agree with the "create a wrapper" statement so no matter what solution you pick, it's easy to sub out later if need be. – rie819 Jan 26 '12 at 17:34
  • Yup! For sure, I'd love to just wrap the whole thing up so I can drop in NCache or AppFabric someday if I want to scale out. Great advice. – Mike Christensen Jan 26 '12 at 17:39
1

I'm assuming that generating a database query from a SearchQuery object is not expensive, and you want to cache the result (i.e. rowset) obtained from executing the query.

You could generate the query text from your SearchQuery object and use that text as the key for a lookup using System.Web.Caching.

From a quick reading the documentation for the Cache class it appears that the keys have to be unique - which they would be if you used they query text - not the hash of the key.

EDIT

If you are concerned about long cache keys then check the following links:

Cache key length in asp.net

Maximum length of cache keys in HttpRuntime.Cache object?

It seems that the Cache class stores the cached items in an internal dictionary, which uses the key's hash. Keys (query text) with the same hash would end-up in the same bucket in the dictionary, where its just a quick linear search to find the required one when do a cache lookup. So I think you'd be okay with long key strings.

The asp.net caching is pretty well thought out, and I don't think this is a case where you need something else.

Community
  • 1
  • 1
Andy Johnson
  • 7,938
  • 4
  • 33
  • 50
  • Yea, or key by the serialized XML or JSON of `SearchQuery` - I wonder if there's any issues with really long cache keys.. Either way, it seems kinda like a hacky way to key items which is why I'm wondering if I'm better off implementing my own in-memory cache which can key by an object and handle key collisions internally. – Mike Christensen Jan 26 '12 at 17:09
  • Yea, looks like a lot of people have been curious about using very verbose keys as well. Since internally the cache stores by 32bit hash, they should have just made the key an object in the first place :) – Mike Christensen Jan 26 '12 at 17:36
  • I tried to explain this in my answer, but instead of worrying about possible duplicate hashes, why don't you just store the `SearchQuery` object along with its results when you cache it? Then just do a straight equality test with the object you're looking up vs. the one that was stored with that hash. The chances of a duplicate hash should be very low, so the only consequence of a collision is that you can't cache both queries. But even if this happened ever, it would just be one query that didn't get cached. – Jamie Treworgy Jan 26 '12 at 20:58