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,
