Live data from Hacker News

35% Faster Than The Filesystem (2017)

sqlite.org

141–150 of 166 posts

Re: 35% Faster Than The Filesystem (2017)

#141

I remember a job interview where the take home project was to parse a log file and search/sort by various top attributes as fast as possible. I thought about writing something from scratch, but I knew that whatever I could optimize in an hour or two would be nothing compared to more robust tools that already existed. So I used sqlite to ingest the log once, and query it in various ways to produce the requested report…

The interviewer didn't like the answer because it didn't answer the implicit question, which is how well you can write your own software. We know that you can load a table into SQLite and have it do the heavy lifting for you. But we're often not looking for software _users_ as much as we're looking for _engineers_. When we interview people, the answers we want often aren't real-world answers because we're trying to g…

You deserve the programmers you're looking for.

Re: 35% Faster Than The Filesystem (2017)

#143
post #25

Wonder what the number is with "noatime"? Every open is a write on a normal filesystem, but you can turn it off.

The default (relatime) is to update atime only once every 24h, so it's negligible for many workloads.

Or more importantly atime is updated in tandem with mtime.

Re: 35% Faster Than The Filesystem (2017)

#144

As someone who has spent time consulting for different kinds of "we do stuff on the internet" companies, I can confidently say that this is a premature optimization for 99.999% of the companies/projects. The companies simply don't have enough IO traffic to need it. Is it cool? Sure. Is it sexy? Maybe. Is it needed ? Nope. Do boring stuff. Use files. If you send your small files over the internet via web and you need…

While I agree with the sentiment, using the unix file API is wrought with peril if you try to do it properly.

https://www.usenix.org/system/files/conference/osdi14/osdi14...

sqlite does a good job to provide expected consistency even in the face of power loss. Half overwritten files or causal ordering violations can occur if you do not call fsync at the appropriate places.

Re: 35% Faster Than The Filesystem (2017)

#145

Earlier quoted context omitted.

The interviewer didn't like the answer because it didn't answer the implicit question, which is how well you can write your own software. We know that you can load a table into SQLite and have it do the heavy lifting for you. But we're often not looking for software _users_ as much as we're looking for _engineers_. When we interview people, the answers we want often aren't real-world answers because we're trying to g…

You deserve the programmers you're looking for.

God damn but is that a true statement.

Re: 35% Faster Than The Filesystem (2017)

#146

Earlier quoted context omitted.

> But we're often not looking for software _users_ as much as we're looking for _engineers_. What the applicant illustrated is that he is a much better engineer than the interviewer and the interviewer did not like it. Good software engineering is about leveraging existing robust tools in a new way, not about re-inventing a wheel while making is square. For me that would have been an insta-hire.

I disagree. Applicant should have done more to understand the requirements for the task. That’s a massive part of software engineering, and you would be surprised how much time software engineers will spend solving the wrong problem . He didn’t understand that part of the problem included rolling a novel solution or restricted use of a database. Almost a daily problem for software engineers is extracting this informa…

Some people do enjoy reinventing a wheel and making it square. And lots of managers enjoy having those who work for them to do it. It makes the managers feel smart.

The applicant solved a problem that was presented to him. If the person who interviewed him did not want him to do it that way, he or she would have specified it.

Re: 35% Faster Than The Filesystem (2017)

#147
post #113

stat to get filesize is a pathlogically bad pattern on Windows. If I remove the call to fileSize() in kvtest and instead replace it with 16k (since the max size in the post is 12k), I can significantly improve the time measured on Windows 10. Before: C:\temp>kvtest run test1.dir --count 100k --blob-api --count 100000 --max-id 1000 --asc Total elapsed time: 9.495 Microseconds per BLOB read: 94.950 Content read rate: 1…

Thanks for this. I did not realize that fileSize() was a performance issue on Windows. I'll attempt to update kvtest.c to deal with that, rerun the tests, and update the page, as I have opportunity.

Also, that test program for the above arguments just loops through the first 1000 files 100 times. (iMax is 1000). Would be good to point that out a bit more clearly if it's intentional. Curious to know why if it is.

Re: 35% Faster Than The Filesystem (2017)

#148
post #132

Earlier quoted context omitted.

Strong consistency is not what you think then. You can only do stale reads from backups.

I thought ahachete meant that a database backup is atomic, i e. it will only contain fully completed transactions. The problem with data split across databases then is that transactions don't span multiple databases, so you can't get an atomic snapshot of data spanning multiple databases. Are you saying that even a single-database backup is not atomic?

No, it's atomic. It's just not important if separate databases are not atomic to each other when you recover from backups, you will still have data loss and an inconsistent state. I.e. things that should be in the database missing, and that shouldn't be overwriting missing IDs, etc. Backups cannot be strongly consistent, so you have to take the exact same approaches to deal with this whether you store everything in a single database or in two separate ones.

Re: 35% Faster Than The Filesystem (2017)

#149
post #118
post #94

Slightly off the topic. In one of web applications (CRM alike) I was experimenting with SQLite-per-user approach. In that application user related data was clustered on per-user basis. So instead of single-db-for-all-users I had one-db-per-user. Performance gain was significant - around 25% for most of requests. I suspect that this is due the fact that index trees were significantly shorter for each particular user,…

This is exactly the topic that made me read this thread. I have been wondering whether one sqlite file per customer was a good option for an online service where each customer needed only his own, private data but wanted to work on it from his desktop, laptop, or phone, with the option of occasionally downloading the file for additional backup. I just don't know enough about multi-tenant database approaches to know i…

SQLite in the browser...

https://en.wikipedia.org/wiki/Web_SQL_Database

It was killed though. Derp.

Re: 35% Faster Than The Filesystem (2017)

#150

Earlier quoted context omitted.

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).

> 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. My thought process is that the current solution works so I'd only change to a K/V store with the extra complexity if that got me a better API and more of the stack in Rust. Consuming something in Go seems like a pain, while also adding a GC runtime just for this. > BTW I've heard very…

I wonder how a Rust library deals with the fact that sqlite is loosely typed.
Post reply on HN