3 ms·

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

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 module doesn't simplify anything (as far as I understand), since SQL is used anyway. 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.

siscia 10y ago
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.
edibleEnergy 10y ago
Well, SQLite has to be accessed over a filesystem. This sounds like it would proxy to a sqlite db located on the Redis server. Still sounds dicey but I could see the appeal if you didn't have the DBA skills necessary to set up a decent PostgreSQL or other SQL server.
- pizza234 10y ago
  Well, although the requirements which would lead to such setup are clearer now, it's still smelly to me. Under this conditions there is still a false dichotomy between RediSQL on one side, and "complex RDBMS" on the other. What about simple RDMSs like H2? Such solution would meet the requirements: - network-accessible RDBMS - no configuration The only requirement I can think of which would make this solution inadequate would be "No JVM on the system", which sound quite far-fetched.

siscia 10y ago

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.

edibleEnergy 10y ago

Well, SQLite has to be accessed over a filesystem. This sounds like it would proxy to a sqlite db located on the Redis server. Still sounds dicey but I could see the appeal if you didn't have the DBA skills necessary to set up a decent PostgreSQL or other SQL server.

pizza234 10y ago
Well, although the requirements which would lead to such setup are clearer now, it's still smelly to me. Under this conditions there is still a false dichotomy between RediSQL on one side, and "complex RDBMS" on the other. What about simple RDMSs like H2? Such solution would meet the requirements: - network-accessible RDBMS - no configuration The only requirement I can think of which would make this solution inadequate would be "No JVM on the system", which sound quite far-fetched.