3 ms·

It's a simplification for the threading implementation. Spawning a new connection per thread would work but then I'd probably have to deal with failed transacti

It's a simplification for the threading implementation. Spawning a new connection per thread would work but then I'd probably have to deal with failed transactions. The bottleneck wasn't there though, INSERT performance will just naturally have that behavior: https://stackoverflow.com/questions/1711631/improve-insert-per-second-performance-of-sqlite https://stackoverflow.com/questions/1711631/improve-insert-p... Without batching several INSERTs into a single transaction you can't do very many of them which is why I ended up doing a caching layer and batching them.

bob1029 7y ago
I would recommend giving it a try regardless. This is the exact approach we use today and we are seeing zero issues. I am not sure why you think you will see failed transactions. It is a perfectly legitimate/recommended approach to create a new connection per logical transaction.
- pedrocr 7y ago
  If the locking is moved to the database concurrent transactions can happen. If those touch the same rows one of them will have to fail to maintain consistency. The bottleneck wasn't there though. Even a single thread doing INSERTs is more than enough to slow down the database. You probably don't have a write-heavy workload.
  - pdimitar 7y ago
    Well, sqlite is not recommended for write-heavy workflows anyway. I have the same impressions as your parent commenter: passing around an sqlite connection handle is thread-safe and always will be faster than application-level locking. If you do however have a write-heavy workflow then it's likely time to replace sqlite.
    - pedrocr 7y ago
      >I have the same impressions as your parent commenter: passing around an sqlite connection handle is thread-safe and always will be faster than application-level locking. I'm not debating that. It's just that that's not the current bottleneck so no point in dealing with the extra complexity. The current solution can saturate my SSD with low CPU usage. >If you do however have a write-heavy workflow then it's likely time to replace sqlite. That's definitely true. But there's no other SQL database to embed that I know of. That's why I mentioned wanting postgres as a lib. I know of other options that are non-SQL and will require extra rework. If there's an SQL option I'm all ears.
      - pdimitar 7y ago
        I did a research about a month ago and was very disappointed. Basically, outside BerkeleyDB and Firebase semi-embedded mode (since it is still not fully embedded) we're on our own. From then on, you can just use BoltDB or its successor(s) if you don't care about SQL. Which I do, and you seem to as well. At this point I am thinking of developing an Elixir wrapper for sqlite that can also do a best effort strong-typing and be done with it. It seems sqlite made many developers complacent, but then again, the raging consumerism and micro-management economy we live in worldwide does not exactly encourage tinkering and OSS contributions.
        pedrocr 7y ago
        I've been loosely following this: https://github.com/spacejam/sled https://github.com/spacejam/sled Since I'm writing in rust it might be a good fit. It's non-SQL but does have some nice features. I would need to figure out how to adapt all the syncer features to that model though. Right now I should just focus on finishing the merging code to be able to release a 1.0 some time soon.
        pdimitar 7y ago
        Not to be a complete cynic but IMO you should just use any of the pretty well-done NoSQL K/V stores if you don't mind ditching SQL. There's plenty that are very well done, BoltDB successors and FoundationDB included. BTW I've heard very good things about the widely used sqlite Rust libraries (sorry, don't remember the names).

bob1029 7y ago

I would recommend giving it a try regardless. This is the exact approach we use today and we are seeing zero issues. I am not sure why you think you will see failed transactions. It is a perfectly legitimate/recommended approach to create a new connection per logical transaction.

pedrocr 7y ago
If the locking is moved to the database concurrent transactions can happen. If those touch the same rows one of them will have to fail to maintain consistency. The bottleneck wasn't there though. Even a single thread doing INSERTs is more than enough to slow down the database. You probably don't have a write-heavy workload.
- pdimitar 7y ago
  Well, sqlite is not recommended for write-heavy workflows anyway. I have the same impressions as your parent commenter: passing around an sqlite connection handle is thread-safe and always will be faster than application-level locking. If you do however have a write-heavy workflow then it's likely time to replace sqlite.
  - pedrocr 7y ago
    >I have the same impressions as your parent commenter: passing around an sqlite connection handle is thread-safe and always will be faster than application-level locking. I'm not debating that. It's just that that's not the current bottleneck so no point in dealing with the extra complexity. The current solution can saturate my SSD with low CPU usage. >If you do however have a write-heavy workflow then it's likely time to replace sqlite. That's definitely true. But there's no other SQL database to embed that I know of. That's why I mentioned wanting postgres as a lib. I know of other options that are non-SQL and will require extra rework. If there's an SQL option I'm all ears.
    - pdimitar 7y ago
      I did a research about a month ago and was very disappointed. Basically, outside BerkeleyDB and Firebase semi-embedded mode (since it is still not fully embedded) we're on our own. From then on, you can just use BoltDB or its successor(s) if you don't care about SQL. Which I do, and you seem to as well. At this point I am thinking of developing an Elixir wrapper for sqlite that can also do a best effort strong-typing and be done with it. It seems sqlite made many developers complacent, but then again, the raging consumerism and micro-management economy we live in worldwide does not exactly encourage tinkering and OSS contributions.
      - pedrocr 7y ago
        I've been loosely following this: https://github.com/spacejam/sled https://github.com/spacejam/sled Since I'm writing in rust it might be a good fit. It's non-SQL but does have some nice features. I would need to figure out how to adapt all the syncer features to that model though. Right now I should just focus on finishing the merging code to be able to release a 1.0 some time soon.
        pdimitar 7y ago
        Not to be a complete cynic but IMO you should just use any of the pretty well-done NoSQL K/V stores if you don't mind ditching SQL. There's plenty that are very well done, BoltDB successors and FoundationDB included. BTW I've heard very good things about the widely used sqlite Rust libraries (sorry, don't remember the names).