Re: changing database backend
Pablo Sanchez <[email protected]>
| Newsgroups | gmane.comp.kde.users.pim |
|---|---|
| Organization | Blueoak Database Engineering Inc |
| Message-ID | <[email protected]> |
[ Comments below, in-line ] On 11/12/2014 10:40 AM, René J.V. Bertin wrote: > On Wednesday November 12 2014 09:54:20 Pablo Sanchez wrote: > > Hi Hi René > with a 300Gb harddisk that isn't likely to be the bottleneck; If you don't believe your HDD is the source of your bottleneck, then why change the backend DB and talk about disabling the database's logging facility? In my experience though, you'll find an instant performance boost moving to an SSD. You'll of course become CPU bound but that's /generally/ a good problem to have. > an SSD upgrade for that kind of machine is just not reasonable). I bought a 500+ GB SSD for my old laptop. The SSD is worth more than the laptop. :) I plan on re-using the SSD on a subsequent laptop/rig. > Yes, I've seen that. It's something akin to COW, and with ZFS's own > COW plus the copies=2 I'm running with that would just be too much > redundancy. It's not quite as simple as you're stating: "too much redundancy." An ACID compliant DBMS moves from one consistent state to the next. It uses its logging/journal facility for this. The logging facility is synchronous. That is, the caller will not be allowed to continue until the data is persisted to disk. If we instruct the DBMS to use non-synchronous and/or buffered writes, then while it may believe its data is secure on disk, it may not be. What this means is in the event of data loss to its journal (which is used during crash-recovery), the DBMS will not be able to bring the database back to a consistent state. This means you're only recourse is to recover the database from either the last full back up or the last full backup plus any logs. The above gets more complicated when you have multiple connections to the database, each with complicated transactions. Again, if you're willing to tolerate the potential of some data loss and/or an inconsistent database (you'll have to re-create your entire environment), then disable the DB's logging facility. If in fact you're I/O bound, I'd suggest instead getting the SSD and know you'll eventually re-use it on your next computer. :) >> >In order for the DBMS to conform to ACID [1], you can't disable >> >logging. :) > > But logging is independent of double-write, right? No, it's not. > Thanks for the links. You're welcome. -- Pablo Sanchez - Blueoak Database Engineering, Inc Ph: 819.459.1926 Blog: http://pablo-blog.blueoakdb.com iNum: 883.5100.0990.1054 _______________________________________________ KDE PIM users mailing list Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users