On Tue, 16 Jun 2015 10:36:45 +0200
Marco Bonardo <mbonardo at mozilla.com> wrote:
> The contents of the page came out from actual bugs and misuses we hit
> in years of use and experience with it and were discussed with
> attention. Most also have workarounds or suggested fixes.
While I'm sure that's true, the page is filled with dubious
assertions.
Almost everything it says about I/O is evidence-free. The implications
of a file (or the database) using multiple extents on the disk
("fragmentation") is the best example. For an application like FF, how
much data, and how many seeks, are we really talking about? How many of
them are in name only, because the OS reads whole tracks and buffers
hundreds of megabytes in the page cache?
Is fsync "very expensive"? Not likely. Compared to network latency,
it's near zero. On many consumer hard disks, it *is* zero, because the
drive lies about completed writes.
Do small, simple writes perform better in JSON? If so, by how much?
What complexity then leaks back into the application to manage deletes
and index seeks, no to mention concurrency?
The page doesn't mention the value of constraints for correctness. It
doesn't mention the convenience to the developer of being able to
inspect and query the data outside the application.
Yes, sure, right tool for the job. In deciding, best to know what the
tool does, and what the job is.
--jkl
