Има ли някакви предимства от използването на персонализиран

Предимства с генерирането на ваш собствен _id s:

Можете да ги направите по-удобни за хората, като присвоите нарастващи числа:1 , 2 , 3 , ...
Или можете да ги направите по-удобни за хората, като използвате произволни низове:t3oSKd9q

(Това не заема твърде много място на екрана, може да бъде избрано от списък и потенциално може да бъде копирано ръчно, ако е необходимо. Все пак трябва да го направите достатъчно дълго, за да предотвратите тайни споразумения.)
Ако използвате произволно генерирани низове, те ще имат приблизително равномерно разпределение на шардинга, за разлика от стандартните mongo ObjectIds, които имат тенденция да групират записи, създадени приблизително по едно и също време, в един и същ шард. (Дали това е полезно или не наистина зависи от вашата стратегия за шардинг.)
Или може да искате да генерирате свой собствен персонализиран _id s, които ще групират свързани обекти в един шард, напр. по собственик, или географски регион, или комбинация. (Отново, дали това е желателно или не зависи от начина, по който възнамерявате да правите заявки за данните и/или колко бързо ги създавате и съхранявате. Можете също да направите това, като посочите shard ключ, вместо _id себе си. Вижте дискусията по-долу.)


 
 Предимства при използването на ObjectId s:
   
 ObjectIds са много добри в избягването на сблъсъци. Ако генерирате свой собствен _id s на случаен принцип или едновременно, тогава трябва сами да управлявате риска от сблъсък.
 
  
 ObjectIds съдържат времето за създаване в тях. Това може да бъде евтин и лесен начин да запазите датата на създаване на документ и да сортирате документите хронологично. (От друга страна, ако не искате да излагате/изтича датата на създаване на документ, тогава не трябва да излагате неговия ObjectId!)
 
 
 
 nanoid
 може да ви помогне да генерирате кратки произволни идентификатори. Те също така предоставят калкулатор
 което може да ви помогне да изберете добра дължина на идентификатора, в зависимост от това колко документи/идентификатори генерирате всеки час.
 
 Като алтернатива написах mongoose-generate-unique-key
 за генериране на много кратки произволни идентификатори (при условие, че използвате библиотеката mongoose).
 Стратегии за шардинг
 
 Няма да твърдя, че съм експерт по това как най-добре да се разделят данни, но ето някои ситуации, които може да вземем предвид:
   
 Астрономическа обсерватория или ускорител на частици обработва гигабайти данни в секунда. Когато бъде открито интересно събитие, те може да поискат да съхранят огромно количество данни само за няколко секунди. В този случай те вероятно искат равномерно разпределение на документите в сегментите, така че всеки сегмент да работи еднакво усилено за съхраняване на данните и нито един сегмент да не бъде претоварен.
 
  
 Имате огромно количество данни и понякога трябва да обработите всички веднага. В този случай (но в зависимост от алгоритъма) може отново да е желателно равномерно разпределение, така че всички фрагменти да могат да работят еднакво усилено върху обработката на своята част от данните, преди да комбинират резултатите в края. (Въпреки че в този сценарий може да сме в състояние да разчитаме на балансиращия инструмент на MongoDB, а не на нашия shard ключ, за равномерното разпределение. Балансиращият работи във фонов режим, след като данните бъдат съхранени. След като съберете много данни, може да се наложи да оставете го да преразпредели парчетата за една нощ.)
 
  
 Имате приложение за социални медии с голямо количество данни, но този път много различни потребители правят много леки заявки свързани главно с техните собствени данни или с техните конкретни приятели или теми. В този случай няма смисъл да се включва всеки шард всеки път, когато потребител направи малка заявка. Може да има смисъл да се разделя по userId (или по тема, или по географски регион), така че всички документи, принадлежащи на един потребител, да се съхраняват на един шард и когато този потребител направи заявка, само един шард трябва да върши работа. Това трябва да остави другите сегменти свободни да обработват заявки за други потребители, така че много потребители да могат да бъдат обслужвани наведнъж.
 
  
 Шардинг на документи по време на създаване (които ObjectIds по подразбиране ще ви дадат) може да е желателно, ако имате много леки заявки, разглеждащи данни за подобни периоди от време. Например много различни потребители, търсещи различни исторически диаграми.
 
 Но може да не е толкова желателно, ако повечето от вашите потребители търсят само най-новите документи (често срещана ситуация в социалните медийни платформи), защото това би означавало, че един или два шарда ще поемат по-голямата част от работата. Разпределянето по тема или може би по регион може да осигури по-плоско цялостно разпределение, като същевременно позволява свързаните документи да се събират заедно в един фрагмент.
 
 
 
 Може да искате да прочетете официалните документи по този въпрос:
   
 https://docs.mongodb.com/manual/sharding/#shard -key-strategy
 
 
  
 https://docs.mongodb.com/manual/ core/sharding-choose-a-shard-key/

Има ли някакви предимства от използването на персонализиран _id за документи в MongoDB?

Стратегии за шардинг