One question that has come up a number of times when I've been
speaking with people (read: evangelizing :) ) about ZFS is about
database storage. In conventional use storage has separated redo logs
from table space, on a spindle basis.
I'm not a database expert but I believe the reasons boil down to a
combination of:
- Separation for redundancy
- Separation for reduction of bottlenecks (most write ops touch both
the logs and the table)
- Separation of usage patterns (logs are mostly sequential writes,
tables are random).
The question then comes up about whether in a ZFS world this
separation is still needed. It seems to me that each of the above
reasons is to some extent ameliorated by ZFS:
- Redundancy is performed at the filesystem level, probably on all
disks in the pool.
- Dynamic striping and copy-on-write mean that all write ops can be
striped across vdevs and the log writes can go right next to the
table writes
- Copy-on-write also turns almost all writes into sequential writes
anyway.
So it seems that the old reasoning may no longer apply. Is my
thinking correct here? Have I missed something? Do we have any
information to support either the use of a single pool or of separate
pools for database usage?
Boyd
Melbourne, Australia
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
