Beberapa strategi muncul dalam pikiran:
1) Gunakan koleksi/database yang berbeda untuk dokumen 'panas'.
Jika Anda tahu dokumen mana yang ada di hot set, ya, memindahkannya ke koleksi terpisah akan membantu. Ini akan memastikan bahwa hot document berada bersama pada luasan/halaman yang sama. Itu juga akan membuat indeks untuk dokumen-dokumen itu lebih mungkin untuk sepenuhnya berada di memori. Ini karena ukurannya lebih kecil dan (sepenuhnya?) lebih sering digunakan.
Jika dokumen panas dicampur secara acak dengan dokumen lain maka Anda mungkin harus kesalahan lebih banyak elemen daun indeks B-Tree saat memuat dokumen karena kemungkinan dokumen lain baru saja memuat atau mengakses blok indeks kecil.
2) Persingkat nilai . yang diindeks .
Semakin pendek nilai indeks, semakin banyak nilai yang masuk ke dalam satu blok B-Tree. (Catatan:Kunci tidak termasuk dalam indeks.) Semakin banyak entri dalam satu ember berarti lebih sedikit ember dan lebih sedikit memori total yang dibutuhkan untuk indeks. Itu berarti probabilitas yang lebih tinggi / masa pakai yang lebih lama yang memblokir akan tetap berada di memori. Dalam contoh Anda, pengurangan karakter 20->8 lebih baik dari penghematan 50%. Jika Anda dapat mengonversi 8 byte tersebut menjadi long, ada sedikit penghematan karena long tidak memiliki awalan panjang (4 byte) dan nol di belakangnya (total 5 byte).
3) Persingkat nama kunci.
Semakin pendek nama bidang, semakin sedikit ruang yang dibutuhkan setiap dokumen. Ini memiliki efek samping yang tidak menguntungkan dari penurunan keterbacaan.
4) Pecahan
Ini benar-benar satu-satunya cara untuk menjaga kinerja dalam menghadapi pembacaan di seluruh corpus yang menghabiskan memori dan akhirnya bandwidth disk. Jika Anda melakukan shard, Anda tetap ingin melakukan shard pada koleksi 'panas'.
5) Sesuaikan read-ahead pada disk ke nilai kecil.
Karena pembacaan 'non-panas' memuat dokumen acak dari disk, kami benar-benar hanya ingin membaca/merusak ke dalam memori dokumen itu dan sesedikit mungkin dokumen di sekitarnya. Sebagian besar sistem akan mencoba dan membaca lebih dulu blok data yang besar setelah pengguna membaca dari sebagian file. Ini justru kebalikan dari apa yang kami inginkan.
Jika Anda melihat sistem Anda banyak mengalami kesalahan tetapi memori tetap untuk proses mongod tidak mendekati memori sistem yang tersedia, Anda mungkin melihat efek OS membaca data yang tidak berguna.
6) Cobalah untuk menggunakan nilai yang meningkat secara monoton untuk kunci.
Ini akan memicu pengoptimalan (untuk indeks berbasis ObjectId) yang ketika blok indeks terbelah akan melakukannya pada 90/10 alih-alih 50/50. Hasilnya adalah sebagian besar blok dalam indeks Anda akan mendekati kapasitas dan Anda akan membutuhkannya lebih sedikit.
Jika Anda hanya mengetahui 50.000 dokumen 'panas' setelah fakta, menambahkannya ke koleksi terpisah dalam urutan indeks juga akan memicu pengoptimalan ini.
Rob.
