3 ms·
How about having two pools, one for writes only, and the other one for reads? SQLite allows you to open the DB more than in one thread per application, so you c
by nasretdinov 3y ago
How about having two pools, one for writes only, and the other one for reads? SQLite allows you to open the DB more than in one thread per application, so you can have a read pool and a write pool with SetMaxConnections(1) for better performance. This of course also means that reads should be handled separately from writes in the API layer too.
- nalgeon 3y agoThought about it, decided to start with simpler and good enough option. The goal here is not to beat Redis anyway.
- acrispino 3y agofor what it's worth, the two pool approach is suggested here by a collaborator to github.com/mattn/go-sqlite3: https://github.com/mattn/go-sqlite3/issues/1179#issuecomment-1638083995 https://github.com/mattn/go-sqlite3/issues/1179#issuecomment...
- nasretdinov 3y agoWell I agree, that's a good starting point. You probably won't be able to beat Redis with SQLite anyway :), although given that WAL mode allows for concurrent reads it might give it a large enough performance boost to match Redis in terms of QPS if the concurrency is high enough.