3 ms·

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 to

• 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)