In memory database in .net [closed]

Question

I have a .net application where i want to use In-Memory data structure. Please advice me how it works in compare to the physical database.

Answer 1

In-Memory Database (IMDB) is a memory-resident relational database that eliminates disk access by storing and manipulating data in main memory. An IMDB usually features a strict memory-based architecture and direct data manipulation.

A bit related stuff's :

• Good in-memory database for .net/PowerShell?
• SQLite in-memory database backup in .NET
• Alternative to the TimesTen in memory database in .NET

Answer 2

There are two myths that should be corrected when you describe memory databases.

1) "A memory database is less persistent that a disk database". While this is true for simpler memory databases, enterprise level memory databases secures data to disk when they commit transactions. Disks are only slow when the disk arms move. If you think about it, you can write a gigabyte in seconds on a fast disk. And if your database changes by that much, you can secure terabytes per day in real time. This makes ram databases such as HANA and Starcounter as safe as disk databases while super fast. You can turn of the power at any time and checkpoints and recoveries works the same as for disk based databases.

2) "Memory databases are much faster." The reason why memory databases are faster is simply because they operate in memory. If you put a traditional database on a RAM drive, nothing much happens. In fact, as caches these days typically exceeds your database size, they already reside in memory. The reason the memory database is so much more efficient is that the database image is treated as primary memory and not secondary memory. This means that a modern RAM database does not copy pages from disk image to RAM when it reads data. In modern servers, the memory wall quickly becomes a bottleneck. This is avoided in RAM databases. The second reason is that when you develop something for a medium that is thousands of times faster than disk, you tend not to add overhead in microseconds and milliseconds as things that consumes nanoseconds are immediately visible. At the scale of disks, there is no reason to optimize code at this level. When suddenly RAM prices drop (98% since 2000), you cannot just rewrite your whole database engine.