couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garren Smith <gar...@apache.org>
Subject Re: Disable "index all" default capability with mango text indexes
Date Mon, 05 Dec 2016 06:04:14 GMT
Hi Tony,

Could we make this optional? So that a CouchDB admin can choose whether
they want this behavior disabled or enabled? Users running smaller clusters
with smaller db's would probably want this functionality.

Cheers
Garren

On Sat, Dec 3, 2016 at 10:31 PM, Joan Touzet <wohali@apache.org> wrote:

> What other possibilities are there?
>
> We could set a max recursion depth, perhaps.
>
> couchjs has a limit on max stack size; a recursion depth limit would be
> similar in spirit.
>
> If nothing else is possible I'm happy for this change as a last-ditch
> effort.
>
> -Joan
>
> ----- Original Message -----
> > From: "Tony Sun" <tony.sun427@gmail.com>
> > To: dev@couchdb.apache.org
> > Sent: Saturday, December 3, 2016 3:19:34 PM
> > Subject: Disable "index all" default capability with mango text indexes
> >
> > Hi all,
> >
> > In mango, once a user has correctly setup text search, he or she can
> > create
> > a simple text index with:
> >
> > {
> > "type" : "text"
> > "index" :{}
> > }
> >
> > This default basically indexes every field in a document for the
> > entire db.
> > Unfortunately, for large dbs, this is resource intensive. Even with
> > warnings, users tend to favor this default behavior because it allows
> > them
> > to quickly being querying the db.
> >
> > In rare instances, if users have nested complex arrays, then
> > thousands of
> > unique field names are generate and could lead to JVM heap
> > exhaustion.
> > We've seen in production that this scenario can disable a cluster.
> >
> > I've entertained the idea of disabling this default behavior. The
> > biggest
> > concern is of course that existing application apis which depend on
> > this
> > default behavior will be affected. I'll think about various solutions
> > to
> > mitigate the impact, but I wanted to throw this out there to see if
> > people
> > are in agreement that we should do this.
> >
> > Thanks,
> >
> > Tony
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message