Saya sangat tidak setuju dengan penulis jawaban yang dipilih bahwa Tidak ada id peningkatan otomatis di MongoDB dan ada alasan bagus . Kami tidak tahu alasan mengapa 10gen tidak mendorong penggunaan ID yang bertambah secara otomatis. Ini spekulasi. Saya pikir 10gen membuat pilihan ini karena lebih mudah untuk memastikan keunikan 12-byte ID di lingkungan cluster. Ini adalah solusi default yang cocok untuk sebagian besar pendatang baru sehingga meningkatkan adopsi produk yang bagus untuk bisnis 10gen.
Sekarang izinkan saya memberi tahu semua orang tentang pengalaman saya dengan ObjectIds di lingkungan komersial.
Saya sedang membangun jaringan sosial. Kami memiliki sekitar 6 juta pengguna dan setiap pengguna memiliki sekitar 20 teman.
Sekarang bayangkan kita memiliki koleksi yang menyimpan hubungan antara pengguna (yang mengikuti siapa). Ini terlihat seperti ini
_id : ObjectId
user_id : ObjectId
followee_id : ObjectId
di mana kami memiliki indeks komposit unik {user_id, followee_id} . Kami dapat memperkirakan ukuran indeks ini menjadi 12*2*6M*20 =2GB. Nah, itulah indeks untuk pencarian cepat orang yang saya ikuti. Untuk pencarian cepat orang yang mengikuti saya, saya memerlukan indeks terbalik. Itu 2 GB lagi.
Dan ini baru permulaan. Saya harus membawa ID ini kemana-mana. Kami memiliki kluster aktivitas tempat kami menyimpan Kabar Beranda Anda. Itu setiap acara yang Anda atau teman Anda lakukan. Bayangkan berapa banyak ruang yang dibutuhkan.
Dan akhirnya salah satu teknisi kami membuat keputusan yang tidak disadari dan memutuskan untuk menyimpan referensi sebagai string yang mewakili ObjectId yang menggandakan ukurannya.
Apa yang terjadi jika indeks tidak cocok dengan RAM? Tidak ada yang bagus, kata 10gen:
Ketika indeks terlalu besar untuk dimasukkan ke dalam RAM, MongoDB harus membaca indeks dari disk, yang merupakan operasi yang jauh lebih lambat daripada membaca dari RAM. Ingatlah bahwa indeks cocok dengan RAM ketika server Anda memiliki RAM yang tersedia untuk indeks yang digabungkan dengan rangkaian kerja lainnya.
Itu berarti membaca lambat. Pertentangan kunci meningkat. Menulis juga menjadi lebih lambat. Melihat pertarungan kunci dalam 80%-nish tidak lagi mengejutkan saya.
Sebelum Anda menyadarinya, Anda berakhir dengan cluster 460GB yang harus Anda pisahkan menjadi pecahan dan yang cukup sulit untuk dimanipulasi.
Facebook menggunakan 64-bit sepanjang id pengguna :) Ada alasan untuk itu. Anda dapat membuat ID berurutan
- menggunakan saran 10gen .
- menggunakan mysql sebagai penyimpanan penghitung (jika Anda khawatir tentang kecepatan, lihat handlersocket )
- menggunakan layanan pembuatan ID yang Anda buat atau menggunakan sesuatu seperti Snowflake oleh Twitter.
Jadi, inilah saran umum saya untuk semua orang. Tolong tolong buat data Anda sekecil mungkin. Saat Anda tumbuh, itu akan menghemat banyak malam tanpa tidur.
