内存缓存中的SQL Server

Question

I want to implement a simple in memory cache for an sql server 2008 R2 Express Edition.

Requirements:

1. The cache must be visible for all users
2. The cache is synchronized with a persistent table. Over this persistent table might occur heavy CRUD operations.

My solution: Create a bucket of CLR procedures that stands into a .NET assembly. These procedures will be named:

• Add (param1, ... paramN);
• Remove (param1 ... paramN);
• GetAll ();

where param1... paramN is my persistent table data specific that i want to cache.

Behind the scenes I will organize in memory data maybe into a HashSet for O (1) add / remove. Then, I will create a trigger for Insert / Delete operations (only inserts and deletes can occur on the persistent table) that would call these methods (Add / Remove). The big issue is that the transaction can be rolled back. How can I find out that the transaction with a specific ID was rolled back? There is a server level event that I can listen?

Please give me whatever alternatives you know. I know that SQL Server 2014 supports memory optimized OLTP tables but ... this feature is active only for SQL Server enterprise edition :D.

Another alternative would be to create a temporary table with ## (visible on all connections) BUT:

1. The table will be stored in TEMPDB. If the tempDB is stored in RAM, there might be a performance boost but then it comes the second issue:

2. Searching in it (for a specific item) in this temporary table will cost me O ( Log ( N )) because behind the scenes if I create an index, there will be a B-tree. My In memory alternative will ensure that lookups will cost O (1).

Answer 1

If you have enough RAM, you're really not reading the data from disc, all your often accessed data will be in memory. I don't really know the limits of express edition in detail, so those could be causing issues you're facing. I think you should at least consider upgrading to standard version, especially if you very big number of records, since you'll most likely run out of space too.

Temp DB is no exception, it will be either in disc or RAM, depending on how much memory you have and what is being accessed the most. Just creating cache 1:1 for data from other tables into tempdb is not useful, you'll just waste your memory for storing the same data twice.

The in memory OLTP of SQL Server 2012 wouldn't probably help you at all. The point of it is not that you have the data in memory, but to reduce the overhead of locking & latching etc.