Hello again, today I would like to talk about SSDB – high-performance NoSQL database as a cheaper drop in replacement for Redis.
Redis in most cases is the best solution for managing a high-througput and low-latency data access. It’s also open source and free to use. But using Redis might be expensive in terms of higher costs for hardware resources utilization. For example, I was recently required to store a lot of keywords, which number per task was virtually unlimited. Redis was a first option coming to my mind. I’ve started to look around for existing services which hosts Redis, and found that the prices were much over expectations. At redislabs.com to get the database storage of 15 GB would cost about USD1000 per month. This is the cheapest I could find so far. Thus, in case, one would need to store large amounts of data, he would have to pay quite a fortune to do this with Redis. Such prices explained by the fact that Redis is in-memory database and memory is an expensive resource. So I started to think about alternatives and search for Redis-like disk-based database which will reduce the costs without compromising the speed.
Ask and it will be given to you.
Eventually, as I was doing my search, I came across SSDB – high performance NoSQL database. It supports most of Redis protocol and can be used as a drop in replacement for Redis. It even can be accessed with Redis clients. There is a list of supported Redis commands and the way they map to SSDB. While being disk based, SSDB can store much more data, than Redis on the same machine, which is much cheaper.
Every programmer should know that 1 disk seek is by 100.000 times slower than an access to RAM. Therefore, how possibly disk-based database can be as fast as in-memory one?
The answer is – a little bit of magic and voila … LevelDB design, which implements SSTable (Sorted Strings Table, hence the name for SSDB). Credit to Google.
Describing briefly, the process works as follows: the database queries, which change the data (writes, updates and deletes) are stored as a deltas in memory layer which is fast. Once the specified size of such layer is reached, all those deltas dumped to disk. Being sorted, the data is written to disk sequentially, which is only by 3 times slower than writing to RAM (not x100.000 times slower as I mentioned before). Such dumps occur once a while thus giving us the amortized performance comparable to in-memory’s one. Reads are done by searching in-memory layer first and then, if not found – accessing the disk (worst case).
The worst case scenario, performing many random seeks to disk, in theory would be significantly slower. However, let’s keep in mind that in such a case, when the data size is bigger than memory available, any in-memory database would be already overflown and effectively dead. Thus the above comparison is still in favor of SSDB.
I made a quick benchmark with redis-benchmark tool to Redis server:
➜ ~ redis-benchmark -p 6379 -n 50000 -t set,get -q
SET: 77399.38 requests per second
GET: 62972.29 requests per second
and the same procedure to SSDB server, running on the same machine, with same redis-benchmark tool:
➜ ~ redis-benchmark -p 8888 -n 50000 -t set,get -q
SET: 61652.28 requests per second
GET: 63451.78 requests per second
We can see that SSDB’s
set is only 20% slower, but
get is slightly faster then
get of Redis.
Concluding the above, we saw that SSDB in most cases is as fast as Redis, and worst case for SSDB is not even supported by Redis. There is an attempt to overcome this problem with hybrid solution such as Redis + MongoDB or Redis + PostgreSQL, where Redis provides a cache-like layer in front of disk-based database. Such approach seems to be not trivial at all, when it comes to scaling and synchronizing the different databases between themselves.
SSDB provides solution to all of these cases at once. No more hybrid solutions needed.
Many companies have already recognized advantages of SSDB. Thus Chinese search giant Baidu uses SSDB for their most important service – Web Search. QIHOO 360 which operates hundreds of millions users, migrated its Redis instances to SSDB, and now it uses less servers for storage.
When I realized there is no simple way to use SSDB from Heroku platform, I created ssdbhub.com which provides SSDB as Heroku add-on.
WE ARE LOOKING FOR ALPHA TESTERS FOR THIS ADD-ON
Our first users will be given away 5 GB Free Plan for unlimited period of time.
To claim your free plan, drop your email at ssdbhub.com
To get started, refer to documentation. There is a comprehensive guide on how to create the SSDB add-on on Heroku and how to access it, using your favorite programming language.
It’s extremely important to us to get your feedback, If you have any technical issues, fill free to open the public discussion on our issue tracker or send us a direct message to firstname.lastname@example.org, whichever works best for you.
A journey of a thousand miles begins with a single step.