Faktor Operasional yang Perlu Dipertimbangkan Selama Pemodelan Data MongoDB

Di blog saya sebelumnya, Cara menggunakan Pemodelan Data MongoDB untuk Meningkatkan Operasi Throughput, kami membahas 2 pendekatan hubungan pemodelan data utama yaitu, embedding dan referensi. Skalabilitas MongoDB sangat bergantung pada arsitekturnya dan untuk lebih spesifiknya, pemodelan data. Saat merancang DBM NoSQL, poin utama pertimbangannya adalah memastikan dokumen tanpa skema selain sejumlah kecil koleksi untuk tujuan perawatan yang mudah. Integritas data yang baik, mengadopsi validasi data melalui beberapa aturan yang ditentukan sebelum penyimpanan didorong. Arsitektur dan desain basis data harus dinormalisasi dan didekomposisi menjadi beberapa kumpulan kecil sebagai cara menghindari pengulangan data, meningkatkan integritas data, dan mempermudah pola pengambilan. Dengan ini, Anda dapat meningkatkan konsistensi data, atomisitas, daya tahan, dan integritas database Anda.

Pemodelan data bukanlah usaha yang dilakukan setelah tahap pengembangan aplikasi tetapi pertimbangan awal karena banyak aspek aplikasi yang benar-benar direalisasikan selama tahap pemodelan data. Dalam artikel ini kita akan membahas faktor mana yang perlu dipertimbangkan selama pemodelan data dan melihat bagaimana faktor tersebut memengaruhi kinerja database secara umum.

Sering kali Anda perlu menerapkan cluster database Anda sebagai salah satu cara untuk meningkatkan ketersediaan data. Dengan model data yang dirancang dengan baik, Anda dapat mendistribusikan aktivitas ke sharded cluster secara lebih efektif sehingga mengurangi operasi throughput yang ditujukan untuk satu instance mongod. Faktor utama yang perlu dipertimbangkan dalam pemodelan data meliputi:

Skalabilitas
Atomitas
Kinerja dan penggunaan Data
Membagi
Pengindeksan
Pengoptimalan penyimpanan
Struktur dan pertumbuhan dokumen
Siklus Hidup Data

1. Skalabilitas

Ini adalah peningkatan beban kerja aplikasi yang didorong oleh peningkatan lalu lintas. Banyak aplikasi selalu memiliki harapan dalam peningkatan jumlah penggunanya. Ketika ada begitu banyak pengguna yang dilayani oleh satu contoh database, kinerjanya tidak selalu memenuhi harapan. Sebagai manajer basis data, Anda memiliki mandat untuk merancang DBM ini sehingga kumpulan dan entitas data dimodelkan berdasarkan permintaan aplikasi saat ini dan di masa mendatang. Struktur database umumnya harus rapi untuk meningkatkan kemudahan proses replikasi dan sharding. Saat Anda memiliki lebih banyak shard, operasi tulis didistribusikan di antara shard ini sehingga untuk pembaruan data apa pun, hal itu dilakukan di dalam shard yang berisi data itu daripada mencari dalam satu set data besar untuk melakukan pembaruan.

2. Atomisitas

Ini mengacu pada keberhasilan atau kegagalan suatu operasi sebagai satu unit. Misalnya Anda mungkin memiliki operasi baca yang melibatkan operasi pengurutan setelah mengambil hasilnya. Jika operasi sortir tidak ditangani dengan benar, maka seluruh operasi tidak akan dilanjutkan ke tahap berikutnya.

Transaksi atom adalah serangkaian operasi yang tidak dapat dibagi atau direduksi sehingga terjadi sebagai entitas tunggal atau gagal sebagai operasi tunggal. Versi MongoDB sebelum 4.0 mendukung operasi penulisan sebagai proses atom pada tingkat dokumen tunggal. Dengan versi 4.0, seseorang sekarang dapat mengimplementasikan transaksi multi-dokumen. Model data yang meningkatkan operasi atom cenderung memiliki kinerja yang hebat dalam hal latensi. Latensi hanyalah durasi di mana permintaan operasi dikirim dan ketika respons dikembalikan dari database. Agar seccant, mudah untuk memperbarui data yang disematkan dalam satu dokumen daripada yang dirujuk.

Mari kita perhatikan misalnya kumpulan data di bawah ini

{
    childId : "535523",
    studentName : "James Karanja",
    parentPhone : 704251068,
    age : 12,
    settings : {
        location : "Embassy",
        address : "420 01",
        bus : "KAZ 450G",
        distance : "4"
      }
}

Jika kami ingin memperbarui usia dengan menambahnya 1 dan mengubah lokasi ke London, kami dapat melakukan:

db.getCollection(‘students’).update({childId: 535523},{$set:{'settings.location':'London'}, $inc:{age:1}}).

Jika misalnya operasi $set gagal, maka secara otomatis operasi $inc tidak akan diimplementasikan dan secara umum seluruh operasi gagal.

Di sisi lain, mari kita pertimbangkan data yang direferensikan sehingga ada 2 koleksi satu untuk siswa dan yang lainnya untuk pengaturan.

Koleksi siswa

{
    childId : "535523",
    studentName : "James Karanja",
    parentPhone : 704251068,
    age : 12
}

Koleksi setelan

{
  childId : "535523",  
  location : "Embassy",
  address : "420 01",
  bus : "KAZ 450G",
  distance : "4"
}

Dalam hal ini Anda dapat memperbarui nilai usia dan lokasi dengan operasi tulis terpisah .i.e

db.getCollection(‘students’).update({childId: 535523},{$inc:{age:1}})
db.getCollection('settings’).update({childId: 535523 } , {$set: { 'settings.location':'London'}})

Jika salah satu operasi gagal, itu tidak serta merta mempengaruhi yang lain karena mereka dilakukan sebagai entitas yang berbeda.

Transaksi untuk Banyak Dokumen

Dengan MongoDB versi 4.0, Anda sekarang dapat melakukan beberapa transaksi dokumen untuk set replika. Ini meningkatkan kinerja karena operasi dikeluarkan ke sejumlah koleksi, database, dan dokumen untuk pemrosesan cepat. Ketika transaksi telah dilakukan, data disimpan sedangkan jika terjadi kesalahan dan transaksi gagal, perubahan yang telah dilakukan akan dibuang dan transaksi umumnya akan dibatalkan. Tidak akan ada pembaruan untuk set replika selama transaksi karena operasi hanya terlihat di luar saat transaksi dilakukan sepenuhnya.

Sebanyak Anda dapat memperbarui banyak dokumen dalam beberapa transaksi, itu datang dengan kemunduran kinerja yang berkurang dibandingkan dengan penulisan dokumen tunggal. Selain itu, pendekatan ini hanya didukung untuk mesin penyimpanan WiredTiger sehingga menjadi kerugian untuk mesin penyimpanan In-Memory dan MMAPv1.

3. Performa dan Penggunaan Data

Aplikasi dirancang secara berbeda untuk memenuhi tujuan yang berbeda. Ada beberapa yang melayani untuk data terkini saja seperti aplikasi berita cuaca. Bergantung pada struktur aplikasi, seseorang harus dapat merancang basis data koresponden yang optimal ke server kasus penggunaan yang diperlukan. Misalnya, jika seseorang mengembangkan aplikasi yang mengambil data terbaru dari database, menggunakan koleksi yang dibatasi akan menjadi pilihan terbaik. Koleksi yang dibatasi meningkatkan operasi throughput tinggi seperti buffer sehingga ketika ruang yang dialokasikan dieksploitasi, dokumen tertua ditimpa dan dokumen dapat diambil sesuai urutan penyisipannya. Mempertimbangkan pengambilan pesanan penyisipan, tidak perlu menggunakan pengindeksan dan tidak adanya overhead indeks akan sama-sama meningkatkan throughput tulis. Dengan koleksi yang dibatasi, data yang terkait cukup kecil karena dapat dipertahankan di dalam RAM untuk beberapa waktu. Data temporal dalam hal ini disimpan dalam cache yang cukup dibaca daripada ditulis sehingga membuat operasi baca cukup cepat. Namun, koleksi yang dibatasi memiliki beberapa kelemahan seperti, Anda tidak dapat menghapus dokumen kecuali menghapus seluruh koleksi, perubahan apa pun pada ukuran dokumen akan menggagalkan operasi dan terakhir, koleksi yang dibatasi tidak dapat di-shard.

Berbagai aspek terintegrasi dalam pemodelan data database tergantung pada kebutuhan penggunaan. Seperti yang terlihat, aplikasi laporan akan cenderung lebih banyak membaca sehingga desainnya harus dengan cara meningkatkan throughput baca.

4. Membagi

Kinerja melalui penskalaan horizontal dapat ditingkatkan dengan sharding karena beban kerja baca dan tulis didistribusikan di antara anggota cluster. Menyebarkan sekelompok pecahan cenderung mempartisi database menjadi beberapa koleksi kecil dengan dokumen terdistribusi tergantung pada beberapa kunci pecahan. Anda harus memilih kunci pecahan yang sesuai yang dapat mencegah isolasi kueri selain meningkatkan kapasitas tulis. Pilihan yang lebih baik umumnya melibatkan bidang yang ada di semua dokumen dalam koleksi yang ditargetkan. Dengan sharding, ada peningkatan penyimpanan karena seiring pertumbuhan data, lebih banyak shard dibuat untuk menampung subset dari cluster ini.

5. Pengindeksan

Pengindeksan adalah salah satu pendekatan terbaik untuk meningkatkan beban kerja tulis terutama di mana bidang terjadi di semua dokumen. Saat melakukan pengindeksan, seseorang harus mempertimbangkan bahwa setiap indeks akan membutuhkan 8KB ruang data. Selanjutnya, ketika indeks aktif, ia akan menghabiskan beberapa ruang disk dan memori sehingga harus dilacak untuk perencanaan kapasitas.

Beberapa Sembilan Menjadi DBA MongoDB - Membawa MongoDB ke ProduksiPelajari tentang apa yang perlu Anda ketahui untuk menerapkan, memantau, mengelola, dan menskalakan MongoDBUnduh secara Gratis

6. Optimalisasi Penyimpanan

Banyak dokumen kecil dalam koleksi akan cenderung memakan lebih banyak ruang daripada saat Anda memiliki beberapa dokumen dengan dokumen sub-sematan. Saat memodelkan, seseorang harus mengelompokkan data terkait sebelum disimpan. Dengan beberapa dokumen, operasi basis data dapat dilakukan dengan beberapa kueri sehingga mengurangi akses disk acak dan akan ada lebih sedikit entri kunci terkait dalam indeks yang sesuai. Oleh karena itu, pertimbangan dalam kasus ini adalah:gunakan penyematan untuk memiliki lebih sedikit dokumen yang pada gilirannya mengurangi overhead per dokumen. Gunakan nama bidang yang lebih pendek jika lebih sedikit bidang yang terlibat dalam kumpulan agar tidak membuat overhead dokumen menjadi signifikan. Nama bidang yang lebih pendek mengurangi ekspresif. yaitu

{ Lname : "Briston", score : 5.9 }

akan menghemat 9 byte per dokumen daripada menggunakan

{ last_name : "Briston", high_score: 5.9 }

Gunakan bidang _id secara eksplisit. Secara default, klien MongoDB menambahkan bidang _id ke setiap dokumen dengan menetapkan ObjectId 12-byte unik untuk bidang ini. Selain itu, bidang _id akan diindeks. Jika dokumennya cukup kecil, skenario ini akan memperhitungkan sejumlah besar ruang dalam jumlah dokumen secara keseluruhan. Untuk pengoptimalan penyimpanan, Anda diperbolehkan menentukan nilai untuk bidang _id secara eksplisit saat memasukkan dokumen ke dalam koleksi. Namun, pastikan nilainya diidentifikasi secara unik karena berfungsi sebagai kunci utama untuk dokumen dalam koleksi.

7. Struktur dan Pertumbuhan Dokumen

Ini terjadi sebagai akibat dari operasi push di mana subdokumen didorong ke dalam bidang larik atau ketika bidang baru ditambahkan ke dokumen yang sudah ada. Pertumbuhan dokumen memiliki beberapa kemunduran yaitu untuk koleksi yang dibatasi, jika ukurannya diubah maka operasi akan secara otomatis gagal. Untuk mesin penyimpanan MMAPv1, versi sebelum 3.0 akan memindahkan dokumen pada disk jika ukuran dokumen terlampaui. Namun, versi yang lebih baru mulai dari 3.0, ada konsep Power of 2 Sized Allocations yang mengurangi kemungkinan alokasi ulang tersebut dan memungkinkan penggunaan kembali ruang rekaman yang dibebaskan secara efektif. Jika Anda mengharapkan data Anda tumbuh, Anda mungkin ingin memfaktorkan ulang model data Anda untuk menggunakan referensi antar data dalam dokumen yang berbeda daripada menggunakan model data yang didenormalisasi. Untuk menghindari pertumbuhan dokumen, Anda juga dapat mempertimbangkan untuk menggunakan strategi pra-alokasi.

8. Daur Hidup Data

Untuk aplikasi yang hanya menggunakan dokumen yang baru saja dimasukkan, pertimbangkan untuk menggunakan koleksi terbatas yang fiturnya telah dibahas di atas.

Anda juga dapat mengatur fitur Time to Live untuk koleksi Anda. Ini cukup berlaku untuk token akses dalam fitur pengaturan ulang kata sandi untuk suatu aplikasi.

Waktunya Untuk Hidup (TTL)

Ini adalah pengaturan koleksi yang memungkinkan mongod untuk menghapus data secara otomatis setelah durasi yang ditentukan. Secara default, konsep ini diterapkan untuk data peristiwa, log, dan informasi sesi yang dihasilkan mesin yang perlu dipertahankan untuk jangka waktu terbatas.

Contoh:

db.log_events.createIndex( { "createdAt": 1 }, { expireAfterSeconds: 3600 } )

Kami telah membuat indeks CreatedAt dan menetapkan beberapa nilai expiredAfterSeconds 3600 yang merupakan 1 jam setelah waktu pembuatan. Sekarang jika kita memasukkan dokumen seperti:

db.log_events.insert( {
   "createdAt": new Date(),
   "logEvent": 2,
   "logMessage": "This message was recorded."
} )

Dokumen ini akan dihapus setelah 1 jam dari waktu penyisipan.

Anda juga dapat mengatur jam waktu tertentu saat Anda ingin dokumen dihapus. Untuk melakukannya, pertama buat indeks yaitu:

db.log_events.createIndex( { "expireAt": 1 }, { expireAfterSeconds: 0 } )

Sekarang kita dapat menyisipkan dokumen dan menentukan waktu kapan harus dihapus.

db.log_events.insert( {
   "expireAt": new Date(December 12, 2018 18:00:00'),
   "logEvent": 2,
   "logMessage": "Success!"
} )

Dokumen ini akan dihapus secara otomatis ketika nilai expiredAt lebih lama dari jumlah detik yang ditentukan dalam expiredAfterSeconds, yaitu 0 dalam kasus ini.

Kesimpulan

Pemodelan data adalah usaha yang luas untuk desain aplikasi apa pun untuk meningkatkan kinerja basis datanya. Sebelum memasukkan data ke db Anda, pertimbangkan kebutuhan aplikasi dan pola model data mana yang terbaik yang harus Anda terapkan. Selain itu, aspek penting dari aplikasi tidak dapat direalisasikan sampai penerapan model data yang tepat.