Kerugian kinerja menggunakan siput sebagai kunci utama/_id di mongo?

Menurut saya, tidak. Perbedaan kinerja akan diabaikan untuk sebagian besar skenario (kecuali paging ), tapi

• Diskusi lama tentang kunci primer pengganti muncul. Sebuah "siput" bukanlah kunci yang sangat alami. Ya, itu pasti unik, tetapi seperti yang sudah Anda tunjukkan, mengubah slug seharusnya tidak mustahil. Ini saja akan membuat saya tidak mengganggu...
• Memiliki _id yang monoton key dapat menyelamatkan Anda dari sejumlah sakit kepala, yang paling penting untuk menghindari paging yang mahal melalui skip dan take (gunakan $lt /$gt pada _id sebagai gantinya).
• Ada batasan pada panjang indeks maksimum di mongodb kurang dari dari 1024 byte. Meskipun tidak cantik, URL diperbolehkan menjadi lebih lama . Jika seseorang memasukkan slug yang lebih panjang, slug tidak akan ditemukan karena secara diam-diam dihapus dari indeks.
• Adalah ide yang baik untuk memiliki antarmuka yang konsisten, yaitu menggunakan jenis _id yang sama pada semua, atau setidaknya, sebagian besar objek Anda. Dalam kode saya, saya memiliki satu pengecualian di mana saya menggunakan hash khusus sebagai id karena nilainya tidak dapat berubah, koleksi memiliki kecepatan tulis yang sangat tinggi dan besar.
• Misalnya Anda ingin menautkan ke artikel di antarmuka manajemen Anda (bukan situs publik), tautan mana yang akan Anda gunakan? Biasanya id, tetapi sekarang id dan slug setara. Sekarang bug sederhana (seperti mengizinkan slug kosong) akan sulit untuk dipulihkan, karena pengguna bahkan tidak dapat membuka antarmuka manajemen lagi.
• Anda akan berurusan dengan masalah rangkaian karakter. Saya menyarankan untuk tidak menggunakan slug untuk mencari artikel, tetapi hash slug .

Pada dasarnya, Anda akan mendapatkan skema seperti

{ "_id" : ObjectId("a237b45..."), // PK
  "slug" : "mongodb-is-fun", // not indexed
  "hash" : "5af87c62da34" } // indexed, unique