On Wed, Jan 30, 2019 at 10:48 PM ermouth <ermo...@gmail.com> wrote: > > As I don't see the 10k limitation as having significant merit > > Not sure it’s relevant here, but Mango indexes put selected doc values into > keys. >
It kind of is, putting the values at the end of the keys is a viable strategy. It means those values must be kept to fit along with their path into the 10k limit as well. To clarify that "insignificant merit" comment: (1) If docs are stored as arrays of blobs, then a 10k key to reference that blob would be an inconceivable choice on our part. The goal would be <= 32 bytes where the FDB folks has said there's a clear performance gain. (2) If the docs are stored as pieces to be assembled (whether that's in individual kvps or document sections) with the nested key in the doc directly used as part of the FDB key; then having a use case where a 10k JSON Path is a requirement seems an "insignificant risk". Even in those cases where such a contrived document exists, it seems to me that requiring the application find a way to make the required path shorter is exceedingly reasonable. and (3) If a more advanced/sophisticated approach is taken where Couch is controlling the make up of the keys, then again, designing a system where the system must support keys larger than 10k simply seems inconceivable. I can't imagine any use cases where key lengths larger than 10k make up any meaningful segment of applications for Couch. At 10k in length, there is bound to be some kind of path segmentation to reasonably reduce the key length at the application layer instead of the Couch layer. Mike
