ApsaraDB for MongoDB：Pengenalan Instans Kluster Sharded ApsaraDB for MongoDB

Skenario

Jumlah node shard dan jumlah node mongos

Pemilihan kunci shard

• ApsaraDB for MongoDB mendukung strategi sharding berikut:
  • Sharding berbasis rentang, yang membagi data menjadi rentang kontinu berdasarkan nilai kunci shard.
  • Sharding berbasis hash, yang mendistribusikan data di antara node shard yang dikonfigurasi.
  • Sharding sadar tag, yang menyesuaikan aturan distribusi chunk berdasarkan tag.
    Catatan

    • Cara kerja strategi sharding:
      1. ApsaraDB for MongoDB memanggil metode sh.addShardTag() untuk menambahkan Tag A ke node shard.
      2. ApsaraDB for MongoDB memanggil metode sh.addTagRange() untuk menambahkan Tag A ke rentang chunk tertentu dari koleksi. Dengan cara ini, ApsaraDB for MongoDB mendistribusikan data dalam rentang chunk yang diberi label dengan Tag A ke node shard yang memiliki Tag A.
    • Skenario:
      • Tambahkan tag ke node shard berdasarkan pusat data tempat node shard tersebut ditempatkan. Ini memastikan data dalam rentang chunk didistribusikan ke pusat data dengan tag yang sama.
      • Tambahkan tag ke node shard berdasarkan nilai QPS dari node shard tersebut. Ini memungkinkan distribusi lebih banyak chunk ke node shard dengan QPS tinggi.
    • Catatan penggunaan:

      ApsaraDB for MongoDB tidak langsung mendistribusikan chunk ke node shard dengan tag tertentu. Distribusi chunk terjadi secara bertahap saat pemecahan dan migrasi chunk dipicu oleh operasi insert dan update. Pastikan balancer diaktifkan selama proses distribusi. Setelah tag ditambahkan ke rentang chunk, data yang ditulis mungkin tidak langsung didistribusikan ke node shard dengan tag yang sama.

    Untuk informasi lebih lanjut, lihat Sharding Sadar Tag.

• Sharding berbasis rentang dan sharding berbasis hash tidak dapat menyelesaikan masalah berikut:
  • Rentang nilai kunci shard kecil. Misalnya, jika pusat data dipilih sebagai kunci shard, sharding tidak efisien karena jumlah pusat data terbatas.
  • Nilai tertentu dari kunci shard terkandung dalam sejumlah besar dokumen. Dalam hal ini, chunk tunggal mungkin menyimpan sejumlah besar dokumen. Jika ukuran dokumen dalam chunk melebihi ukuran per chunk, chunk tersebut diberi label sebagai chunk jumbo dan tidak dapat dimigrasi oleh balancer.
  • Jika Anda menanyakan dan memperbarui data berdasarkan kriteria selain kunci shard, semua operasi menjadi scatter-gather query, yang lambat.
• Sharding efisien ketika kunci shard memiliki karakteristik berikut:
  • Kardinalitas yang cukup.
  • Operasi tulis yang didistribusikan secara merata.
  • Operasi baca yang ditargetkan.

Contoh:

Aplikasi IoT menggunakan instans kluster sharded untuk menyimpan log dari jutaan perangkat. Setiap perangkat mengirimkan log ke instans kluster sharded setiap 10 detik sekali. Log berisi informasi seperti ID perangkat dan timestamp. Log yang dihasilkan untuk perangkat tertentu selama rentang waktu tertentu sering ditanyakan.

Metode sharding berikut tersedia:

• Metode 1: Direkomendasikan. Gunakan kombinasi ID perangkat dan timestamp sebagai kunci shard dan lakukan sharding berbasis rentang.
  • Data yang ditulis didistribusikan secara merata di antara beberapa node shard.
  • Data dengan ID perangkat yang sama dapat dibagi lebih lanjut dan didistribusikan di antara beberapa chunk berdasarkan timestamp.
  • Saat Anda menanyakan log untuk perangkat tertentu selama rentang waktu tertentu, ApsaraDB for MongoDB dapat membuat indeks komposit berdasarkan ID perangkat dan timestamp untuk menyelesaikan query.
• Metode 2: Gunakan timestamp sebagai kunci shard dan lakukan sharding berbasis rentang.
  • Data dengan timestamp kontinu didistribusikan ke node shard yang sama, menyebabkan distribusi data tidak merata.
  • Query berbasis ID perangkat didistribusikan ke semua node shard, menurunkan efisiensi query.
• Metode 3: Gunakan timestamp sebagai kunci shard dan lakukan sharding berbasis hash.
  • Data yang ditulis didistribusikan secara merata di antara beberapa node shard.
  • Query berbasis ID perangkat didistribusikan ke semua node shard, menurunkan efisiensi query.
• Metode 4: Gunakan ID perangkat sebagai kunci shard dan lakukan sharding berbasis hash.
  Catatan Jika tidak ada aturan yang diberlakukan pada ID perangkat, Anda dapat melakukan sharding berbasis rentang.
  • Data yang ditulis didistribusikan secara merata di antara beberapa node shard.
  • Data dengan ID perangkat yang sama hanya dapat didistribusikan ke chunk yang sama, menyebabkan chunk jumbo. Query berbasis ID perangkat hanya dapat didistribusikan ke node shard tunggal, yang perlu memindai dan mengurutkan semua tabel berdasarkan rentang timestamp dalam query.

Chunk jumbo dan ukuran per chunk

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

Balancer

Penyeimbangan beban otomatis dalam instans kluster sharded diimplementasikan oleh thread latar belakang yang berjalan pada node mongos dari instans. Hanya satu tugas migrasi yang dapat dijalankan untuk setiap koleksi pada satu waktu. Penyeimbangan beban dipicu berdasarkan jumlah chunk per koleksi pada setiap node shard. Jika perbedaan antara jumlah chunk koleksi pada node shard dan jumlah total chunk koleksi mencapai ambang batas tertentu, ApsaraDB for MongoDB mulai memigrasi chunk koleksi dari node shard ke node shard lainnya. Tentukan 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 lebih lama, penggunaan ruang disk dalam katalog data mungkin terus meningkat bahkan setelah penulisan data dihentikan.

Masalah ini disebabkan oleh nilai parameter sharding.archiveMovedChunks dalam perintah moveChunk. Di MongoDB 3.0 atau lebih lama, nilai default parameter ini adalah true. Nilai true menunjukkan bahwa chunk diarsipkan di Shard A setelah dimigrasi dari Shard A ke Shard B. Jika chunk di Shard B rusak, Anda dapat memulihkan chunk dari Shard A. Chunk tersebut menempati ruang penyimpanan di Shard A dan Shard B, sehingga penggunaan ruang disk terus meningkat meskipun penulisan data telah dihentikan.