6 ms·
This is a common problem. Bulk inserts should be done within a single txn if possible. The limit isn't insert throughput, but transaction throughput. I've comm
by srcreigh 5y ago
This is a common problem. Bulk inserts should be done within a single txn if possible. The limit isn't insert throughput, but transaction throughput.
I've commented elsewhere here for docs referencing this problem. It's FAQ#19 on the SQLite website.
Was your inserts based on HTTP requests or was it more of a batch process? we're they grouped in txns? Obviously user http requests would be harder to group up, but kudos if your service is handling 100 QPS writes as that's pretty rare level of scale approaching the real "need a beefy concurrent db server" type of problem statement.
- jjoonathan 5y agoThe inserts were batched. That was the second thing I tried after getting rid of the index, and that brought it from 20/s to 100/s. This wasn't a website, it was HPC job tracking. SQLite chugged so hard that the tail wagged the dog, though.
- srcreigh 5y agoI'm not contradicting you, it is curious what you saw, but this SQLite FAQ does claim that 50k/s inserts on a normal computer HDD is possible. Maybe there was some other resource constraint or configuration somewhere. It is very curious. > Actually, SQLite will easily do 50,000 or more INSERT statements per second on an average desktop computer. But it will only do a few dozen transactions per second. Transaction speed is limited by the rotational speed of your disk drive. A transaction normally requires two complete rotations of the disk platter, which on a 7200RPM disk drive limits you to about 60 transactions per second.