3 ms·

Where 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

Where 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.

siscia 10y ago
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?
- avmich 10y ago
  Can rqlite [1] be helpful here? [1] http://www.philipotoole.com/replicating-sqlite-using-raft-consensus/ http://www.philipotoole.com/replicating-sqlite-using-raft-co...
  - siscia 10y ago
    It may. The real question in my opinion is: What kind of replication we need? We want to replicate just to being sure that the data is safe? Then really you could simply stream to all the replicas what happens to the master. You want to increase read performance? Then you first start caching result, then you start stream to slave and only make read from them. You want to increase write performace? That is quite a bad beast. You start by making the single instance as fast as possible (96k insert per second [1]) then you pretty much hit the ceiling in my opinion. You could partition the SQL tables, but then what happens to joins and select? They must go over the network (high latency), spot distributed deadlock (highly variable latency) and it start to become an huge complex project. [1]: http://stackoverflow.com/questions/1711631/improve-insert-per-second-performance-of-sqlite http://stackoverflow.com/questions/1711631/improve-insert-pe...
- hoschicz 10y ago
  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.
  - siscia 10y ago
    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?
  - ddorian43 10y ago
    see actordb (does the first not second)
dom0 10y ago
This is the source: https://github.com/RedBeardLab/rediSQL/blob/master/rediSQL.c https://github.com/RedBeardLab/rediSQL/blob/master/rediSQL.c > Where does it save the data? It doesn't >> in-memory database. > Does it support replication? That's really, really unlikely, because you can't do that on the sqlite VFS layer. > migration off SQLite to a solid DB. This is SQLite (in redis).
- siscia 10y ago
  Replication is always tricky do to it right. The very first and naive solution would be to simply stream all your statements to the slaves.

siscia 10y ago

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?

avmich 10y ago
Can rqlite [1] be helpful here? [1] http://www.philipotoole.com/replicating-sqlite-using-raft-consensus/ http://www.philipotoole.com/replicating-sqlite-using-raft-co...
- siscia 10y ago
  It may. The real question in my opinion is: What kind of replication we need? We want to replicate just to being sure that the data is safe? Then really you could simply stream to all the replicas what happens to the master. You want to increase read performance? Then you first start caching result, then you start stream to slave and only make read from them. You want to increase write performace? That is quite a bad beast. You start by making the single instance as fast as possible (96k insert per second [1]) then you pretty much hit the ceiling in my opinion. You could partition the SQL tables, but then what happens to joins and select? They must go over the network (high latency), spot distributed deadlock (highly variable latency) and it start to become an huge complex project. [1]: http://stackoverflow.com/questions/1711631/improve-insert-per-second-performance-of-sqlite http://stackoverflow.com/questions/1711631/improve-insert-pe...
hoschicz 10y ago
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.
- siscia 10y ago
  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?
- ddorian43 10y ago
  see actordb (does the first not second)

dom0 10y ago

This is the source: https://github.com/RedBeardLab/rediSQL/blob/master/rediSQL.c https://github.com/RedBeardLab/rediSQL/blob/master/rediSQL.c > Where does it save the data? It doesn't >> in-memory database. > Does it support replication? That's really, really unlikely, because you can't do that on the sqlite VFS layer. > migration off SQLite to a solid DB. This is SQLite (in redis).

siscia 10y ago
Replication is always tricky do to it right. The very first and naive solution would be to simply stream all your statements to the slaves.