Satu hal yang terlintas dalam pikiran di sini adalah Anda mungkin tidak perlu melakukan semua pekerjaan yang menurut Anda perlu, dan masalah Anda mungkin dapat diselesaikan dengan sedikit bantuan dari Indeks TTL dan mungkin koleksi yang dibatasi . Pertimbangkan entri berikut:
{ "_id" : ObjectId("531cf5f3ba53b9dd07756bb7"), "user" : "A", "units" : 50 }
{ "_id" : ObjectId("531cf622ba53b9dd07756bb9"), "user" : "B", "units" : 62 }
Jadi ada dua entri dan Anda mendapatkan _id nilai kembali saat Anda memasukkan. Jadi pada awalnya, "A" tidak memiliki siapa pun untuk dilawan, tetapi entri untuk "B" akan bermain melawan yang sebelumnya.
ObejctId adalah monotonic , yang berarti bahwa yang "berikutnya" akan selalu lebih besar nilainya dari yang terakhir. Jadi dengan data yang dimasukkan, lakukan saja ini:
db.moves.find({
_id: {$lt: ObjectId("531cf622ba53b9dd07756bb9") },
user: { $ne: "B" }
}).limit(1)
Itu memberikan "langkah" yang disisipkan sebelumnya ke gerakan saat ini yang baru saja dibuat, dan melakukan ini karena apa pun yang sebelumnya dimasukkan akan memiliki _id dengan nilai lebih kecil daripada item saat ini. Anda juga memastikan bahwa Anda tidak "bermain" melawan gerakan pengguna itu sendiri, dan tentu saja Anda membatasi hasilnya pada satu dokumen saja.
Jadi "bergerak" akan selamanya bergerak maju, Ketika penyisipan berikutnya dilakukan oleh pengguna "C" mereka mendapatkan "bergerak" dari pengguna "B", dan kemudian pengguna "A" akan mendapatkan "bergerak" dari pengguna "C ", dan seterusnya.
Semua yang "bisa" terjadi di sini adalah bahwa "B" membuat berikutnya "pindah" secara berurutan, dan Anda akan mengambil dokumen yang sama seperti pada permintaan terakhir. Tapi itu adalah poin untuk Anda desain "sesi", untuk menyimpan "hasil" terakhir dan memastikan bahwa Anda tidak mendapatkan hal yang sama kembali, dan karena itu, tangani hal itu bagaimanapun Anda ingin dalam desain Anda.
Itu seharusnya cukup untuk "bermain". Tapi mari kita lakukan "penghapusan . Anda " bagian.
Secara alami Anda "berpikir" Anda ingin menghapus sesuatu, tetapi kembali ke "pembantu" awal saya ini tidak perlu. Dari atas, penghapusan hanya menjadi faktor "pembersihan", sehingga koleksi Anda tidak bertambah banyak.
Jika Anda menerapkan indeks TTL, dengan cara yang sama seperti tutorial ini menjelaskan, entri koleksi Anda akan dibersihkan untuk Anda, dan dihapus setelah jangka waktu tertentu.
Juga apa yang bisa dilakukan, dan terutama mengingat bahwa kita menggunakan meningkatkan sifat _id key dan ini kurang lebih merupakan "antrian", Anda mungkin dapat menerapkan ini sebagai koleksi yang dibatasi
. Jadi Anda dapat mengatur ukuran maksimum untuk berapa banyak "gerakan" yang akan pertahankan pada waktu tertentu.
Menggabungkan keduanya bersama-sama, Anda mendapatkan sesuatu yang hanya "tumbuh" ke ukuran tertentu, dan akan dibersihkan secara otomatis untuk Anda, jika aktivitas sedikit melambat. Dan itu akan membuat semua operasi cepat .
Intinya adalah bahwa konkurensi "menghapus " yang Anda khawatirkan telah dihapus dengan benar-benar "menghapus" kebutuhan untuk menghapus dokumen yang baru saja diputar. Kueri membuatnya tetap sederhana, dan indeks TTL serta koleksi yang dibatasi menjaga pengelolaan data Anda untuk Anda.
Jadi begitulah pendapat saya tentang game "Blind War" yang sangat bersamaan.
