Hello siscia, do you have any benchmark against a sqlite Db on Ramdisk?
RediSQL – A Redis module that provides a functional SQL database
21–30 of 60 posts
Re: RediSQL – A Redis module that provides a functional SQL database
#22Hello siscia, do you have any benchmark against a sqlite Db on Ramdisk?
Hi Azureel, benchmark are a little tricky in this situation.
You are sending data to the redis instance, that read your statement and pass it to the module, the module execute and finally reply.
And everything really depends on your network and load on redis itself.
However, to just give some number on my machine I do 1000 insert on 0.6 seconds, the longest insert took 0.01 second and overall I can claim a total of 1000 / 0.6 => 1600 insert per second. Consider that each insert is a isolated transaction.
The test I run is exactly the one you can find here: https://github.com/RedBeardLab/rediSQL/blob/381e3796ad31c231...
Of course, if you start to insert JOINS everything is slowing down.
Also please consider that, at the moment, it is a BLOCKING version, while executing the statements redis itself is waiting.
Finally I believe there are possibilities to improve this numbers.
Re: RediSQL – A Redis module that provides a functional SQL database
#23Where does it save the data? Just in a blob in Redis? Does it support replication? How about persistence - - can I use standard Redis persistence? I'm kinda new to modules in Redis. Definitely could use this for migration off SQLite to a solid DB.
Just update the readme. For now it works in memory, after Saturday it will save data in a standard SQLite file. Replication and SQL are fairly tricky beast together. What is your use case?
My use case is: one SQLite DB for every client, scaling by distributing clients across servers. I would like to have all clients in one DB and make scaling easier.
Re: RediSQL – A Redis module that provides a functional SQL database
#24Author here, if you have any question please feel free to ask. Also I have introduced the module in a blog post here: http://redbeardlab.tech/2016/12/13/redisql
Which would be a use case, from a technical perspective?
The blog mentions:
If you are writing microservices to avoid bothering the master of DB with your need ephemeral needs of structured database
I see this module perfect for small dataset of unimportant data.
I would understand this as an experiment (something like "ReDoom"), but since there will be a paid version, I'm trying to position the product technology.
Re: RediSQL – A Redis module that provides a functional SQL database
#25Author here, if you have any question please feel free to ask. Also I have introduced the module in a blog post here: http://redbeardlab.tech/2016/12/13/redisql
Which would be a use case, from a technical perspective? The blog mentions: If you are writing microservices to avoid bothering the master of DB with your need ephemeral needs of structured database and I see this module perfect for small dataset of unimportant data. In other words, why would one use this module in place of a straight SQLite database (possibly in-memory, if there is really such need for speed)? Such…
SQLite gives you a lot of simplicity over client-server databases such as Postgres or MySQL.
A straight SQLite database doesn't quite give to you the same kind of possibility, imagine you have multiple machine that want to access the data.
It is a middle ground between "full" SQL databases and simpler solution.
It does use Redis for the client-server communication which gives reliability and is already well know in most companies.
My suggestion to use it for small, unimportant data is because there is still not persistency on disk, I am working on it right now.
Re: RediSQL – A Redis module that provides a functional SQL database
#26Earlier quoted context omitted.
Just update the readme. For now it works in memory, after Saturday it will save data in a standard SQLite file. Replication and SQL are fairly tricky beast together. What is your use case?
My use case is: one SQLite DB for every client, scaling by distributing clients across servers. I would like to have all clients in one DB and make scaling easier.
That is quite interesting and achievable in reasonable bound of complexity.
I could associate each DB to a redis key and stream all the UPDATES on each db.
At this point you could simply listen to the stream and apply those updates to a master DB.
What you think?
Re: RediSQL – A Redis module that provides a functional SQL database
#27Fully in-memory SQL can also be accomplished using IMOLTP via MS SQL Express on Linux now as well. And you get a fairly feature complete engine along with multithreaded execution, no blocking, and some great client options. The only limits right now are 4 cores and ~350MB of in-memory data per database.
Re: RediSQL – A Redis module that provides a functional SQL database
#28Fully in-memory SQL can also be accomplished using IMOLTP via MS SQL Express on Linux now as well. And you get a fairly feature complete engine along with multithreaded execution, no blocking, and some great client options. The only limits right now are 4 cores and ~350MB of in-memory data per database.
My memory is a bit fuzzy right now, but isn't mysql itself providing that since forever too? Or do you fully in memory db - with a hard copy on the hard drive?
Re: RediSQL – A Redis module that provides a functional SQL database
#29Earlier quoted context omitted.
Just update the readme. For now it works in memory, after Saturday it will save data in a standard SQLite file. Replication and SQL are fairly tricky beast together. What is your use case?
My use case is: one SQLite DB for every client, scaling by distributing clients across servers. I would like to have all clients in one DB and make scaling easier.
see actordb (does the first not second)
Re: RediSQL – A Redis module that provides a functional SQL database
#30I tried to do the same (before great Lua support, using PHP), but overall performance was similar to MySQL (much more reliable than my experiment) so I abandoned it.
So would be very interesting to see benchmarks and comparisons with MySQL - I think right now we have more ways to implement it better.