Artikel blog ini telah diterbitkan ulang dengan izin saya oleh MongoDB di https. // www. mongodb. com/blog/post/generating-globally-unique-identifiers-for-use-with-mongodb Show Secara default, MongoDB menghasilkan pengenal ObjectID unik yang ditetapkan ke bidang _id dalam dokumen baru sebelum menulis dokumen itu ke database. Dalam banyak kasus, pengidentifikasi unik default yang ditetapkan oleh MongoDB akan memenuhi persyaratan aplikasi. Namun, dalam beberapa kasus, aplikasi mungkin perlu membuat pengidentifikasi unik khusus, seperti.
Karena sifat aplikasi modern yang multi-utas dan terdistribusi, tidak selalu merupakan tugas yang mudah untuk menghasilkan pengidentifikasi unik yang memenuhi persyaratan aplikasi RingkasanPosting ini mencakup topik-topik berikut
Semua pendekatan yang kami usulkan di sini menghasilkan pengidentifikasi yang unik secara global untuk semua tujuan praktis, namun tergantung pada pendekatan yang dipilih, mungkin ada kasus tepi jarak jauh di mana pengidentifikasi yang dihasilkan mungkin tidak benar-benar unik secara global Jika risiko benturan pengidentifikasi unik dianggap cukup jauh atau konsekuensi dari benturan semacam itu kecil, maka seseorang dapat mempertimbangkan untuk menulis ke database tanpa pemeriksaan keunikan tambahan. Ini adalah pendekatan yang valid yang kemungkinan akan diadopsi oleh banyak aplikasi Namun, jika sangat penting untuk memastikan bahwa pengidentifikasi yang dihasilkan unik secara global, kode dapat ditulis secara defensif untuk menjamin bahwa database tidak akan pernah menulis pengidentifikasi unik yang sama dua kali. Ini relatif mudah diterapkan pada koleksi non-sharded dengan menentukan indeks unik pada kolom tertentu, yang mencegah nilai duplikat untuk kolom tersebut agar tidak pernah ditulis ke koleksi. Perhatikan bahwa secara default kolom _id selalu mematuhi batasan indeks unik Jika penulisan gagal karena tabrakan pada bidang yang memiliki indeks unik, maka aplikasi harus menangkap kesalahan ini dan membuat pengidentifikasi unik baru dan mencoba menulis dokumen ke database lagi Jika koleksi dipecah, ada. Jika batasan untuk menggunakan indeks unik pada koleksi sharded tidak dapat dipenuhi, maka koleksi proxy dapat digunakan untuk menjamin keunikan sebelum menulis data ke database Gunakan ObjectID sebagai pengidentifikasi unikKeteranganDriver database MongoDB secara default menghasilkan pengidentifikasi ObjectID yang ditetapkan ke bidang _id dari setiap dokumen. Jika dokumen masuk ke database tanpa nilai _id, maka database itu sendiri akan menetapkan ObjectID ke bidang _id. Dalam banyak kasus, ObjectID dapat digunakan sebagai pengidentifikasi unik dalam aplikasi ObjectID adalah angka 96-bit yang disusun sebagai berikut
Manfaat
Kekurangan
PenafianPendekatan yang dijelaskan di bagian ini umumnya tidak disarankan karena potensi dokumen penghitung tunggal menjadi hambatan dalam aplikasi KeteranganPengidentifikasi unik mungkin diperlukan dalam urutan sekuensial yang meningkat secara monoton dan terus menerus, yang mirip dengan fungsionalitas urutan yang diimplementasikan oleh beberapa RDBMS. Ini dapat dicapai dengan menerapkan solusi yang didasarkan pada dokumen penghitung terpusat yang berada dalam kumpulan yang kami sebut uniqueIdentifierCounter. Dokumen penghitung terpusat ini adalah satu-satunya dokumen dalam koleksi uniqueIdentifierCounter, dan kolom COUNT-nya akan melacak nilai pengidentifikasi unik saat ini Setiap kali pengidentifikasi unik baru diperlukan, findAndModify akan digunakan pada dokumen penghitung untuk . Nilai COUNT kemudian dapat digunakan oleh aplikasi sebagai pengidentifikasi unik. Misalnya aplikasi dapat memberikan nilai COUNT ke bidang _id dari dokumen yang akan ditulis ke koleksi tertentu. Contoh implementasiDokumen penghitung untuk pembuatan pengidentifikasi unik dapat terlihat sebagai berikut {
"_id" : "UNIQUE COUNT DOCUMENT IDENTIFIER",
"COUNT" : 0,
"NOTES" : “Increment COUNT using findAndModify to ensure that the COUNT field will be incremented atomically with the fetch of this document",
}
Dan dokumen pembuatan pengenal unik dapat diminta dan ditambahkan secara atomik sebagai berikut. Perhatikan bahwa secara default dokumen yang dikembalikan dari findAndModify adalah dokumen pra-modifikasi db.uniqueIdentifierCounter.findAndModify({
query: { _id: "UNIQUE COUNT DOCUMENT IDENTIFIER" },
update: {
$inc: { COUNT: 1 },
},
writeConcern: 'majority'
})
_Manfaat
Kekurangan
KeteranganPendekatan ini mirip dengan pendekatan sebelumnya, dengan perbedaan bahwa alih-alih menambah nilai COUNT dengan 1, kami mungkin ingin menambahkannya dengan angka yang lebih besar yang akan mewakili kumpulan pengidentifikasi unik yang akan dialokasikan oleh database ke Misalnya, jika aplikasi mengetahui bahwa ia memerlukan 1000 pengidentifikasi unik baru, maka aplikasi akan menggunakan findAndModify() untuk secara atomis mendapatkan COUNT saat ini dan menambah nilai COUNT sebesar 1000. Dokumen yang dikembalikan dari perintah findAndModify akan berisi nilai awal untuk sekumpulan pengidentifikasi unik, dan aplikasi akan mengulang lebih dari 1000 nilai dari titik awal tersebut Perhatikan bahwa dengan pendekatan ini aplikasi dapat mengirimkan nilai apa pun yang diinginkannya untuk menambah nilai COUNT, dan oleh karena itu pendekatan ini dapat dibuat fleksibel. Untuk batch besar, kenaikan ini akan menjadi angka yang besar, dan untuk pengenal tunggal, ini akan disetel ke 1 Contoh implementasiBerikut ini menunjukkan perintah shell javascript yang secara atomik akan menambah COUNT sebanyak 1000 dan mengembalikan dokumen penghitung sebelumnya (sebelum kenaikan) var seq_increment = 1000;
db.uniqueIdentifierCounter.findAndModify({
query: { _id: "UNIQUE COUNT DOCUMENT IDENTIFIER" },
update: {
$inc: {COUNT: seq_increment },
}
writeConcern: 'majority'
})Manfaat
Kekurangan
KeteranganPendekatan ini mirip dengan pendekatan sebelumnya, tetapi alih-alih memiliki satu dokumen penghitung, kita dapat memiliki banyak dokumen penghitung yang disimpan dalam koleksi uniqueIdentifierCounter Misalnya, mungkin ada 1000 dokumen counter (bernomor 0 sampai 999) masing-masing bertanggung jawab untuk mengalokasikan 1 miliar nomor unik yang diambil dari rentang tertentu yang telah dialokasikan ke setiap counter. Dalam hal ini, penghitung 499 akan bertanggung jawab untuk mengalokasikan nilai dari 499000000000 ke 499999999999 Perhatikan bahwa contoh khusus ini menghasilkan angka unik mulai dari 0 hingga 999.999.999.999 yang merupakan angka 12 digit Contoh implementasiDi bawah ini kami menunjukkan format dan nilai awal yang ditetapkan ke dokumen penghitung di koleksi uniqueIdentifierCounter /* The following would be the initial state of the 0th counter document, which is responsible for the range of unique identifiers from 0 to 999,999,999 */
{
"_id" : "COUNTER DOCUMENT NUMBER 0",
"MAX_VALUE": 999999999,
"COUNT" : 0,
"NOTES" : "Increment COUNT using findAndModify to ensure that the COUNT field will be incremented atomically with the fetch of this document",
}
/* The following would be the initial state of 499th counter document, which is responsible for the range of unique identifiers from 499,000,000,000 to 499,999,999,999 */
{
"_id" : "COUNTER DOCUMENT NUMBER 499"),
"MAX_VALUE": 499999999999,
"COUNT" : 499000000000,
"NOTES" : "Increment COUNT using findAndModify to ensure that the COUNT field will be incremented atomically with the fetch of this document",
}
/* Etc… */
Dengan pendekatan ini, setiap kali aplikasi membutuhkan nomor unik baru atau rentang nomor unik, aplikasi akan secara acak menghasilkan angka antara 0 dan 999 yang akan digunakan untuk melakukan kueri terhadap atribut _id di koleksi uniqueIdentifierCounter. Ini akan memilih dokumen penghitung tertentu untuk mengambil pengidentifikasi unik Ini ditunjukkan dalam contoh berikut, di mana kami secara acak memilih salah satu dokumen penghitung, dan meminta kumpulan 100 nomor unik dari penghitung itu var which_counter_to_query = Math.floor((Math.random()*1000));
var seq_increment = 100;
db.Unique Identifier_counter.findAndModify({
query: { _id: "COUNTER DOCUMENT NUMBER " + which_counter_to_query},
update: {
$inc: {COUNT: seq_increment },
},
writeConcern: 'majority'
})_Manfaat
Kekurangan
KeteranganPendekatan ini bergantung pada fakta bahwa jika indeks unik didefinisikan dalam koleksi, bahwa setiap dokumen yang ditulis ke koleksi tersebut harus memiliki nilai unik yang ditetapkan ke bidang tersebut agar berhasil ditulis. Oleh karena itu, kami dapat secara acak membuat nomor pengidentifikasi unik dalam aplikasi, menetapkannya ke kolom unik dalam dokumen, dan mencoba menulis dokumen tersebut ke koleksi. Jika penulisan berhasil, maka kita tahu bahwa nilai yang kita berikan padanya unik. Jika penulisan gagal, maka aplikasi harus menangkap kegagalan tersebut dan secara acak membuat pengidentifikasi unik baru yang kemudian dapat digunakan untuk menulis dokumen ke koleksi. Jika jumlah tabrakan rendah, maka ini bisa menjadi cara yang efisien untuk menulis dokumen ke database dengan setiap dokumen memiliki pengidentifikasi unik yang dijamin Contoh implementasiJika kita tahu bahwa kita akan memiliki maksimal satu miliar catatan dalam basis data kita, agar memiliki kemungkinan rendah untuk memilih pengidentifikasi yang telah ditetapkan (alias tabrakan), kita dapat secara acak memilih angka antara 0 dan 999.999.999.999 ( . Untuk contoh ini, rentang yang kami gunakan untuk memilih nomor acak adalah 1000 kali lebih besar dari jumlah dokumen yang kami harapkan untuk ditulis ke koleksi ini, yang menghasilkan kasus terburuk yang diharapkan 0. 1% kemungkinan tabrakan Kami kemudian akan menetapkan nomor yang dibuat secara acak ke bidang yang memiliki indeks unik, dan menulis dokumen itu ke database. Jika penulisan berhasil, maka kita tahu bahwa pengidentifikasi itu unik. Jika penulisan gagal, maka aplikasi harus memilih pengenal lain secara acak dan mencoba lagi hingga penulisan berhasil. Perhatikan bahwa ada beberapa saat digunakan dalam cluster yang terfragmentasi. Jika batasan untuk menggunakan indeks unik pada koleksi sharded tidak dapat dipenuhi, maka koleksi proxy dapat digunakan untuk membantu menghasilkan indeks unik Manfaat
Kekurangan
KeteranganRFC 4122 menentukan standar untuk menghasilkan UUID 128-bit. RFC menentukan berbagai algoritme untuk membuat UUID, yang disebut versi UUID. Ada pustaka standar yang akan menghasilkan UUID 128-bit pada tingkat aplikasi. Spesifikasi BSON mendefinisikan UUID sebagai subtipe yang valid, dan dapat ditemukan di. http. //bsonspec. org/spesifikasi. html. Manfaat
Kekurangan
|
Apakah _id unik di mongodb?
Pos Terkait
Copyright © 2024 ketajaman Inc.
