Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An unscientific benchmark of SQLite vs. the file system (btrfs)

github.com

Post reply on HN
Print view View original

61–68 of 68 posts

Re: An unscientific benchmark of SQLite vs. the file system (btrfs)

#61

Post by ehvatum »

heinrich5991 wrote: post #57
ehvatum wrote: post #54

Earlier quoted context omitted.

> Would take about the same time as integrating SQLite into a system for the same purpose and would be easily extendable to support features as the system grows. I find it much easier to add features to my post-2007 projects (when I started using SQLite) for the specific reason that I can open the SQLite file in a GUI and pretty quickly see what’s going on with data organization (schema) and how the customer uses the…

What's the UI you use for viewing SQLite files?

At client site to debug issues and deal with things like bulk product name changes https://sqlitebrowser.org/

For more involved work that I do at my shop or on my laptop, DataGrip by Jet Brains is great. Before I got fed up with Apple, I used https://menial.co.uk/base/

DataGrip’s benefit to me is mainly reworking a customer DB at the ER diagram level, then I manually update my code to match.

Re: An unscientific benchmark of SQLite vs. the file system (btrfs)

#62

Post by cafxx »

prussian wrote: post #52
cafxx wrote: post #49

Earlier quoted context omitted.

I am not aware of implicit fsyncs. Can you please link to what you are referring to?

Probably in reference to Ext4's[0] configurable rename-replace behavior under auto_da_alloc [0]: https://www.kernel.org/doc/Documentation/filesystems/ext4.tx... Edit: note this isn't a universal property either, so it's still wrong: https://btrfs.wiki.kernel.org/index.php/FAQ#What_are_the_cra...

Yeah considering that the test is on btrfs, I would really be interested in knowing what OP is referring to.

Also, even if we were on ext4, it's worth pointing out that the ext4 documentation refers to apps that rely on that behavior as "broken applications", so it's hardly a good term of comparison.

Re: An unscientific benchmark of SQLite vs. the file system (btrfs)

#63

Post by ehvatum »

heinrich5991 wrote: post #57
ehvatum wrote: post #54

Earlier quoted context omitted.

> Would take about the same time as integrating SQLite into a system for the same purpose and would be easily extendable to support features as the system grows. I find it much easier to add features to my post-2007 projects (when I started using SQLite) for the specific reason that I can open the SQLite file in a GUI and pretty quickly see what’s going on with data organization (schema) and how the customer uses the…

What's the UI you use for viewing SQLite files?

By the way, SQLite started out as a TCL extension. It works really well in TCL and good old TCL/TK/SQLite gets CRUD done fast. I almost feel bad looking so heroic.

Re: An unscientific benchmark of SQLite vs. the file system (btrfs)

#64

Post by nyanpasu64 »

lamontcg wrote: post #50
christophilus wrote: post #9

Earlier quoted context omitted.

Yeah. I mentioned that in the final test where I write to a temporary file, then rename. This is much slower, probably due to an implicit fsync.

There's some 10-year old webpage that used to be popular on HN that goes into data integrity issues and fsync and filesystem databases that someone should dig up so you can read.

https://danluu.com/file-consistency/, https://stackoverflow.com/a/41362774

Re: An unscientific benchmark of SQLite vs. the file system (btrfs)

#66

Post by lamontcg »

nyanpasu64 wrote: post #64
lamontcg wrote: post #50

Earlier quoted context omitted.

There's some 10-year old webpage that used to be popular on HN that goes into data integrity issues and fsync and filesystem databases that someone should dig up so you can read.

https://danluu.com/file-consistency/ , https://stackoverflow.com/a/41362774

Yes that's the one.

And damn near every application is "broken" according to the ext4 documentation.

Post reply on HN