Нужен ли уникальный ключ MongoDB Shard?

Question

Я немного борюсь с этим, выйдя из среды SQL, где мы окопали идентификатор пользователя. У нас было несколько таблиц с добавленным пользователем user_id, так что мы могли бы обмануть. Если в одной таблице было 100 записей, все для одного и того же пользователя, все 100 попадают в один и тот же осколок.

Итак, у нас есть наша первая база данных mongo, что мы хотели бы иметь возможность очертить, если необходимо. Существует пользовательский коллектор, который мы намереваемся очертить _id. Нет проблем. Но есть вторая коллекция, в которой могут быть сотни документов для одного пользователя. Нам бы хотелось, чтобы они перешли на один и тот же осколок (не обязательно должны быть такими же, как и у пользовательского документа, поскольку они получаются отдельно, но они действительно извлекаются пользователем в кусках.) Но похоже, что если мы shard by user_id, который был добавлен ко второй коллекции, этого недостаточно, ключ осколка должен быть уникальным, поэтому каждый раз, когда мы выполняем поиск, мы будем пересекать все осколки. Это не оптимально. Итак, нужно ли быть полностью уникальным, как и в, только одна такая запись на коллекцию?

Документация указывает на то, что у нас есть проблема. Я надеюсь, что не понимаю.

Answer 1

Никакой ключ окантовки не обязательно должен быть уникальным (хотя это может быть). Например, следующий Sharding ключа {userID : 1, countryID : 1} абсолютно справедлив для коллекции, которая имеет поле (обратите внимание, что два элемента имеет тот же идентификатор пользователя и CountryId):

{userID : 4, countryID : 5}, 
{userID : 4, countryID : 9}, 
{userID : 1, countryID : 5}, 
{userID : 2, countryID : 3}, 
{userID : 4, countryID : 5}, 
{userID : 5, countryID : 4} 

Насколько я помню, Монго не позволяет создавать шардинг ключ только при отсутствии ключа (и там was a bug about it). А также после этого вы получите can not change значение ключа.

Но вы можете даже иметь одно и то же поле {a : 5} по всей коллекции и иметь его как осколки ключа (это было бы совершенно глупо, но вы можете это сделать).

Вы должны быть осторожны при выборе ключа, потому что это большой pain in the ass, чтобы изменить его после. Так что хорошая вещь слишком долго читается в течение некоторого времени. how to choose a sharding key.