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,

Reply via email to