MongoDB and ZFS

1,299 views
Skip to first unread message

bundacia

unread,
Mar 29, 2011, 3:29:20 PM3/29/11
to mongodb-user
Hi,
My company is going to start using MongoDB for a new project. We
currently use MySQL for our primary database and store the datafiles
on a zfs filesystem. My question is, would zfs be a good choice for
MongoDB as well? I'm wondering how performance is affected since, as I
understand it, zfs writes everything to disk immediately while mongo
is intentionally only fsync-ing every 60 seconds. Will zfs slow things
down?

If we do use zfs, does that mean we don't need to run MongoDB with the
--journal flag turned on?

Thanks in advance for your help.

Trevor

Mathias Stearn

unread,
Mar 29, 2011, 6:56:38 PM3/29/11
to mongod...@googlegroups.com, bundacia
On Tue, Mar 29, 2011 at 3:29 PM, bundacia <trevo...@gmail.com> wrote:
> Hi,
>    My company is going to start using MongoDB for a new project. We
> currently use MySQL for our primary database and store the datafiles
> on a zfs filesystem.
> My question is, would zfs be a good choice for
> MongoDB as well?

It is probably the best choice on solaris, but you would probably be
better off on XFS/ext4 on linux.

> I'm wondering how performance is affected since, as I
> understand it, zfs writes everything to disk immediately while mongo
> is intentionally only fsync-ing every 60 seconds.

I don't think it is actually flushing after every write. Especially
since it isn't really possible with mmap.

> Will zfs slow things down?

We've heard reports of slowdowns due to it's copy-on-write behavior
leading to objects being out-of-order on disk and needing more
seeking. To some extent, MongoDB's performance (both read and write)
relies on in-place updating.

That said, there may be ways to disable COW on ZFS since most
databases expect in-place updates. However I am not enough of an
expert in ZFS to know how to do this. You may already have it set up
that way for MySQL.

> If we do use zfs, does that mean we don't need to run MongoDB with the
> --journal flag turned on?

No, you still need --journal if you want durability.

> Thanks in advance for your help.
>
> Trevor
>

> --
> You received this message because you are subscribed to the Google Groups "mongodb-user" group.
> To post to this group, send email to mongod...@googlegroups.com.
> To unsubscribe from this group, send email to mongodb-user...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.
>
>

bundacia

unread,
Mar 30, 2011, 3:29:01 PM3/30/11
to mongodb-user
Thanks for the reply. That's really helpful. If we don't deploy on zfs
we'll have to do backups a different way. I've looked into LVM but
that seems to employ copy-on-write once a snapshot exists (possibly
less efficiently than zfs). What's the best way to handle backups of
large datasets on ext4 or xfs?

Trevor

On Mar 29, 6:56 pm, Mathias Stearn <math...@10gen.com> wrote:

Brad

unread,
Apr 3, 2011, 12:08:14 PM4/3/11
to mongodb-user
Trevor,
With ZFS, asynchronous writes are not written immediately to disk.
Synchronous
writes to zfs need to be written "somewhere" before returning to the
caller. But ZFS supports
the use of hybrid storage pools, so if performance is a concern you
can devote an
SSD device to function as your transaction log, allowing you to get
very fast response
times. With a configuration option you can adjust the synchronous
nature of the writes for
the pool at a global level.

Whether it's a good choice versus other options really depends on your
performance and
reliability requirements. If you want to eliminate RAID5 write holes,
ensure data is always
consistent on disk with no silent data corruption, then ZFS may be a
good option for you.
Reply all
Reply to author
Forward
0 new messages