Modern day .NET applications must be well equipped to cope with the scalability demands being put on them due to the explosion of ASP.NET web applications reaching millions of users, WCF web services applications handling Internet of Things (IoT) devices, and Big Data analytics applications processing huge amounts of data. Scalability here means to maintain the same high performance under extremely heavy loads that you see with no load.
The architectures of these .NET applications are very scalable because you can add more app servers as you need higher transaction loads. But, the problem is with data storage, especially relational databases like SQL Server and Oracle, and mainframe. Basically, data storage is unable to scale in the same manner as the application tier.
Is Migrating to NoSQL a Right Strategy?
Some people propose that these .NET applications should stop using relational databases or mainframe and instead use a NoSQL database for .NET. But that is not possible in most cases because of business and legacy reasons. Relational databases also have various technical merits over NoSQL databases in how they’re able to handle the complexity of real world data.
Although, NoSQL databases don’t have the same scalability problems as relational databases, they can only be used for storing unstructured data and all structured data must still be kept in a relational database.
So, the bottom line is that NoSQL databases cannot completely replace relational databases. As a result, you still need to work with relational databases like SQL Server and Oracle whether you like or not and they have major scalability issues.
In-Memory NoSQL Store is different from NoSQL Database
So, what is the answer to this problem? Well, the answer is to continue using relational database but with another type of NoSQL. And, this is called In-Memory NoSQL store. Although, the name sounds very similar to NoSQL databases, however in reality is actually different. In-Memory NoSQL store is also called distributed cache or In-Memory Data Grid.
In-Memory NoSQL store does not persist any data on the disk for permanent storage. It keeps it in-memory and is therefore good only as a temporary store. As a result, it is not meant to replace relational databases that NoSQL databases claim to do. Instead, it is intended to be used “along with” relational databases and helps reduce pressure on them so they’re no longer a scalability bottleneck.
NCache as an In-Memory NoSQL Store
In-Memory NoSQL store like NCache can be used for caching data coming from relational databases so you can reduce database traffic that making them the bottleneck. It can also be used to store transient data (temporary data) created at runtime for a short period. One example of transient data is ASP.NET Session State storage in a load balanced web farm deployment.
In-Memory NoSQL store is linearly scalable in comparison to relational databases because it builds a dynamic cluster of In-Memory NoSQL storage servers and distributes all the data across these storage servers. And, you can easily add more servers at runtime without interrupting your applications as you need to handle a bigger transaction load.
Figure 1 shows you how an In-Memory NoSQL store like NCache is used by your application. NCache also synchronizes its store with relational databases to make sure the data in the In-Memory NoSQL store is always correct.
In most cases, your application uses a simple “cache API” to talk to the In-Memory NoSQL store and sees it as a cache. In other cases like ASP.NET Session State or ASP.NET View State caching, In-Memory NoSQL store usually has a pluggable module that plugs in directly without any code changes.
So, by using an In-Memory NoSQL store like NCache, your application can truly scale in a linear fashion and handle extreme transaction load. Now, whether you have web applications, web services applications, big data analytics applications, or other server applications with scalability needs, you are all set.
If you have a .NET application with scalability requirements, I recommend you take a look at NCache. Here are some useful links: