Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of mark.deibert@gmail.com
 designates 209.85.128.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <D0BF25869D534E1EBA00B83F3EB7E34F@cloudant.com>
References: 
 <CAMGHjASjaVagGbvOGSJrPitoVVDN0qn7BxahT4y3t1XeRcHekg@mail.gmail.com>
	<527E548F.4020203@yandex.ru>
	<CABvT1DHMwHDAB4yc19h2z9avxfJOQ3Yp5FnQyBimULuGa5NJ_w@mail.gmail.com>
	<CAMGHjATWVSc4WyJ4N3g-roGkPKMxEF_DwmXieuy7qS3wugTYpA@mail.gmail.com>
	<CAK0S_BDsCRwUXBSUtjr-rBMXJuw_JcdhdTDLKUYckPj5+BC7XA@mail.gmail.com>
	<CABvT1DEnX0He=ZvYF5ucHcAJGphwso2vajS8jSd6fBLtzLA0Ag@mail.gmail.com>
	<1CD5C733-4854-407A-A8DF-8E29A1A0493B@couchbase.com>
	<CAMGHjARqtzUWujNn6EW-v1BAk=XYSp3_Ru8VNwgmeYb_M=m8Zw@mail.gmail.com>
	<CAKiq=tATz_ymdvX7mfGowM2xY82jniz1_-RjJ5Dj7gGKZP43AA@mail.gmail.com>
	<CAMGHjAT2GQYjmRp=ntDRAMZGGAFtRbKfUVW0zU+mCY6yh=BSjQ@mail.gmail.com>
	<CAMGHjAQ4qqu=eHm31L7T9fDN90Fiit3rjMGQOprF+7DsvN8rxw@mail.gmail.com>
	<CAL+Y1nt=RtTtCQ07_0OYHhbk9ESUhhDuShedHbgYcvZvHDj_Zw@mail.gmail.com>
	<CAMGHjAQWKtbrjDEWyrW3n1DiPAdCLsS8tWOdXV6-iJ5XbOAY1g@mail.gmail.com>
	<D0BF25869D534E1EBA00B83F3EB7E34F@cloudant.com>
Date: Mon, 11 Nov 2013 10:00:18 -0500
Message-ID: 
 <CAMGHjARDXkE2RwLQ9O=weg4CQRzY4bzpUin-u0gwxVJTnk0z2Q@mail.gmail.com>
Subject: Re: Storage limitations?
From: Mark Deibert <mark.deibert@gmail.com>
To: "user@couchdb.apache.org" <user@couchdb.apache.org>
Content-Type: multipart/alternative; boundary=089e013cbc8c82235004eae7fdff

--089e013cbc8c82235004eae7fdff
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

@Simon: Thanks for the advice. As I type, I don't anticipate any
aggregation on the Photo docs, but I should think about that some more.


On Mon, Nov 11, 2013 at 9:56 AM, Simon Metson <simon@cloudant.com> wrote:

> Hey,
> I=92d go with what you=92re doing (1:1 doc:photo).
>
> 2 seems a bit weird - do you mean host the app in a different server to
> the data or have different databases for different types of data (that
> might work, if you never want to query across types of data)? 3 might wor=
k
> so long as you never want to aggregate across the categories. 4 is a
> reasonable approach for very very large attachments, but you can get into
> consistency issues - what=92s the source of truth the database or the
> filesystem?
> Cheers
> Simon
>
>
> On Monday, 11 November 2013 at 14:41, Mark Deibert wrote:
>
> > A followup on the "1000's of images" question. I could approach this a
> > couple ways. Currently each image is attached to it's own Photo doc.
> Which
> > I've read is better for replication than one attachment with many
> > attachments. So that's fine, but will Couch have any issue managing
> several
> > thousand of these Photo docs, each with a 3MB'ish image attachment? If
> you
> > were building this Couchapp, would you...
> >
> > 1) Keep the photos as described above in one CouchDB
> > 2) Move the Photo docs with attachments out into a separate CouchDB
> > 3) Do 2, but break Photos into multiple categorized CouchDBs
> > 4) Upload the images to the filesystem, just store the link in Couch
> >
> > I want to build this Couchapp in such a way as to not make life miserab=
le
> > for CouchDB :-D
> >
> >
> >
> >
> > On Sun, Nov 10, 2013 at 6:33 PM, Dave Cottlehuber <dch@jsonified.com(ma=
ilto:
> dch@jsonified.com)> wrote:
> >
> > > On 10 November 2013 23:14, Mark Deibert <mark.deibert@gmail.com(mailt=
o:
> mark.deibert@gmail.com)> wrote:
> > > > I read an article somewhere that using include_docs is "hard" on
> memory
> > >
> > >
> > > or
> > > > disk or in some way taxes Couch and therefore you should just emit
> the
> > >
> > >
> > > doc.
> > > > Is this true?
> > >
> > >
> > >
> > > Like most general statements it has some truth and some lies in it :-=
)
> > >
> > > views and docs are stored in separate .couch btree files on disk.
> > >
> > > emit(key, doc) puts a full copy of the doc (that's already in the doc
> > > .couch b~tree) into the view b~tree.
> > >
> > > advantage - no need to hop over to the doc .couch file to retrieve th=
e
> > > document.
> > > disadvantage - you now have 2 copies of the doc in separate files,
> wasted
> > > space.
> > >
> > > If you do things right, and your app fits this model, the generated
> > > etags from views and docs can be cached in nginx or similar, and
> > > repeated queries don't need to hit your couch.
> > >
> > > So yes, include_docs means extra reads, but like most of these things
> > > you should benchmark your situation, under a realistic load, not just
> > > pumping 1000 single-doc reads at it.
> > >
> > > A+
> > > Dave
> >
>
>
>
>

--089e013cbc8c82235004eae7fdff--