You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Mahesh Paolini-Subramanya <ma...@aptela.com> on 2008/11/11 18:03:23 UTC
Any opinions on an NFS data store?
Assuming just one CouchDB server, would having the data store be NFS
based even work?
What about multiple servers? I can definitely see chaos emerging from
multiple servers building View indexes simultaneously, but what if
read-access was done with 'update=false'?
What about writes with multiple servers?
Just wondering if there are any *immediate* gotchas that I should be
aware of (e.g., NFS - Just Say No :-) )
cheers
---
Mahesh Paolini-Subramanya
CTO, Aptela Inc.
(703.386.1500 x9100)
http://www.aptela.com
Re: Any opinions on an NFS data store?
Posted by Ayende Rahien <ay...@ayende.com>.
Probably a bad idea, a lot of NFS implementation would not respect flush()
in the same way that a disk would.caching at the local level is also going
to cause a whole lot of problem.
On Tue, Nov 11, 2008 at 7:03 PM, Mahesh Paolini-Subramanya <
mahesh@aptela.com> wrote:
> Assuming just one CouchDB server, would having the data store be NFS based
> even work?
> What about multiple servers? I can definitely see chaos emerging from
> multiple servers building View indexes simultaneously, but what if
> read-access was done with 'update=false'?
> What about writes with multiple servers?
>
> Just wondering if there are any *immediate* gotchas that I should be aware
> of (e.g., NFS - Just Say No :-) )
>
> cheers
> ---
> Mahesh Paolini-Subramanya
> CTO, Aptela Inc.
> (703.386.1500 x9100)
> http://www.aptela.com
>
>
Re: Any opinions on an NFS data store?
Posted by Chris Anderson <jc...@apache.org>.
On Tue, Nov 11, 2008 at 1:04 PM, Mahesh Paolini-Subramanya
<ma...@aptela.com> wrote:
> Well, it just so happens that we have a (wicked) fast NFS server in-house,
> which has the added benefit of being fault-tolerant, reliable, redundant
> (and clearly fully buzz-word compliant).
> The way I look at it, I'd *love* to use it for this purpose, and if flush()
> is pretty much the only constraint, I doubt that I have an issue.
> Clearly, however, the 'update=false' (or stale='ok', or whatever) will be a
> much bigger problem.
As long as you only point one couchdb instance at those files, you
should be fine. Couch can handle a lot of read load before you'll
start to wish you could split it across hardware...
And, I'm not certain that having more than one writer on the couch
files would kill it right away. It just seems like it might be asking
for trouble.
> That said, any particular reason that we dont want to have a Read-Only view?
Currently, just implementation details. I don't know if there are
deeper reasons.
Chris
--
Chris Anderson
http://jchris.mfdz.com
Re: Any opinions on an NFS data store?
Posted by Mahesh Paolini-Subramanya <ma...@aptela.com>.
Well, it just so happens that we have a (wicked) fast NFS server in-
house, which has the added benefit of being fault-tolerant, reliable,
redundant (and clearly fully buzz-word compliant).
The way I look at it, I'd *love* to use it for this purpose, and if
flush() is pretty much the only constraint, I doubt that I have an
issue.
Clearly, however, the 'update=false' (or stale='ok', or whatever) will
be a much bigger problem.
That said, any particular reason that we dont want to have a Read-Only
view?
I know that in our particular case (processing vast quantities of
CDRs), i really don't care about the data/indexes being up to date -
heck accuracy to the nearest hour will do too :-)
cheers
---
Mahesh Paolini-Subramanya
CTO, Aptela Inc.
(703.386.1500 x9100)
http://www.aptela.com
On Nov 11, 2008, at 12:26 PM, ara.t.howard wrote:
>
> On Nov 11, 2008, at 10:03 AM, Mahesh Paolini-Subramanya wrote:
>
>> Assuming just one CouchDB server, would having the data store be NFS
>> based even work?
>> What about multiple servers? I can definitely see chaos emerging
>> from multiple servers building View indexes simultaneously, but what
>> if read-access was done with 'update=false'?
>> What about writes with multiple servers?
>>
>> Just wondering if there are any *immediate* gotchas that I should be
>> aware of (e.g., NFS - Just Say No :-) )
>
> it depends *greatly* on what your NFS sever is. i've run linux-ha
> machines with stonith serving postgresql on top of NFS and it was more
> robust and faster that local disk. how is that you ask? huge ram/
> cache and batter backed ram - thus any call to 'flush()' is
> effectively a noop and therefore blindingly fast *and* robust. we
> failed over manually every monday and did so for over 3 years in a
> 24x7 situation with zero hitches. this was a 250k netapp however.
> if your NFS box is just a linux box w/o special hardware i'd be
> nervous.
>
> cheers.
>
> a @ http://codeforpeople.com/
> --
> we can deny everything, except that we have the possibility of being
> better. simply reflect on that.
> h.h. the 14th dalai lama
>
>
>
Re: Any opinions on an NFS data store?
Posted by "ara.t.howard" <ar...@gmail.com>.
On Nov 11, 2008, at 10:03 AM, Mahesh Paolini-Subramanya wrote:
> Assuming just one CouchDB server, would having the data store be NFS
> based even work?
> What about multiple servers? I can definitely see chaos emerging
> from multiple servers building View indexes simultaneously, but what
> if read-access was done with 'update=false'?
> What about writes with multiple servers?
>
> Just wondering if there are any *immediate* gotchas that I should be
> aware of (e.g., NFS - Just Say No :-) )
it depends *greatly* on what your NFS sever is. i've run linux-ha
machines with stonith serving postgresql on top of NFS and it was more
robust and faster that local disk. how is that you ask? huge ram/
cache and batter backed ram - thus any call to 'flush()' is
effectively a noop and therefore blindingly fast *and* robust. we
failed over manually every monday and did so for over 3 years in a
24x7 situation with zero hitches. this was a 250k netapp however.
if your NFS box is just a linux box w/o special hardware i'd be nervous.
cheers.
a @ http://codeforpeople.com/
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama
Re: Any opinions on an NFS data store?
Posted by Chris Anderson <jc...@apache.org>.
On Tue, Nov 11, 2008 at 9:03 AM, Mahesh Paolini-Subramanya
<ma...@aptela.com> wrote:
> Assuming just one CouchDB server, would having the data store be NFS based
> even work?
> What about multiple servers? I can definitely see chaos emerging from
> multiple servers building View indexes simultaneously, but what if
> read-access was done with 'update=false'?
I'd say, you'd probably have a slow experience. Also note that there
is no guarantee that update=false will be read-only. We're considering
calling it something like stale=ok, to better capture the guarantees
it (doesn't) make.
--
Chris Anderson
http://jchris.mfdz.com