Использование составного первичного ключа в коллекции с большим количеством обновлений
У меня есть коллекция примерно из 10 000 документов, и структура документов такая:
{
"_id" : NUUID("a23ad36e-b0ca-4fa2-9d36-163223f26142"),
"Field_1" : NUUID("451a4cd9-3dab-4b5d-b792-bb81f0950a75"),
"Field_2" : null,
"Field_3" : NUUID("31ab892f-99c1-4e33-959b-12d0a90a3d3d"),
"Field_4" : 1,
"Field_5" : "AAF12A0A4D18",
"Field_6" : ISODate("2018-05-30T22:40:05.389Z"),
"Field_7" : ISODate("2018-06-31T20:02:35.947Z"),
"Field_8" : NumberLong(9300)
}
Мое приложение обновляет документы в этой коллекции каждую секунду. Что лучше: использовать составной первичный ключ для этой коллекции или просто использовать обычный первичный ключ и вместо этого определить составной индекс?
Чтобы найти каждый объект для обновления, мне нужно найти конкретный объект на основе 4 параметров, если я использую составной первичный ключ, я думаю, что смогу найти эту запись быстрее, и мне не нужно определять составной индекс, потому что он будет _id и он будет проиндексирован автоматически. С другой стороны, эта коллекция растет и займет больше места на диске.
Растущая коллекция также вызывает беспокойство при использовании составного индекса, поэтому вам, возможно, придется подумать о создании индекса в фоновом режиме. См. docs.mongodb.com/manual/core/index-creation/…
Спасибо за ссылку. Но я думаю, что это касается автономной базы данных, я использую набор реплик.
Каковы ваши аргументы в пользу использования составного ключа?