OK. thanks, Paul.
On Tue, Jul 28, 2020 at 2:52 PM Paul Davis <paul.joseph.da...@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 <sans...@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,
>
