NosDB In-Memory Caching

NosDB is an Open Source NoSQL database for .NET. It is extremely fast and scalable because it incorporates both server-side and client-side In-Memory Caching. NosDB also integrates NCache, the industry leader in .NET distributed caching.

Server-Side In-Memory Caching

NosDB makes full use of a variety of caching techniques within the NosDB database server. Alachisoft (maker of NosDB) is an expert in the field of distributed caching through its industry leader product NCache. Here are some caching techniques used in NosDB.

In-Memory Indexes: NosDB incorporates in-memory caching within database servers. Each NosDB server maintains all its indexes in-memory. So, when SQL SELECT queries are executed, it does not have to go through a disk-based index that would be very slow. Instead, it finds the entire index in memory and as a result the SQL query runs extremely fast.

Read-through/Write-through Cache: The NosDB server uses a Read-through/Write-through paradigm for fetching and updating individual JSON documents from the database. A Read-through approach means that there is a cache of JSON documents kept in memory that is searched upon a read request. If the JSON document is found in this cache, it is returned to the client. Otherwise, it is fetched from the disk storage and cached before returning it to the client. This way, the document is found in the cache next time around.

Similarly, the Write-through approach updates all JSON documents in the cache, returns the control to the client, and then updates the disk storage in the background. This way, the client doesn't have to wait for the write to complete and this improves client response time greatly. The client is notified upon completion of the update if the client chooses.

File System Cache: After caching documents in a Read-through/Write-through model, NosDB servers eventually write them to the disk based storage. For disk storage, NosDB uses Lightning Memory-Mapped Database (LMDB) that has a file system level in-memory caching feature. NosDB uses this feature which results in an extremely fast performance at this level.

Client-Side In-Memory Caching

In addition to using a variety of server-side caching techniques, NosDB also provides client-side in-memory caching. Client-side caching is especially important because it enables your applications to avoid making expensive database trips and instead fetches their documents and query results from a local cache.

InProc/OutProc Cache: The NosDB client-side cache actually uses a client-side version of NCache that is specially packaged for NosDB and is free with NosDB. As a result, the client-side cache can either be InProc or OutProc. InProc means all cached data is kept within your application process in object form so fetching is extremely fast. OutProc means there is a separate process on your local application server that is keeping all the cached data and all application processes access the same local Client Cache.

Query Cache: NosDB allows you to specify through the API which query results you want to cache. And, then it caches those query results for a configurable duration after which it expires them from the cache. NosDB caches the entire query result as one item in the cache. So, the next time you execute that same query and specify that the cache should be checked first, NosDB checks the client-side cache and if the query result is still in the cache, then it returns it.

Please note that NosDB does not break down each row of the query result into a separate JSON document to cache. The reason is simple. The client-side cache does not contain the entire database and therefore a SQL query should not be run against it since it will only return a subset of the data. So, the only benefit is in fetching the last run query as long as it does not expire. Secondly, documents found in query results are usually not fetched independently as individual documents. So, caching them separately doesn't add any value. If any document is ever fetched independently, it will be cached at that time.

Read-through/Write-through Cache: Just like the server-side cache, the client-side cache also uses a Read-through/Write-through cache paradigm. Whenever your application fetches individual JSON documents (either through NosDB API or through SQL SELECT statement), NosDB first checks the client-side cache for this document. If found, it returns it from the cache. Otherwise, it fetches the document from the database, caches it in the client-side cache, and returns it to the client.

Similarly, whenever your application tries to add or update a JSON document, NosDB also updates the client-side cache along with updating the database. This way, the JSON document in the client-side cache is consistent with the database version.

Client-side Cache Synchronized with the Database: Whenever you cache any documents or query results in the client-side cache, there is a possibility that it might be updated directly in the database by other applications or SQL tools. To handle such a situation, NosDB uses its SqlDependency feature that tells the NosDB server to notify this client whenever this particulate document or data in the query result is updated in the NosDB database. And, upon receiving such an event, NosDB client can either remove this document from the client-side cache or reload it. Either way, the client-side cache is always kept synchronized with the NosDB database.

NCache Integration

NosDB also provides an integration with NCache, the industry's leading distributed cache for .NET. NCache is also developed by Alachisoft, the makers of NosDB. NosDB integration with NCache works just like the Client-Side In-Memory Cache feature but with a few major differences. Below are more details.

Scalable Separate Caching Tier: NCache allows you to create a separate caching tier of two or more cache servers working as a cache cluster. This makes your cache extremely scalable not only in terms of data storage but also transaction capacity. The standard NosDB client-side cache (without NCache Integration) resides in a single process on the client machine (either InProc or OutProc). As a result, it cannot easily grow in size and even when you grow it, you're making that many more copies of the cache which eventually slows down your operations upon updates.

But, creating a common caching tier resolves all these size and synchronization cost issues. The caching tier keeps only one or two copies of each cached item depending on which caching topology you have used and this is highly efficient.

Client Cache (InProc/OutProc): Despite having a separate caching tier, NCache allows you to create a Client Cache (also called Near Cache) on the application server. This Client Cache is either InProc or OutProc and is a subset of the caching tier and provides the same benefits as the standard client-side cache in NosDB. Client Cache also lets you specify how much memory it should consume and it doesn't use more than this. Finally, the Client Cache automatically keeps itself synchronized with the caching tier.

NCache Synchronized with NosDB Database: Just like the standard NosDB client-side cache database synchronization feature, NCache also keeps itself synchronized with the NosDB database. NCache uses the SqlDependency feature of NosDB through which NosDB notifies NCache whenever the corresponding data of any cached item is updated in the database. Then, NCache either removes it from its cache or reloads it again from the NosDB database.

Using NCache API Directly: When you choose to use NCache integration, you have the option of accessing the NCache API directly. This allows you to take advantage of a very rich caching feature set of NCache. See more details about NCache.

What to Do Next?