views:

319

answers:

2

Hello. I have a search functionality on my site that is accessible from every page. Typical top of the masterpage textbox and button deal. I'm looking for a better way to accomplish my caching of the most common search strings and their result using System.Web.Caching.Cache.

I was thinking of concatenating the search string with some applicable user group permission data and using that as the cache key with the value being the List.

example cache key:

Microsoft Visual Studio 2008 Service Pack 1--usergroup2,3,6,17,89

But that got me thinking about what's the max length of cache key. Is there a max length that the key can be? By trying to store things this way can end up with some pretty lengthy key name values and it really doesn't do anything about keeping the most common searches as well the most recently used.

Is there already a commonly used method to accomplish what I'm trying to do? Does my question even make sense? Thanks for any help.

A: 

Caching search results is a fairly common technique. ASP.NET Cache will store all the cached data in memory for faster access. It all depends on how much memory is available to you for caching. If you want to deviate from the ASP.NET Cache approach, there's another mehtod for implementing this - that method for caching the data retrieved from search is to store it in a database table.

Searching a table with billions of records is really expensive; so, you can store the data for the most searched keywords in a table for faster access. You can also create a job to refresh the table at regular intervals, based on some fairly easy algorithms. Least Recently Used algorithm, for example. You can remove the search results which have not been used recently.

EDIT: And, as for your question for the length of the cache key; it is a string, and the length of a string is dependent on the memory available to store it.

Kirtan
A: 

But that got me thinking about what's the max length of cache key. Is there a max length that the key can be? By trying to store things this way can end up with some pretty lengthy key name values and it really doesn't do anything about keeping the most common searches as well the most recently used.

The length for the key is the maximum length of the "string" itself.

According to the documentation here : http://msdn.microsoft.com/en-us/library/system.web.caching.cache.add.aspx, the key can be defined in a string with the value in Object type.

I would suggest to tag a custom Object with a unique key, so that when you query from the Cache, you can object your custom Object with more complex information tagged along in the Custom Object.

EDIT 11072009_1154

After i carefully read your requirement again, i noticed that your objective is to cache the frequently search string.

In your given example, the frequently search string might be "Microsoft Visual Studio 2008 Service Pack 1". In my opinion this should be the key, while the value is a custom object which will have additional properties to hold your other necessary attributes.

In summary, this might be the example : Key : "Microsoft Visual Studio 2008 Service Pack 1" Value : CustomObjectInstance where : CustomObjectInstance.UserLanguage = "English" and CustomObjectInstance.UserLocalization : "USA" , CustomObjectInstance.UserKeyboardLayout = "UK" etc.

AFAIK, The Cache implement a dictionary type of data structure, so the key must be unique enough. So if your key is "Microsoft Visual Studio 2008 Service Pack 1--usergroup2,3,6,17,89" How can you uniquely identify this particular key from your ASp.NET web apps ? Because in my search textbox, i will not insert usergroup2,3,6,17,89

Think also like StackOverflow site search functionality: users will insert a common search string i.e. "learn jquery material", then in my opinion, your cache key should have an entry of "learn jquery material".

EDIT 11072009_1250

Thanks for the additional information. I can also give additional solution by enforcing multiple layers, what i mean is, rather than cramming all the information into one layer of cache, why not store additional layer.

Means that your cache will have a key (string) and a value which point to a dictionary again.

Another possible solution, is to push these feature by using SQL Server Full Text Index Search, i am not quite familiar to the SQL Server Full Text Index Search, but it can be good if we can leverage this functionality to existing infrastructure if possible.

hadi teo
"...tag a custom Object with a unique key, so that when you query from the Cache, you can object your custom Object with more complex information tagged along in the Custom Object."Can you give me some sort of pseudo example on this? Are you saying to cache some custom obj that would hold both the search details as a property along with a prop of the result list? See, originally what I was thinking I would do was build a string of the search details to use as the cache key with it's value being the List<T>
Billyhole
@Billyhole, please refer to my updated answer above.
hadi teo
Thanks, I appreciate your input. Just to answer your question, I would get the usergroup data from the info of my currently logged in user whose doing the searching. The thing is that with our search, the same search string would not necessarily return the same data for every user. Different usergroups have access to different data. So doing my original plan should work out, just wasn't sure if there was a recognized common way that people were dealing with this common requirement. Thanks.
Billyhole