Apakah MongoDB Sharding dan Praktik Terbaik?

Bagaimana cara mengukur MongoDB? Apa praktik sharding terbaik?


Meskipun skema fleksibel adalah cara sebagian besar orang mengenal MongoDB, skema ini juga merupakan salah satu database terbaik (bahkan mungkin yang terbaik dalam hal aplikasi sehari-hari) untuk menangani set data yang sangat, sangat besar. Sementara pembenaran argumen ini membutuhkan seluruh artikel itu sendiri (saya harap saya dapat menemukan waktu untuknya suatu hari nanti!), Ide umumnya adalah bahwa solusi berbasis SQL tidak mendukung sharding, dan membangunnya di atas kesulitan Anda..

Yang terbaik yang dapat Anda harapkan adalah membuat sebuah cluster (yang tidak ada hubungannya dengan sharding secara fundamental, dengan cara) atau mencari solusi yang dikelola seperti Amazon RDS atau Google Cloud SQL, yang menjadi sangat mahal ketika data Anda tumbuh.

Di artikel ini, kita akan melihat salah satu teknik penting untuk penskalaan basis data horizontal: sharding, untuk MongoDB, dan merekomendasikan beberapa praktik terbaik untuk hal yang sama. Namun, saya merasa lebih baik memulai dengan dasar-dasar sharding, karena banyak orang yang mencari skala MongoDB mungkin tidak terlalu mengenalnya..

Namun, jika Anda sadar akan sharding, silakan membaca bagian selanjutnya.

Dasar-Dasar Sharding

Anda mungkin telah memperhatikan penggunaan kata “horisontal” pada paragraf terakhir dari bagian sebelumnya. Tanpa meluncurkan jalan memutar besar lainnya, saya ingin mengangkat poin ini dengan cepat. Penskalaan mempertimbangkan dua jenis: Anda mendapatkan mesin yang lebih kuat dengan kapasitas penyimpanan yang lebih tinggi (vertikal), atau Anda menghubungkan beberapa komputer yang lebih kecil dan membentuk koleksi (horisontal).

Sekarang, mengingat bahwa bahkan server terbaik saat ini tidak memiliki lebih dari 256 GB RAM atau 16 TB hard disk, Anda menabrak dinding bata segera ketika mencoba untuk skala secara vertikal (atau “skala,” sebagai terminologi berjalan). Namun, Anda dapat menghubungkan sebanyak satu mesin bersama (setidaknya secara teoritis) dan memotong batasan ini dengan mudah.

Tentu saja, tantangannya sekarang adalah untuk berkoordinasi dengan semua mesin ini.

Database Sharding

Istilah “sharding” umumnya berlaku untuk database, gagasan bahwa satu mesin tidak akan pernah cukup untuk menampung semua data. Saat sharding, basis data “dipecah” menjadi potongan-potongan terpisah yang berada pada mesin yang berbeda. Contoh sederhana mungkin: misalkan bisnis memiliki mesin yang dapat menyimpan hingga 2 juta item data pelanggan. Sekarang, bisnis ini mencapai titik break-break dan kemungkinan akan melampaui 2,5 juta pengguna segera. Jadi, mereka memutuskan untuk memecah database mereka menjadi dua:

Dan ajaibnya, kapasitas sistem sekarang berlipat ganda!

Ya, seandainya hidup sesederhana itu! ��

Tantangan dalam database sharding

Segera setelah Anda berpikir sedikit dalam tentang sharding, beberapa tantangan jahat mendukung kepala mereka yang jelek.

Tidak ada kunci utama

Segera setelah Anda keluar dari satu basis data, kunci primer kehilangan artinya. Sebagai contoh, jika kunci utama Anda disetel ke peningkatan otomatis, dan Anda memindahkan separuh data ke basis data lain, kini Anda akan memiliki dua item data yang berbeda untuk setiap kunci utama.

Tidak ada kunci asing

Karena tidak ada dukungan dalam database untuk menunjuk ke entitas di luar database saat ini (baik, bahkan database yang berbeda pada mesin yang sama tidak didukung, jadi lupakan database pada mesin yang berbeda), konsep kunci asing berlaku untuk undian sebagai baik. Tiba-tiba, basis data menjadi “bisu,” dan integritas data adalah masalah Anda.

Kesalahan data aneh

Jika satu mesin mati, pengguna akhir dapat diperlihatkan sebuah “Ups, ada yang rusak!” Halaman, yang tidak diragukan lagi akan mengganggu, tetapi hidup akan berada di jalur setelah beberapa waktu.

Sekarang perhatikan apa yang terjadi di database yang terbengkalai. Misalkan database berjenggot dalam contoh kami sebelumnya adalah database perbankan dan satu pelanggan mengirim uang ke yang lain. Mari kita anggap juga data pelanggan pertama tinggal di beling pertama, sedangkan data pelanggan kedua tinggal di beling kedua (Anda lihat ke mana saya akan pergi dengan ini ?!). Jika mesin yang berisi pecahan kedua gagal, dapatkah Anda bayangkan dalam kondisi apa sistem akan berada? Kemana perginya uang transaksi? Apa yang akan dilihat pengguna pertama? Apa yang akan dilihat pengguna kedua? Apa yang akan mereka berdua lihat ketika pecahan kembali online?

Pengelolaan transaksi

Mari kita juga mempertimbangkan kasus manajemen transaksi yang selalu kritis. Kali ini, anggaplah sistem bekerja dengan baik 100%. Sekarang, dua orang (A dan B) melakukan pembayaran ke yang ketiga (C). Sangat mungkin kedua transaksi akan membaca saldo akun C secara bersamaan, menyebabkan kebingungan ini:

  • Saldo akun C = $ 100.
  • Transaksi A membaca saldo C: $ 100.
  • Transaksi B membaca saldo C: $ 100.
  • Transaksi A menambah $ 50 dan memperbarui saldo: $ 100 + 50 = $ 150.
  • Transaksi B menambah $ 50 dan memperbarui saldo: $ 100 + 50 = $ 150.

Sial! $ 50 menghilang begitu saja!

Sistem SQL tradisional menyelamatkan Anda dari ini dengan menyediakan manajemen transaksi internal, tetapi begitu Anda keluar dari satu mesin, Anda bersulang.

Intinya, dengan sistem seperti itu, mudah untuk mengalami masalah korupsi data yang tidak mungkin dipulihkan. Menarik rambutmu juga tidak akan membantu! ��

MongoDB Sharding

Untuk arsitek perangkat lunak, kegembiraan tentang MongoDB tidak begitu banyak dalam skema fleksibelnya, seperti dalam dukungan sharding bawaannya. Dengan hanya beberapa aturan sederhana dan mesin yang terhubung, Anda siap menjalankan cluster MongoDB yang tergesa-gesa dalam waktu singkat.

Gambar di bawah ini menunjukkan bagaimana ini terlihat dalam penerapan aplikasi web yang khas.

Kredit gambar: mongodb.com

Bagian terbaik tentang MongoDB sharding adalah bahkan menyeimbangkan pecahan adalah otomatis. Itu adalah jika Anda memiliki lima pecahan dan dua di antaranya hampir kosong, Anda dapat memberitahu MongoDB untuk menyeimbangkan kembali hal-hal sedemikian rupa sehingga semua pecahan sama-sama penuh.

Sebagai pengembang atau administrator, Anda tidak perlu terlalu khawatir, karena MongoDB di belakang layar melakukan sebagian besar pekerjaan berat. Hal yang sama berlaku untuk kegagalan sebagian node; jika Anda memiliki set replika yang dikonfigurasikan dengan benar dan berjalan di cluster Anda, pemadaman sebagian tidak akan memengaruhi waktu kerja sistem.

Seluruh penjelasan akan menjadi agak singkat, jadi saya akan menutup bagian ini dengan mengatakan bahwa MongoDB memiliki beberapa alat bawaan untuk sharding, replikasi, dan pemulihan, sehingga sangat mudah bagi pengembang untuk membangun aplikasi skala besar. Jika Anda ingin panduan yang lebih komprehensif untuk kapabilitas MongoDB, the dokumen resmi adalah tempatnya.

Anda mungkin juga tertarik dengan ini lengkapi panduan pengembang.

Praktik Terbaik Sharding MongoDB

Sementara MongoDB “hanya bekerja” di luar kotak untuk sharding, itu tidak berarti kita bisa berpuas diri. Sharding dapat membuat atau menghancurkan proyek Anda selamanya, tergantung pada seberapa baik atau buruknya itu dilakukan.

Selain itu, ada banyak detail kecil yang harus diperhitungkan, gagal yang, tidak jarang melihat proyek runtuh. Tujuannya bukan untuk menakut-nakuti Anda, tetapi untuk menyoroti perlunya perencanaan dan menjadi sangat berhati-hati bahkan dengan keputusan kecil.

Kunci Sharding mau tidak mau mengendalikan pecahan di MongoDB, sehingga sangat ideal bagi kami untuk memulai survei dengan.

Kardinalitas tinggi

Kardinalitas berarti jumlah variasi. Misalnya, kumpulan negara favorit 1 juta orang akan memiliki variasi rendah (hanya ada begitu banyak negara di dunia!), Sedangkan koleksi alamat email mereka akan (sempurna) kardinalitas tinggi. Mengapa itu penting? Misalkan Anda memilih skema naif yang membagi data berdasarkan nama depan pengguna.

Di sini kita memiliki pengaturan yang agak sederhana; dokumen yang masuk dipindai untuk nama pengguna, dan tergantung di mana huruf pertama terletak pada alfabet Inggris, ia masuk ke salah satu dari tiga pecahan. Demikian pula, mencari dokumen itu mudah: perincian untuk “Peter”, misalnya, pasti ada di beling kedua.

Semua terdengar bagus, tetapi intinya, kami tidak mengontrol nama pengguna dokumen yang masuk. Bagaimana jika kita hanya mendapatkan nama dalam rentang B ke F sebagian besar waktu? Jika demikian, kita akan memiliki apa yang disebut potongan “jumbo” dalam shard1: sebagian besar data sistem akan ramai di sana, secara efektif mengubah pengaturan menjadi satu sistem basis data tunggal.

Obatnya?

Pilih kunci dengan kardinalitas tinggi – misalnya, alamat email pengguna, atau Anda bahkan dapat menggunakan kunci beling campuran, yang merupakan kombinasi dari beberapa bidang.

Berubah secara monoton

Kesalahan umum dalam sharding MongoDB adalah menggunakan kunci yang meningkat secara monoton (atau meningkat otomatis, jika Anda mau) sebagai kunci beling.

Secara umum, kunci utama dokumen digunakan. Idenya di sini bermakna baik, yaitu, karena dokumen baru terus dibuat, mereka akan jatuh secara merata ke dalam salah satu pecahan yang tersedia. Sayangnya, konfigurasi seperti itu adalah kesalahan klasik. Ini terjadi karena jika kunci beling selalu meningkat, setelah titik data akan mulai menumpuk di sisi bernilai tinggi dari beling, menyebabkan ketidakseimbangan dalam sistem.

Kredit gambar: mongodb.com

Seperti yang Anda lihat dalam gambar, setelah kami melewati rentang 20, semua dokumen mulai mengumpulkan di Chunk C, menyebabkan monolit di sana. Solusinya adalah pergi untuk skema kunci sharding hash, yang menciptakan kunci sharding dengan hashing salah satu bidang yang disediakan dan menggunakannya untuk menentukan chunk.

Kredit gambar: Mongodb.com

Kunci pecahan hash terlihat seperti ini:

{
"_Indo" :"6b85117af532da651cc912cd"
}

. . . dan dapat dibuat di shell klien Mongo dengan menggunakan:

db.collection.createIndex ({_id: hashedValue})

Shard Early

Salah satu saran paling berguna langsung dari parit adalah untuk beling lebih awal, bahkan jika Anda berakhir dengan sekelompok kecil, dua-chunk. Setelah data mencapai 500 GB atau apa, sharding menjadi proses berantakan di MongoDB, dan Anda harus siap untuk kejutan yang tidak menyenangkan. Selain itu, proses penyeimbangan ulang mengkonsumsi bandwidth jaringan dalam jumlah sangat tinggi, yang dapat mencekik sistem jika Anda tidak berhati-hati.

Namun, tidak semua orang pro-sharding. Sebagai contoh yang menarik (pembelajarannya benar-benar ada di komentar), lihat Percona yang bagus ini blog.

Menjalankan penyeimbang

Ide bagus lainnya adalah memantau pola lalu lintas Anda dan menjalankan penyeimbang beling hanya pada waktu lalu lintas rendah. Seperti yang telah saya sebutkan, penyeimbangan ulang sendiri membutuhkan bandwidth yang besar, yang dapat dengan cepat membuat keseluruhan sistem merangkak. Ingat, pecahan yang tidak seimbang bukanlah penyebab panik segera. Biarkan penggunaan normal tetap ada, tunggu peluang lalu lintas rendah, dan biarkan penyeimbang melakukan sisanya!

Inilah cara Anda dapat melakukan ini (dengan asumsi Anda memiliki lalu lintas rendah dari jam 3 pagi hingga jam 5 pagi):

gunakan config
db.settings.update (
{ _Indo: "pengimbang" },
{$ set: {activeWindow: {start: "03:00", berhenti : "05:00" }}},
{upsert: true}
)

Kesimpulan

Mengabaikan dan menskalakan basis data apa pun adalah pekerjaan yang sulit, tetapi untungnya MongoDB membuatnya lebih mudah dikelola daripada basis data populer lainnya di luar sana.

Memang ada saat ketika MongoDB bukan pilihan yang tepat untuk proyek apa pun (berkat beberapa masalah kritis dan perilaku default), tetapi itu sudah lama berlalu. Seiring dengan sharding, penyeimbangan ulang, kompresi otomatis, kunci terdistribusi tingkat agregat, dan banyak fitur lainnya, MongoDB telah datang jauh di depan adalah pilihan pertama arsitek perangkat lunak ini.

Saya harap artikel ini bisa menjelaskan tentang apa itu pecahan di MongoDB, dan apa yang harus dijaga pengembang ketika akan meningkatkan skala. Untuk mempelajari lebih lanjut, Anda dapat memperoleh ini kursus online untuk menguasai MongoDB.

TAGS:

  • Basis data

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map