So a typical ssd will have a read speed of 250 - 500 mb / second. And a ram will have about 10x than that.
Just what kind of RAM are you referring to? Certainly not something that has been in common use in PCs recently, it would seem.
DDR3 SDRAM can trivially give you a transfer rate of around 10 GB/s (you need DDR3-1333 for that) and currently tops out at about 17 GB/s for DDR3-2133.
Let's say you stripe four SSDs capable of delivering 500 MB/s and the overall system is capable of handling that (no bus contention, the system is still I/O-bound, etc.). This gives you a theoretical maximum throughput of 2 GB/s. The 4xSSD loses out by nearly a factor of 10.
DDR3 SDRAM has a latency in the 10 ns region. A good SSD might give you 100k IOPS, tops, which translates to a latency of 10,000 ns. (For example, the Intel 530 specifies a 41k IOPS for random 4k reads, which gives you a latency of nearly 25,000 ns.)
Stripe four fast SSDs and ignore all overhead, and you might get 400k IOPS, or 2,500 ns latency. The 4xSSD loses out by a factor of 250.
The data from the SSD has to go to somewhere, and that "somewhere" will be RAM. The CPU can grab it from there, but it does not talk directly to the SSD any more than it talks directly to a spinning-platter hard disk drive.
If we assume that you don't suffer from bus contention on the SSD, it makes sense to assume the same thing for the RAM. Which leads to the conclusion that by either of these metrics, a SSD is horrendeously slow compared to DDR3 SDRAM.
RAM has other drawbacks. Even compared to SSDs it is very expensive per gigabyte, and it needs constant power to retain its contents. Also, a RAM disk does not function quite the same as RAM, as it is a software construct in the operating system. You should still get most of the performance benefit of RAM, but you lose out on the same amount of RAM which may cause the system to need to resort to swapping more often (which is a death sentence for performance) and it likely won't give quite the same performance as raw RAM would.
I pretty much agree with the above, with the exception of transaction logs, which MUST be written to disk. For the highest-performance transactional systems, I often specify that logs are maintained on flash-backed RAM drives. – Curt – 2015-09-03T17:46:17.097
ramdisk it is then.. – Koray Tugay – 2013-12-10T13:37:10.277
1@KorayTugay If you need the absolute most in performance, you should go with a RAM disk, but keep in mind that a RAM disk does not function quite the same as RAM and has its own set of drawbacks, not the least of which being price. (Also, while I appreciate the accept, I encourage you to wait a day or so before accepting an answer in case someone else provides an even better answer.) – a CVn – 2013-12-10T13:39:34.210
@KorayTugay: Generally speaking, the answer to "Do I need a RAMDisk?" is almost always "No. If you really needed it, you'd know enough that you wouldn't have to ask." What are you doing that makes you think you'll need it? – afrazier – 2013-12-10T15:39:35.897
@afrazier development / testing with a huge database and I access it many times for and a lot of data is fetched from it. I will keep the db in the ram. I do this for 8 10 hours a day and waiting for 4 5 seconds seem too long after some time. I need to hit the db faster. – Koray Tugay – 2013-12-10T17:39:04.737
5Any competent DBMS will keep as much of the DB in RAM as possible. If your DB is tiny enough to fit in a RAMdisk, it's tiny enough to just fit in RAM. Properly tuning your DBMS with an SSD will give you the performance you're looking for -- for local development, you can even take advantage of things like write back caching and worrying less about ACID. A RAMdisk is fighting the system. – afrazier – 2013-12-10T18:26:33.230