Уникальность _id в осколке

Question

Я смотрю в sharding с использованием mongodb, и большинство, если оно довольно прямолинейно. У меня есть некоторый опыт с очертаниями в других базах данных, поэтому я не спрашиваю о самой концепции. Есть одна вещь, которую я смутил, и, похоже, в документации нет ничего подобного, так что здесь.

_id Необходимо быть уникальным в пределах осколка, независимо от ключа осколка?

Небольшой масштаб (одиночный осколок), похоже, подтверждает, что это так. Однако это похоже на менее звездный подход к осколкам, который меня смущает. Для меня было бы разумнее потребовать, чтобы shard-key + _id был уникальным (т. Е. Использовал составной ключ), или у вас будет непоследовательное поведение в зависимости от того, куда направляются ваши ключи-шрамы. В моей модели данных используются детерминированные ключи, а ключ осколка - неотъемлемая часть. Так что я думаю, что все сводится к тому, что я сделал что-то не так в моем малом тесте? Должен ли я хранить ключ осколка дважды, один раз в качестве поля ключа осколка и один раз в качестве части _id? Или есть специальный случай, когда я могу как-то объявить составной ключ, используя shard-key и _id?

Update

Для полноты, это тривиальный случай я тестирование, вставляя следующие два документа:

{"_id": 1, "shardkey": 1} 
{"_id": 1, "shardkey": 2} 

Сначала один, очевидно, проходит, второй один выходит из строя. Если бы у меня было два осколка, и ключи осколков были бы перенаправлены на разные осколки, я предполагаю, что оба они преуспели.

Я могу, очевидно, просто объединить осколочный ключ и идентификатор, чтобы создать поле для mongodb, поскольку это действительно тот ключ, который я использую, но это похоже на странный способ приблизиться к проблеме из архитектуры базы данных точка зрения.

Answer 1

_id должен быть уникальным, всегда, независимо от того, собирается ли коллекция или нет. Ключ осколка не обязательно должен быть уникальным. Он используется для разделения коллекции на куски, которые можно разделить на осколки, составляющие базу данных. Ключ осколка должен обеспечить достаточную детализацию для разделения документов в коллекции на куски. Очевидно, хорошая идея связать ключ осколка с тем, как вы запрашиваете данные, и использовать ключ осколка, который относится к полям, на которые вы запрашиваете. Таким образом, запросы, которые вы запускаете, будут легко перенаправлены на соответствующие осколки, чтобы удовлетворить запрос. Если ключ осколка не является достаточно избирательным, то для поиска правильных документов запрос нужно будет переходить к нескольким осколкам. Вы можете создать составной индекс на _id + shard-key и сделать его уникальным, если хотите.

Я понимаю, что это не полностью отвечает на вопрос. tbh Я изо всех сил пытаюсь понять, о чем вы спрашиваете. Возможно, если вы сможете опубликовать пример документов, которые вы храните, и запросы, которые вы запускаете, помогут.