ApsaraDB for MongoDB:Pengenalan kluster sharded MongoDB

Kapan harus menggunakan kluster sharded?

Bagaimana menentukan jumlah shard dan mongos?

Pemilihan kunci shard

• Strategi sharding yang didukung oleh kluster sharded MongoDB

  • Range sharding mendukung kueri rentang berdasarkan kunci shard.

  • Hash sharding mendistribusikan operasi tulis secara merata ke seluruh shard.

  • Tag aware sharding memungkinkan Anda menyesuaikan aturan distribusi chunk.

    Catatan

    • Cara kerjanya

      1. Gunakan sh.addShardTag() untuk menetapkan Tag A pada sebuah shard.

      2. Gunakan sh.addTagRange() untuk menetapkan Tag A pada rentang chunk suatu koleksi. MongoDB kemudian memastikan bahwa rentang chunk dengan Tag A, atau superset dari rentang tersebut, didistribusikan ke shard yang memiliki Tag A.

    • Skenario

      • Anda dapat menetapkan tag data center pada shard yang dideploy di data center berbeda. Hal ini mendistribusikan data dari rentang chunk berbeda ke data center yang ditentukan.

      • Anda dapat menetapkan tag tingkat layanan pada shard dengan kemampuan layanan berbeda. Hal ini mendistribusikan lebih banyak chunk ke shard dengan kemampuan lebih tinggi.

    • Catatan

      ApsaraDB for MongoDB tidak dapat langsung mendistribusikan chunk ke node shard yang diberi label tag tertentu. Chunk didistribusikan secara bertahap seiring pemisahan dan migrasi chunk yang sering dipicu oleh operasi insert dan update. Pastikan balancer diaktifkan selama proses distribusi. Setelah tag ditambahkan ke rentang chunk, data yang ditulis mungkin tidak didistribusikan ke node shard yang memiliki tag yang sama dengan rentang chunk tersebut.

• Permasalahan yang tidak dapat diselesaikan oleh range dan hash sharding

  • Rentang nilai kunci shard terlalu kecil. Misalnya, jika Anda menggunakan data center sebagai kunci shard, sharding tidak efektif karena biasanya hanya ada sedikit data center.

  • Nilai kunci shard tertentu muncul di terlalu banyak dokumen. Hal ini dapat menyebabkan satu chunk berukuran sangat besar, yang dikenal sebagai jumbo chunk, sehingga memengaruhi migrasi chunk dan load balancing.

  • Kueri dan pembaruan berdasarkan bidang non-kunci shard menjadi kueri scatter-gather, yang tidak efisien.

• Karakteristik kunci shard yang baik

  • Kardinalitas yang cukup

  • Distribusi operasi tulis yang merata

  • Menghindari kueri scatter-gather (baca terarah).

Contoh:

Aplikasi IoT menggunakan instans kluster sharded untuk menyimpan log dari jutaan perangkat. Setiap perangkat mengirim log ke instans kluster sharded setiap 10 detik. Log tersebut berisi informasi seperti ID perangkat dan timestamp. Log yang dihasilkan oleh perangkat tertentu dalam rentang waktu tertentu sering dikueri.

Permintaan kueri: Mengambil log untuk perangkat tertentu dalam rentang waktu tertentu.

• (Direkomendasikan) Metode 1: Gunakan kunci shard gabungan berupa ID perangkat dan timestamp dengan range sharding.

  • Operasi tulis didistribusikan secara merata ke beberapa shard.

  • Data untuk ID perangkat yang sama selanjutnya didistribusikan ke beberapa chunk berdasarkan timestamp.

  • Kueri untuk rentang waktu berdasarkan ID perangkat dapat diselesaikan langsung menggunakan indeks gabungan (deviceId, timestamp).

• Metode 2: Gunakan timestamp sebagai kunci shard dengan range sharding.

  • Tulisan baru memiliki timestamp berurutan dan semuanya dikirim ke shard yang sama, menyebabkan distribusi tulis tidak merata.

  • Kueri berdasarkan ID perangkat tersebar ke semua shard, sehingga tidak efisien.

• Metode 3: Gunakan timestamp sebagai kunci shard dengan hash sharding.

  • Operasi tulis didistribusikan secara merata ke beberapa shard.

  • Kueri berdasarkan ID perangkat tersebar ke semua shard, sehingga tidak efisien.

• Metode 4: Gunakan ID perangkat sebagai kunci shard dengan hash sharding.

  Catatan

  Jika ID perangkat tidak memiliki pola yang jelas, Anda dapat menggunakan range sharding.

  • Operasi tulis didistribusikan secara merata ke beberapa shard.

  • Data untuk ID perangkat yang sama tidak dapat dibagi lagi dan hanya didistribusikan ke satu chunk. Hal ini menyebabkan jumbo chunk. Kueri berdasarkan ID perangkat dikirim ke satu shard. Setelah permintaan diarahkan ke shard tersebut, kueri rentang berdasarkan timestamp memerlukan pemindaian tabel penuh dan pengurutan.

Jumbo chunk dan ukuran per chunk

Ukuran default per chunk dalam instans kluster sharded adalah 64 MB. Jika ukuran chunk melebihi 64 MB dan chunk tersebut tidak dapat dipisah, chunk tersebut diberi label sebagai jumbo chunk. Misalnya, jika semua dokumen memiliki nilai kunci shard yang sama, dokumen-dokumen tersebut disimpan dalam chunk yang sama dan tidak dapat dipisah. Balancer tidak dapat memigrasi jumbo chunk, yang dapat menyebabkan ketidakseimbangan beban. Kami merekomendasikan agar Anda mencegah terbentuknya jumbo chunk.

Tentang load balancing

Load balancing otomatis dalam instans kluster sharded diimplementasikan oleh thread latar belakang yang berjalan pada node mongos instans tersebut. Hanya satu tugas migrasi yang dapat dijalankan untuk setiap koleksi pada waktu tertentu. Load balancing dipicu berdasarkan jumlah chunk per koleksi pada setiap node shard. Jika selisih antara jumlah chunk suatu koleksi pada sebuah node shard dan jumlah total chunk koleksi tersebut mencapai ambang batas yang ditentukan, ApsaraDB for MongoDB akan mulai memigrasikan chunk koleksi tersebut dari node shard ke node shard lainnya. Anda harus menentukan ambang batas berdasarkan jumlah total chunk.

use config
                db.settings.update(
                { _id: "balancer" },
                { $set: { activeWindow : { start : "02:00", stop : "06:00" } } },
                { upsert: true }
                )
            

sh.stopBalancer()            

Pengaturan arsip dalam perintah moveChunk

Jika instans kluster sharded menjalankan MongoDB 3.0 atau versi sebelumnya, penggunaan disk space dalam katalog data dapat terus meningkat meskipun penulisan data telah dihentikan.

Permasalahan ini disebabkan oleh item konfigurasi sharding.archiveMovedChunks, yang secara default bernilai true pada MongoDB 3.0 dan versi sebelumnya. Pengaturan ini berarti bahwa selama operasi moveChunk, shard sumber mengarsipkan data chunk yang dimigrasikan untuk tujuan pemulihan. Akibatnya, saat chunk dimigrasikan, disk space pada node sumber tidak dilepaskan, sedangkan node tujuan menggunakan disk space baru.