couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From San Sato <sans...@inator.biz>
Subject Re: object keys in couchdb 4
Date Wed, 29 Jul 2020 16:21:43 GMT
OK.  thanks, Paul.

On Tue, Jul 28, 2020 at 2:52 PM Paul Davis <paul.joseph.davis@gmail.com>
wrote:

> San,
>
> I don't remember that being a performance issue under consideration
> for the "exploded document" design that we had contemplated in
> particular, but I could see there being some concerns around it.
> However, we have not implemented that idea and instead just store
> documents in as few consecutive keys as possible so in terms of fdb,
> the doc bodies are just a string of bytes so its definitely a
> non-issue with the current design.
>
> Paul
>
> On Tue, Jul 28, 2020 at 4:15 PM San Sato <sansato@inator.biz> wrote:
> >
> > During the design process with FDB integration, there was talk about
> issues
> > with nesting keys having user-provided values, the gist of which was, as
> I
> > recall, was that having many documents *{ _id: "xyz", o: ...}* with *o*'s
> > value being a nested object with runtime-generated, non-predictable keys
> *{x1,
> > x2, y1, y2, y3, m1...mX, n, ...}* harms FDB performance; that FDB
> keyspace
> > prefers, operationally, to be relatively static (maybe this had something
> > to do with joined paths-to-value, and limiting the number of distincts in
> > the flattened namespace for the keys?).
> >
> > Is that still the case?
> >
> > Thanks,
>

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