Learning a few things about running SQLite

▲ Learning a few things about running SQLite(jvns.ca)

65 points by surprisetalk 2 hours ago | 10 comments

▲ striking an hour ago | parent | next [-]

> Maybe one day I’ll learn to read a query plan.

With SQLite's `.expert` mode you can delay that day a little longer: https://www.sqlite.org/cli.html#index_recommendations_sqlite...

  sqlite> CREATE TABLE x1(a, b, c);                  -- Create table in database 
  sqlite> .expert
  sqlite> SELECT * FROM x1 WHERE a=? AND b>?;        -- Analyze this SELECT 
  CREATE INDEX x1_idx_000123a7 ON x1(a, b);

  0|0|0|SEARCH TABLE x1 USING INDEX x1_idx_000123a7 (a=? AND b>?)

  sqlite> CREATE INDEX x1ab ON x1(a, b);             -- Create the recommended index 
  sqlite> .expert
  sqlite> SELECT * FROM x1 WHERE a=? AND b>?;        -- Re-analyze the same SELECT 
  (no new indexes)

  0|0|0|SEARCH TABLE x1 USING INDEX x1ab (a=? AND b>?)

Also wrt

> My approach so far has been to just do these cleanup operations in small batches so that I don’t need to do database queries that take more than 5 seconds to run. This whole experience has given me more of an appreciation for why someone might want to use a “real” database like Postgres which can have more than one writer at the same time though.

The advice for those " “real” " databases is generally to also do cleanup operations in small batches, they just tend to make it less obvious you're doing something unperformant in the smaller case. You're more right than you thought!

▲

simonw 25 minutes ago | parent | next [-]

I've worked with large MySQL databases that used row-based replication and things like an UPDATE or DELETE that affected millions of rows had to be applied in batches there, because otherwise one SQL query might result in a million updated rows needing to be sent to all of the replicas at once.

	▲	cogman10 17 minutes ago \| parent [-]
		Yeah, I think anyone that's done significant database work has come to the understanding that large updates need to be done in batches, otherwise you nuke performance. Once you get to about 1M rows of data, batching is essential.

▲

DANmode 29 minutes ago | parent | prev [-]

> they just tend to make it less obvious you're doing something unperformant

Is this being positioned as a strength, in your comment?

▲ simonw an hour ago | parent | prev | next [-]

> I’ve been backing up to AWS, which is always a pain because it’s annoying to navigate the AWS console to generate credentials.

I got so annoyed with that a few years ago that I ended up building a whole tool just to solve that one problem:

  uvx s3-credentials create my-existing-s3-bucket

This spits out read-write credentials that are scoped JUST for that bucket. You can add --read-only or --write-only to have credentials that are further locked down, or even add --prefix foo/bar for credentials that can only read/write keys that start with that prefix within the bucket.

> Maybe one day I’ll move away to some other S3-compatible alternative.

I've used Restic with Cloudflare R2 and it worked great.

▲ andrewaylett 5 minutes ago | parent | prev | next [-]

I run my backups like this:

    OUT="${i}.sql.zst"
    PART="${OUT}.part"
    sqlite3 -readonly "${i}" .dump | zstd --fast --rsyncable -v -o "${PART}" -
    mv "${PART}" "${OUT}"

That doesn't block writers (when the writer uses WAL), and gives me a dump that's compressed well while also being easy to sync. My Home Assistant DB is 1.8GB, my dump is 286MB compressed, and I'd guess 90% of that is consistent from one day to the next.

▲ masklinn 26 minutes ago | parent | prev | next [-]

> and presumably other things?

Various statistical views over the value distributions of the indexes, so that the planner can estimate how useful (selective) the index should be.

sqlite_stat1 just gives an average (number of records in the index, and average number of records per value), and if enabled sqlite_stat4 stores histogram data.

▲ ryan42 20 minutes ago | parent | prev | next [-]

If you're not using them, adding in silk and/or debug toolbar to your django app will be able to get some good automatic reporting and guidance on performance issues.

▲ m0ose 23 minutes ago | parent | prev | next [-]

What does he mean by "I do usually try to monitor them with a dead man’s switch.", when talking about backups?

▲ datadrivenangel an hour ago | parent | prev [-]

"Maybe one day I’ll learn to read a query plan."

Query plans aren't that hard to read! [0]

0 - https://xkcd.com/2501/