You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Hank Knight <hk...@gmail.com> on 2014/01/19 23:11:00 UTC
CouchDB: Are large design documents OK?
I would like to use CouchDB to power a large website containing
hundreds of pages. The pages will be dynamically created from
thousands of documents. Some pages will be powered by List Functions
and the other pages will be created by Show functions.
There are many advantages of using a single design document to power
ALL of the pages. For example, I could access could access common
JavaScript modules / functions and I could manage common areas such as
the header and footer from a single place.
Are there any drawbacks to storing all pages inside a singe design document?
Re: CouchDB: Are large design documents OK?
Posted by Dave Cottlehuber <dc...@jsonified.com>.
Hi Hank,
Sounds exciting! TL;DR try it via benchmark.
My gut feel says that overall performance and cost (storage, cpu time
etc) are likely to trump any pure couchdb related concerns. So I'd
seriously benchmark this, nothing makes for better advice than a real
test scenario to back it up done on real world hardware. Some
considerations;
Every update you need to make represents another version of that ddoc.
That will trigger a view group rebuild for any code changes (show/list
etc) over the whole db. This is probably one of the most common
reasons for splitting up ddocs (and databases).
A static site with nginx or <preferred_server> will always beat a
dynamic CouchDB setup. Using nginx to cache content that hasn't
changed is a good compromise. There's apache and nginx examples on the
wiki that leverages couchdb etag support, but is that fast enough for
the hardware & infrastructure you budgeted?
If you're simply talking about having a lot of attachments in that
ddoc (couchapp style) then is this for end-user convenience or
developer convenience? Updating a single .css file and then needing to
re-push an entire 100MB+ ddoc doesn't seem effective to me. I'd ask
whether you can achieve the same outcome using some pre-processing
tool (grunt, whatever) to keep what appears to be developer
convenience, and use the results from the benchmarking to decide
whether your end-user experience is going to be appropriate &
cost-effective instead. If your ddoc + attachments is GB in size, I'd
be worried, but 100MBs should not be a constraint.
http://docs.couchdb.org/en/latest/config/http.html?highlight=secure_rewrites#httpd/secure_rewrites
may give you the developer flexibility to share some of the web
components across websites & ddocs without needing to have to
duplicate all the code -- you can put all the core files into a single
ddoc hosted in a common db that can be accessed from a single origin.
Finally, there are a lot of other factors that may influence your
choices, security, backups & version control being the big ones.
On 20 January 2014 13:46, Hank Knight <hk...@gmail.com> wrote:
> Thanks, but I am looking for a direct answer. Could extremely large
> design documents cause performance problems?
>
> On Sun, Jan 19, 2014 at 7:20 PM, Andy Wenk <an...@nms.de> wrote:
>> On 19 January 2014 23:11, Hank Knight <hk...@gmail.com> wrote:
>>
>>> I would like to use CouchDB to power a large website containing
>>> hundreds of pages. The pages will be dynamically created from
>>> thousands of documents. Some pages will be powered by List Functions
>>> and the other pages will be created by Show functions.
>>>
>>> There are many advantages of using a single design document to power
>>> ALL of the pages. For example, I could access could access common
>>> JavaScript modules / functions and I could manage common areas such as
>>> the header and footer from a single place.
>>>
>>> Are there any drawbacks to storing all pages inside a singe design
>>> document?
>>>
>>
>> not answering your question directly, but this sounds like you want to
>> check out these frameworks for doing the job:
>>
>> http://couchapp.org/page/index
>> https://github.com/benoitc/erica
>> http://kan.so/
>>
>> Cheers
>>
>> Andy
>>
>> --
>> Andy Wenk
>> Hamburg - Germany
>> RockIt!
>>
>> http://www.couchdb-buch.de
>> http://www.pg-praxisbuch.de
>>
>> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
>>
>> https://people.apache.org/keys/committer/andywenk.asc
Re: CouchDB: Are large design documents OK?
Posted by Hank Knight <hk...@gmail.com>.
Thanks, but I am looking for a direct answer. Could extremely large
design documents cause performance problems?
On Sun, Jan 19, 2014 at 7:20 PM, Andy Wenk <an...@nms.de> wrote:
> On 19 January 2014 23:11, Hank Knight <hk...@gmail.com> wrote:
>
>> I would like to use CouchDB to power a large website containing
>> hundreds of pages. The pages will be dynamically created from
>> thousands of documents. Some pages will be powered by List Functions
>> and the other pages will be created by Show functions.
>>
>> There are many advantages of using a single design document to power
>> ALL of the pages. For example, I could access could access common
>> JavaScript modules / functions and I could manage common areas such as
>> the header and footer from a single place.
>>
>> Are there any drawbacks to storing all pages inside a singe design
>> document?
>>
>
> not answering your question directly, but this sounds like you want to
> check out these frameworks for doing the job:
>
> http://couchapp.org/page/index
> https://github.com/benoitc/erica
> http://kan.so/
>
> Cheers
>
> Andy
>
> --
> Andy Wenk
> Hamburg - Germany
> RockIt!
>
> http://www.couchdb-buch.de
> http://www.pg-praxisbuch.de
>
> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
>
> https://people.apache.org/keys/committer/andywenk.asc
Re: CouchDB: Are large design documents OK?
Posted by Andy Wenk <an...@nms.de>.
On 19 January 2014 23:11, Hank Knight <hk...@gmail.com> wrote:
> I would like to use CouchDB to power a large website containing
> hundreds of pages. The pages will be dynamically created from
> thousands of documents. Some pages will be powered by List Functions
> and the other pages will be created by Show functions.
>
> There are many advantages of using a single design document to power
> ALL of the pages. For example, I could access could access common
> JavaScript modules / functions and I could manage common areas such as
> the header and footer from a single place.
>
> Are there any drawbacks to storing all pages inside a singe design
> document?
>
not answering your question directly, but this sounds like you want to
check out these frameworks for doing the job:
http://couchapp.org/page/index
https://github.com/benoitc/erica
http://kan.so/
Cheers
Andy
--
Andy Wenk
Hamburg - Germany
RockIt!
http://www.couchdb-buch.de
http://www.pg-praxisbuch.de
GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
https://people.apache.org/keys/committer/andywenk.asc