Field name generated from embedded document. Am I crazy? - arrays

Question

What are the potential problems for the following design decision?
Suppose you have a MongoDB collection where, for each document, you want to store many documents in one of the embedded fields. Think about a kind of one-to-many relationship.
For different reasons, an array is to be avoided, meaning, the documents in the collection won't be like this
{
p: 1,
q: [
{ k1: 1, k2 : "p", x: "aaa" },
{ k1: 2, k2 : "b", x: "bbb" }
]
}
Instead, I choose to do the following
{
p: 1,
q: {
KEY1 : { k1: 1, k2 : "a", x: "aaa" },
KEY2 : { k1: 2, k2 : "b", x: "bbb" }
}
}
where KEY1 and KEY are unique strings representing the documents {k1: 1, k2 : "a" } and {k1: 2, k2 : "b"}, respectively.
Such string could be calculated in many ways, as far as the representation is unique. For example, {k1: 1, k2 : "a"} and {k2 : "a" , k1: 1} should have the same string, and should be different from the one of {k2 : "a" , k1: "1"}. It should take into account that the values for some ki could also be a document.
By the way, I cannot use a hash function for calculating KEY, as I need to store all the documents.
(If you are still here, the reason I didn't use an array is because I need atomicity when adding documents to the field q, and I need to modify the field x, although k1 and k2 will not be modified was added to q. This design was based on this question: MongoDB arrays - atomic update or push element. $addToSet only work for whole documents)
Two possible source of problems:
The numbers of possible KEY would grow fast. (Although in my case it should be under the thousands)
The keys themselves could be very long strings. Can it degrade the performance?
Technical view
About feasibility, the documentation of MongoDB only says fields cannot be _id and cannot include the characters $, . or null. The BSON spec only says it should be an Modified UTF-8 string, not including null.
I'd have done the following, but MongoDB complained the keys should be non mutable:
{
p: 1,
q: {
{ k1: 1, k2 : "a" } : { x: "aaa" },
{ k1: 2, k2 : "b" } : { x: "bbb" }
}
}
You can, however, use related similar notation with using the operator $group in the aggregation framework. Just similar notation: You cannot save such things into a collection.
This whole idea, it seems, would not be necessary if the documents {k1: 1, k2 : "a" } where to be store directly in the collection, meaning not embedded. In that case, I just would set k1 and k2 as a unique index, and then use update/upsert to insert without repetition. All this overkill is because that cannot in an Array. Indeed, it seem an array is almost like a collection, where the _id is the position in the array. If I'm not wrong in this paragraph, then what ever is representable in the top-level collection, should be representable in an embedded document.
EDIT: What about using a collection instead of embedding?
(Edited after comment by #hd)
My end goal is to have a one-to-many relationship with atomicity, especially while updating the many-side.
Lets explore the idea of having separate documents for representing the one-to-many relationship. It mean two collections:
Collection cOne
{
p: 1,
q: _id_in_Many
}
Collection cMany
{
id: ...,
p: 1,
q: { k1: 1, k2 : "p" },
x: "aaa",
}
In this case, I should use an unique index in cMany + updateOne/upsert to ensure uniqueness, {p: 1, q: 1}. But then indexes has a limit of 1024 bytes per entry, but {k1: ..., k2 : ...} could go beyond it, especially if the values contain utf-8 strings.
If I use anyway a KEY generated as explained, like this
{
id: ...,
p: 1,
key: KEY1,
k1 : 1,
k2 : "p" ,
x: "aaa",
}
Then the posibility of hitting the 1024 bytes limit persist for the index {p : 1, key: 1}. I got to say, I don't expect the {k1: ..., k2 : ...} to go far beyond 1k. I'm aware of the 16b limit per document.
Maybe there is a principled way to have collections unique on a field which values would let the index entries go over 1k, but I couldn't find it. The mongo documentation of upsert says "To avoid multiple upserts, ensure that the filter fields are uniquely indexed."
In contrast, it seems there is no official restriction on the length of the fields names, and field assignment should, as any other document update, unique.
EDIT 2: Are arrays and documents more powerful than Collections?
(Edited after comment by #hd)
Since I haven't found a way to add an arbitrary document to a Collection, preserving uniqueness, we could argue that Documents and Arrays are more powerful, uniqueness-wise, than Collections. Documents field names are unique, and Arrays at least support $addToSet, that would be enough if I only had the keys k1, k2 but not mutable x.