object keys in couchdb 4

[San Sato <sa...@inator.biz>]

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,

Re: object keys in couchdb 4

[San Sato <sa...@inator.biz>]

OK.  thanks, Paul.

On Tue, Jul 28, 2020 at 2:52 PM Paul Davis <pa...@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 <sa...@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,
>

Re: object keys in couchdb 4

[Paul Davis <pa...@gmail.com>]

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 <sa...@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,