Apakah ada keuntungan menggunakan _id khusus untuk dokumen di MongoDB?

Keuntungan dengan membuat _id Anda sendiri s:

Anda dapat membuatnya lebih ramah manusia, dengan menetapkan angka yang bertambah:1 , 2 , 3 , ...
Atau Anda dapat membuatnya lebih ramah manusia, menggunakan string acak:t3oSKd9q

(Itu tidak memakan terlalu banyak ruang di layar, dapat diambil dari daftar, dan berpotensi disalin secara manual jika diperlukan. Namun Anda perlu membuatnya cukup lama untuk mencegah kolusi.)
Jika Anda menggunakan string yang dibuat secara acak, mereka akan memiliki distribusi sharding yang kira-kira merata, tidak seperti ObjectIds mongo standar, yang cenderung mengelompokkan catatan yang dibuat sekitar waktu yang sama ke dalam shard yang sama. (Apakah itu membantu atau tidak tergantung pada strategi sharding Anda.)
Atau Anda mungkin ingin membuat _id khusus Anda sendiri s yang akan mengelompokkan objek terkait ke dalam satu pecahan, mis. oleh pemilik, atau wilayah geografis, atau kombinasi. (Sekali lagi, apakah itu diinginkan atau tidak tergantung pada bagaimana Anda ingin menanyakan data, dan/atau seberapa cepat Anda memproduksi dan menyimpannya. Anda juga dapat melakukan ini dengan menentukan kunci shard, daripada _id diri. Lihat pembahasan di bawah ini.)

Keuntungan menggunakan ObjectId s:

ObjectIds sangat baik dalam menghindari tabrakan. Jika Anda membuat _id Anda sendiri s secara acak atau bersamaan, maka Anda perlu mengelola sendiri risiko tabrakan.
ObjectIds berisi waktu pembuatannya di dalamnya. Itu bisa menjadi cara yang murah dan mudah untuk mempertahankan tanggal pembuatan dokumen, dan untuk menyortir dokumen secara kronologis. (Di sisi lain, jika Anda tidak ingin mengekspos/membocorkan tanggal pembuatan dokumen, maka Anda tidak boleh mengekspos ObjectId-nya!)

nanoid modul dapat membantu Anda menghasilkan id acak pendek. Mereka juga menyediakan kalkulator yang dapat membantu Anda memilih panjang id yang baik, tergantung pada berapa banyak dokumen/id yang Anda hasilkan setiap jam.

Atau, saya menulis mongoose-generate-unique-key untuk menghasilkan sangat id acak pendek (asalkan Anda menggunakan perpustakaan luwak).

Strategi pembagian

Saya tidak akan mengklaim sebagai ahli tentang cara terbaik untuk memisahkan data, tetapi berikut adalah beberapa situasi yang dapat kami pertimbangkan:

Sebuah observatorium astronomi atau akselerator partikel menangani gigabyte data per detik. Saat peristiwa menarik terdeteksi, mereka mungkin ingin menyimpan data dalam jumlah besar hanya dalam beberapa detik. Dalam hal ini, mereka mungkin menginginkan distribusi dokumen yang merata di seluruh pecahan, sehingga setiap pecahan akan bekerja sama kerasnya untuk menyimpan data, dan tidak ada pecahan yang kewalahan.
Anda memiliki sejumlah besar data dan terkadang Anda perlu memproses semuanya sekaligus. Dalam hal ini (tetapi tergantung pada algoritmenya), distribusi yang merata mungkin lagi diinginkan, sehingga semua shard dapat bekerja sama kerasnya dalam memproses potongan data mereka, sebelum menggabungkan hasilnya di akhir. (Meskipun dalam skenario ini, kami mungkin dapat mengandalkan penyeimbang MongoDB, daripada kunci shard kami, untuk distribusi yang merata. Penyeimbang berjalan di latar belakang setelah data disimpan. Setelah mengumpulkan banyak data, Anda mungkin perlu biarkan untuk mendistribusikan kembali potongan semalaman.)
Anda memiliki aplikasi media sosial dengan sejumlah besar data, tetapi kali ini banyak pengguna yang berbeda membuat banyak kueri ringan terkait terutama dengan data mereka sendiri, atau teman atau topik khusus mereka. Dalam hal ini, tidak masuk akal untuk melibatkan setiap pecahan setiap kali pengguna membuat sedikit permintaan. Mungkin masuk akal untuk melakukan shard berdasarkan userId (atau berdasarkan topik atau wilayah geografis) sehingga semua dokumen milik satu pengguna akan disimpan di satu shard, dan ketika pengguna tersebut membuat kueri, hanya satu shard yang perlu bekerja. Ini akan membuat pecahan lain bebas memproses kueri untuk pengguna lain, sehingga banyak pengguna dapat dilayani sekaligus.
Membagi dokumen menurut waktu pembuatan (yang akan diberikan ObjectIds default kepada Anda) mungkin diinginkan jika Anda memiliki banyak kueri ringan yang melihat data untuk periode waktu yang sama. Misalnya banyak pengguna yang berbeda menanyakan grafik historis yang berbeda.

Tetapi mungkin tidak begitu diinginkan jika sebagian besar pengguna Anda hanya menanyakan dokumen terbaru (situasi umum di platform media sosial) karena itu berarti satu atau dua pecahan akan mendapatkan sebagian besar pekerjaan. Mendistribusikan berdasarkan topik atau mungkin berdasarkan wilayah dapat memberikan distribusi keseluruhan yang lebih datar, sementara juga memungkinkan dokumen terkait untuk berkumpul di satu pecahan.

Anda mungkin ingin membaca dokumen resmi tentang hal ini: