SQLite insert speed slows as number of records increases due to an index

Question

Original question

Background

It is well-known that SQLite needs to be fine tuned to achieve insert speeds on the order of 50k inserts/s. There are many questions here regarding slow insert speeds and a wealth of advice and benchmarks.

There are also claims that SQLite can handle large amounts of data, with reports of 50+ GB not causing any problems with the right settings.

I have followed the advice here and elsewhere to achieve these speeds and I'm happy with 35k-45k inserts/s. The problem I have is that all of the benchmarks only demonstrate fast insert speeds with < 1m records. What I am seeing is that insert speed seems to be inversely proportional to table size.

Issue

My use case requires storing 500m to 1b tuples ([x_id, y_id, z_id]) over a few years (1m rows / day) in a link table. The values are all integer IDs between 1 and 2,000,000. There is a single index on z_id.

Performance is great for the first 10m rows, ~35k inserts/s, but by the time the table has ~20m rows, performance starts to suffer. I'm now seeing about 100 inserts/s.

The size of the table is not particularly large. With 20m rows, the size on disk is around 500MB.

The project is written in Perl.

Question

Is this the reality of large tables in SQLite or are there any secrets to maintaining high insert rates for tables with > 10m rows?

Known workarounds which I'd like to avoid if possible

• Drop the index, add the records, and re-index: This is fine as a workaround, but doesn't work when the DB still needs to be usable during updates. It won't work to make the database completely inaccessible for x minutes / day
• Break the table into smaller subtables / files: This will work in the short term and I have already experimented with it. The problem is that I need to be able to retrieve data from the entire history when querying which means that eventually I'll hit the 62 table attachment limit. Attaching, collecting results in a temp table, and detaching hundreds of times per request seems to be a lot of work and overhead, but I'll try it if there are no other alternatives.
• Set SQLITE_FCNTL_CHUNK_SIZE: I don't know C (?!), so I'd prefer to not learn it just to get this done. I can't see any way to set this parameter using Perl though.

UPDATE

Following Tim's suggestion that an index was causing increasingly slow insert times despite SQLite's claims that it is capable of handling large data sets, I performed a benchmark comparison with the following settings:

• inserted rows: 14 million
• commit batch size: 50,000 records
• cache_size pragma: 10,000
• page_size pragma: 4,096
• temp_store pragma: memory
• journal_mode pragma: delete
• synchronous pragma: off

In my project, as in the benchmark results below, a file-based temporary table is created and SQLite's built-in support for importing CSV data is used. The temporary table is then attached to the receiving database and sets of 50,000 rows are inserted with an insert-select statement. Therefore, the insert times do not reflect file to database insert times, but rather table to table insert speed. Taking the CSV import time into account would reduce the speeds by 25-50% (a very rough estimate, it doesn't take long to import the CSV data).

Clearly having an index causes the slowdown in insert speed as table size increases.

It's quite clear from the data above that the correct answer can be assigned to Tim's answer rather than the assertions that SQLite just can't handle it. Clearly it can handle large datasets if indexing that dataset is not part of your use case. I have been using SQLite for just that, as a backend for a logging system, for a while now which does not need to be indexed, so I was quite surprised at the slowdown I experienced.

Conclusion

If anyone finds themselves wanting to store a large amount of data using SQLite and have it indexed, using shards may be the answer. I eventually settled on using the first three characters of an MD5 hash a unique column in z to determine assignment to one of 4,096 databases. Since my use case is primarily archival in nature, the schema will not change and queries will never require shard walking. There is a limit to database size since extremely old data will be reduced and eventually discarded, so this combination of sharding, pragma settings, and even some denormalisation gives me a nice balance that will, based on the benchmarking above, maintain an insert speed of at least 10k inserts / second.

Stuart

How are you using transactions? How large have you configured the page cache? – Olnton

@Olnton cache_size is set to 10000. All inserts are in one transaction with commits every 50k inserts. These values were chosen after extensive testing to find the fastest insert speed (35k-45k inserts/s), but that speed drops as the number of records increases past about 10m. – Stuart

Going beyond your specific question here: may I ask, are you using the index on z_id to find individual records or to select ranges? – Redwine

@Redwine it's a link table, so items get selected from table_z then linked to table_y and table_x via z_id through this table. So, to answer your question, it helps find individual records. – Stuart

@veryhungrymike: In that case, you could look into a non-indexed hash-table nested-relational db that would allow you to instantly find your way to z_id rows and the y_ids and x_ids linked to a particular z_id without the indexing overhead and the concomitant degraded performance during inserts as the index grows. One that puts greater weight on the digits of z_id with greatest variation (right-weighted) would give you good distribution. – Redwine

I realize Im a decade too late, but it'd be interesting to see numbers for a NO ROWID table with PRIMARY KEY(z, counter). Then the table would be its own index. – Audio

Answer 1

If your requirement is to find a particular z_id and the x_ids and y_ids linked to it (as distinct from quickly selecting a range of z_ids) you could look into a non-indexed hash-table nested-relational db that would allow you to instantly find your way to a particular z_id in order to get its y_ids and x_ids -- without the indexing overhead and the concomitant degraded performance during inserts as the index grows. In order to avoid clumping (aka bucket collisions), choose a key hashing algorithm that puts greatest weight on the digits of z_id with greatest variation (right-weighted).

P.S. A database that uses a b-tree may at first appear faster than a db that uses linear hashing, say, but the insert performance will remain level with the linear hash as performance on the b-tree begins to degrade.

P.P.S. To answer @kawing-chiu's question: the core feature relevant here is that such a database relies on so-called "sparse" tables in which the physical location of a record is determined by a hashing algorithm which takes the record key as input. This approach permits a seek directly to the record's location in the table without the intermediary of an index. As there is no need to traverse indexes or to re-balance indexes, insert-times remain constant as the table becomes more densely populated. With a b-tree, by contrast, insert times degrade as the index tree grows. OLTP applications with large numbers of concurrent inserts can benefit from such a sparse-table approach. The records are scattered throughout the table. The downside of records being scattered across the "tundra" of the sparse table is that gathering large sets of records which have a value in common, such as a postal code, can be slower. The hashed sparse-table approach is optimized to insert and retrieve individual records, and to retrieve networks of related records, not large sets of records that have some field value in common.

A nested relational database is one that permits tuples within a column of a row.

Redwine

Thanks for the further explanation. But most of the dbs that I know of either use b-tree or LSM-tree. Could you name some dbs that use linear hashing? – Agronomy

After reading more on linear hashing, I think it is still not the solution for really big data generally. Because either you have a smaller hash map with a lot of collisions, or your hash map becomes almost as big as your data. The author of lmdb prefers b tree, too. – Agronomy

No "hash map" is required; the file space is divided into addressable pages. And did I ever say LH was the solution for "really big data generally"? As I made clear, LH is optimized for OLTP applications where individual records are inserted and retrieved. LH is great for pulling up dossiers or a person's medical record or a user profile on a social networking site. No indexes are required for such retrieval and the retrieval is instantaneous nonetheless. LH it is not optimized for "big data" analytics, where subsets of data are extracted having some common field(s). – Redwine

Answer 2

Great question and very interesting follow-up!

I would just like to make a quick remark: You mentioned that breaking the table into smaller subtables / files and attaching them later is not an option because you'll quickly reach the hard limit of 62 attached databases. While this is completely true, I don't think you have considered a mid-way option: sharding the data into several tables but keep using the same, single database (file).

---

I did a very crude benchmark just to make sure my suggestion really has an impact on performance.

Schema:

CREATE TABLE IF NOT EXISTS "test_$i"
(
    "i" integer NOT NULL,
    "md5" text(32) NOT NULL
);

Data - 2 Million Rows:

• i = 1..2,000,000
• md5 = md5 hex digest of i

Each transaction = 50,000 INSERTs.

---

Databases: 1; Tables: 1; Indexes: 0

0..50000 records inserted in 1.87 seconds
50000..100000 records inserted in 1.92 seconds
100000..150000 records inserted in 1.97 seconds
150000..200000 records inserted in 1.99 seconds
200000..250000 records inserted in 2.19 seconds
250000..300000 records inserted in 1.94 seconds
300000..350000 records inserted in 1.94 seconds
350000..400000 records inserted in 1.94 seconds
400000..450000 records inserted in 1.94 seconds
450000..500000 records inserted in 2.50 seconds
500000..550000 records inserted in 1.94 seconds
550000..600000 records inserted in 1.94 seconds
600000..650000 records inserted in 1.93 seconds
650000..700000 records inserted in 1.94 seconds
700000..750000 records inserted in 1.94 seconds
750000..800000 records inserted in 1.94 seconds
800000..850000 records inserted in 1.93 seconds
850000..900000 records inserted in 1.95 seconds
900000..950000 records inserted in 1.94 seconds
950000..1000000 records inserted in 1.94 seconds
1000000..1050000 records inserted in 1.95 seconds
1050000..1100000 records inserted in 1.95 seconds
1100000..1150000 records inserted in 1.95 seconds
1150000..1200000 records inserted in 1.95 seconds
1200000..1250000 records inserted in 1.96 seconds
1250000..1300000 records inserted in 1.98 seconds
1300000..1350000 records inserted in 1.95 seconds
1350000..1400000 records inserted in 1.95 seconds
1400000..1450000 records inserted in 1.95 seconds
1450000..1500000 records inserted in 1.95 seconds
1500000..1550000 records inserted in 1.95 seconds
1550000..1600000 records inserted in 1.95 seconds
1600000..1650000 records inserted in 1.95 seconds
1650000..1700000 records inserted in 1.96 seconds
1700000..1750000 records inserted in 1.95 seconds
1750000..1800000 records inserted in 1.95 seconds
1800000..1850000 records inserted in 1.94 seconds
1850000..1900000 records inserted in 1.95 seconds
1900000..1950000 records inserted in 1.95 seconds
1950000..2000000 records inserted in 1.95 seconds

Database file size: 89.2 MiB.

---

Databases: 1; Tables: 1; Indexes: 1 (md5)

0..50000 records inserted in 2.90 seconds
50000..100000 records inserted in 11.64 seconds
100000..150000 records inserted in 10.85 seconds
150000..200000 records inserted in 10.62 seconds
200000..250000 records inserted in 11.28 seconds
250000..300000 records inserted in 12.09 seconds
300000..350000 records inserted in 10.60 seconds
350000..400000 records inserted in 12.25 seconds
400000..450000 records inserted in 13.83 seconds
450000..500000 records inserted in 14.48 seconds
500000..550000 records inserted in 11.08 seconds
550000..600000 records inserted in 10.72 seconds
600000..650000 records inserted in 14.99 seconds
650000..700000 records inserted in 10.85 seconds
700000..750000 records inserted in 11.25 seconds
750000..800000 records inserted in 17.68 seconds
800000..850000 records inserted in 14.44 seconds
850000..900000 records inserted in 19.46 seconds
900000..950000 records inserted in 16.41 seconds
950000..1000000 records inserted in 22.41 seconds
1000000..1050000 records inserted in 24.68 seconds
1050000..1100000 records inserted in 28.12 seconds
1100000..1150000 records inserted in 26.85 seconds
1150000..1200000 records inserted in 28.57 seconds
1200000..1250000 records inserted in 29.17 seconds
1250000..1300000 records inserted in 36.99 seconds
1300000..1350000 records inserted in 30.66 seconds
1350000..1400000 records inserted in 32.06 seconds
1400000..1450000 records inserted in 33.14 seconds
1450000..1500000 records inserted in 47.74 seconds
1500000..1550000 records inserted in 34.51 seconds
1550000..1600000 records inserted in 39.16 seconds
1600000..1650000 records inserted in 37.69 seconds
1650000..1700000 records inserted in 37.82 seconds
1700000..1750000 records inserted in 41.43 seconds
1750000..1800000 records inserted in 49.58 seconds
1800000..1850000 records inserted in 44.08 seconds
1850000..1900000 records inserted in 57.17 seconds
1900000..1950000 records inserted in 50.04 seconds
1950000..2000000 records inserted in 42.15 seconds

Database file size: 181.1 MiB.

---

Databases: 1; Tables: 20 (one per 100,000 records); Indexes: 1 (md5)

0..50000 records inserted in 2.91 seconds
50000..100000 records inserted in 10.30 seconds
100000..150000 records inserted in 10.85 seconds
150000..200000 records inserted in 10.45 seconds
200000..250000 records inserted in 10.11 seconds
250000..300000 records inserted in 11.04 seconds
300000..350000 records inserted in 10.25 seconds
350000..400000 records inserted in 10.36 seconds
400000..450000 records inserted in 11.48 seconds
450000..500000 records inserted in 10.97 seconds
500000..550000 records inserted in 10.86 seconds
550000..600000 records inserted in 10.35 seconds
600000..650000 records inserted in 10.77 seconds
650000..700000 records inserted in 10.62 seconds
700000..750000 records inserted in 10.57 seconds
750000..800000 records inserted in 11.13 seconds
800000..850000 records inserted in 10.44 seconds
850000..900000 records inserted in 10.40 seconds
900000..950000 records inserted in 10.70 seconds
950000..1000000 records inserted in 10.53 seconds
1000000..1050000 records inserted in 10.98 seconds
1050000..1100000 records inserted in 11.56 seconds
1100000..1150000 records inserted in 10.66 seconds
1150000..1200000 records inserted in 10.38 seconds
1200000..1250000 records inserted in 10.24 seconds
1250000..1300000 records inserted in 10.80 seconds
1300000..1350000 records inserted in 10.85 seconds
1350000..1400000 records inserted in 10.46 seconds
1400000..1450000 records inserted in 10.25 seconds
1450000..1500000 records inserted in 10.98 seconds
1500000..1550000 records inserted in 10.15 seconds
1550000..1600000 records inserted in 11.81 seconds
1600000..1650000 records inserted in 10.80 seconds
1650000..1700000 records inserted in 11.06 seconds
1700000..1750000 records inserted in 10.24 seconds
1750000..1800000 records inserted in 10.57 seconds
1800000..1850000 records inserted in 11.54 seconds
1850000..1900000 records inserted in 10.80 seconds
1900000..1950000 records inserted in 11.07 seconds
1950000..2000000 records inserted in 13.27 seconds

Database file size: 180.1 MiB.

---

As you can see, the insert speed remains pretty much constant if you shard the data into several tables.

Coexecutor

I did end up sharding the data (into 4096 tables) with one table per file. I've read in several places that one table per database is a better approach with SQLite and in my initial benchmarking, before I discovered the above, it seemed that having the tables in one database was part of the problem. In the end, what I do is prepare 100k or so records in memory, then attach/detach the databases for writing as required. I didn't realise the overhead for attaching/detaching was pretty minor if you can do a few thousand writes for each. I will try your suggestion on the next iteration though! – Stuart

Also, 2M rows is not enough to see the drop in speed. You'll need to benchmark with at least 10M as shown in the graph above. Ultimately I'll be dealing with about a billion rows. – Stuart

@veryhungrymike: There are a couple of advantages of having 1 table per file, but it's also more impractical. The bottleneck is the indexes, and since they are tied to the tables I'm pretty confident you get pretty much the same improvement with one or several files, as long as you keep each individual table short. – Coexecutor

@veryhungrymike: Oh, as for the number of records, I'm aware that the more they are, the slower it gets (I just didn't had much time to wait hours for the benchmark to end). Anyway, each of the tests has 2 million rows and you can notice that the second test starts getting considerably slower at 800k rows while the third one remains consistent till the end. That should say something. – Coexecutor

Maybe I need to adjust the description because the whole point is how to maintain speed with many (i.e. millions) of records. It's a logging type of use case where data is constantly appended, but once there, never changes, so maintaining speed for 10s or 100s of millions of rows is the primary goal. – Stuart

@veryhungrymike: The description is pretty clear already, my answer is the one that may be lacking some additional clarifications. – Coexecutor

Answer 3

I suspect the Index's hash value collision causes the insert speed slow.

When we have many many rows in one table, and then the indexed column hash value collision will happen more frequently. It means Sqlite engine needs to calculate the hash value two times or three times, or maybe even four times, in order to get a different hash value.

So I guess this is the root cause of the SQLite insert slowness when the table has many rows.

This point could explain why using shards could avoid this problem. Who's a real expert in SQLite domain to confirm or deny my point here?

Monatomic

Answer 4

Unfortunately I'd say this is a limitation of large tables in SQLite. It's not designed to operate on large-scale or large-volume datasets. While I understand it may drastically increase project complexity, you're probably better off researching more sophisticated database solutions appropriate to your needs.

From everything you linked, it looks like table size to access speed is a direct tradeoff. Can't have both.

Contingency

The link you provided mentions database sizes on the order of terabytes, which is not the case here. The size of the database currently is around 500MB. In the long run, I plan to drop historical data when I reach 20-50GB. – Stuart

Please see the above benchmark which shows that indeed you can have a large table and fast inserts. What you can't have, however, is an index on that table. – Stuart

Answer 5

In my project, I couldn't shard the database, as it's indexed on different columns. To speed up the inserts, I've put the database during creation on /dev/shm (=linux ramdisk) and then copy it over to local disk. That obviously only works well for a write-once, read-many database.

Quechuan