Пользовательский MongoDB Object _id vs Compound index

Question

Так что мне нужно создать коллекцию поиска в MongoDB для проверки уникальности. Требование состоит в том, чтобы проверить, повторяются ли те же 2 значения или нет. В SQL я бы что-то вроде этого

SELECT count(id) WHERE key1 = 'value1' AND key2 = 'value2' 

Если приведенный выше запрос возвращает счет, значит, комбинация не уникальна. У меня есть 2 решения, но я не уверен, какой из них более масштабируемым. Есть 30M + docs, против которых мне нужно создать это сопоставление.

Solution1:

создать коллекцию документации с индексом соединения на ключом1 и key2

{ 
    _id: <MongoID>, 
    key1: <value1>, 
    key2: <value2> 
} 

Solution2:

Я пишу логику приложения для создания пользовательской _ID конкатенации значение1 и значение2

{ 
    _id: <value1>_<value2> 
} 

Лично я чувствую, что второй оптимизирован, поскольку он имеет только один индекс, а размер документа также меньше. Но я не уверен, что это хорошая практика для создания моих собственных индексов _id, поскольку они не могут быть полностью случайными. Как вы думаете?

Заранее спасибо.

Update:

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

Answer 1

Я хотел бы предложить раствор 1 т.е. использовать индекс соединения и использовать два различных свойства key1 и key2

db.yourCollection.ensureIndex({ "key1": 1, "key2": 1 }, { unique: true }) 

1. Вы можете найти легко отдельного поля, если это необходимо. т. е. если вам требуется искать только ключ1 или key2, то это будет легко с составным индексом. Если вы сделаете _id с комбинацией клавиш, тогда будет сложно выполнить поиск по отдельному полю.
2. Размер документа в Монго наименее обеспокоен при разработке документа.
3. Если в ближайшем будущем, если вам потребуется изменить значения ключей одного и того же документа по отношению к другим значениям, это будет легко. Имейте в виду, если вы используете ссылку на этот документ в документе другой коллекции.
4. С точки зрения вашей масштабируемости, индекс _id будет последовательным, легко масштабируемым, и вы можете позволить MongoDB управлять им.
5. Если вы ищете с этими ключами, то он будет использовать этот индекс, иначе он будет использовать другие необходимые индексы для вашего поиска.

Если вы все еще думаете о размер документа, чем поиск, то вы можете пойти с раствором 1, сделать _id как

{_id:{key1:<value1>,key2:<value2>}} 

По этому вы можете найти конкретный _id.key1 тоже.

Update:

Да, если размер документа ваша забота, чем сохранение. И если вы уверены в том, что ключи не изменятся в будущем того же документа, и если он все еще изменит и не будет иметь ссылку в других коллекциях, вы можете использовать решение 1. Просто используйте ключи как объекты, кроме подчеркивания _. Вы можете добавить еще несколько ключей позже, если захотите в будущем.

Answer 2

Я думаю, что решение 2 больше подходит для вашего требования. Абсолютно нормально генерировать _id значение MongoDB. Большинство приложений заполняют значение _id с помощью UUID. В вашем случае имеет смысл объединить значения 1 и 2 для значения _id, предполагая, что эта коллекция в основном используется для проверки уникальности (например, временной таблицы) или цели поиска.

Решение 1 дорого, так как для его использования требуется дополнительный индекс. Опять же, это зависит от того, собираетесь ли вы использовать эту коллекцию для проверки цели единственности в одиночку или для какого-либо другого варианта использования.

Обратите внимание, что вам нужно создать уникальный составной индекс, чтобы он не позволял вставлять данные для повторяющихся значений.