Praktik terbaik untuk penyesuaian skala throughput yang disediakan

  • Berlaku untuk: ✅ NoSQL, ✅ MongoDB, ✅ Apache Cassandra, ✅ Apache Gremlin, ✅ Table

Artikel ini menjelaskan praktik dan strategi terbaik untuk menskalakan throughput database atau kontainer Anda (koleksi, tabel, atau grafik). Konsep ini berlaku ketika Anda meningkatkan unit permintaan manual yang disediakan per detik (RU/d) atau maksimum RU per detik dalam skala otomatis dari sumber daya apa pun untuk salah satu API Azure Cosmos DB.

Prerequisites

Latar belakang penskalaan RU per detik

Saat Anda mengirim permintaan untuk meningkatkan RU/s database atau kontainer Anda, tergantung pada RU/s yang diminta dan tata letak partisi fisik Anda saat ini, operasi peningkatan kapasitas dapat selesai secara instan atau asinkron (biasanya 4-6 jam).

  • Peningkatan skala instan:

    • Ketika RU yang Anda minta dapat didukung oleh tata letak partisi fisik saat ini, Azure Cosmos DB tidak perlu membagi atau menambahkan partisi baru.
    • Sebagai hasilnya, operasi langsung selesai dan RU/s tersedia untuk digunakan.

  • Meningkatkan kinerja asinkron:

    • Ketika RU yang diminta lebih tinggi dari apa yang dapat didukung oleh tata letak partisi fisik, Azure Cosmos DB membagi partisi fisik yang ada. Hal ini terjadi sampai sumber daya memiliki jumlah minimum partisi yang diperlukan untuk mendukung RU yang diminta.
    • Akibatnya, operasi dapat memakan waktu cukup lama, biasanya 4-6 jam. Setiap partisi fisik dapat mendukung throughput maksimum 10.000 RU/s (berlaku untuk semua API) dan 50 GB penyimpanan (berlaku untuk semua API kecuali Cassandra, yang memiliki 30 GB penyimpanan).

    Nota

    Jika Anda melakukan operasi wilayah tulis perubahan atau menambahkan/menghapus wilayah baru saat operasi peningkatan skala asinkron sedang berlangsung, operasi peningkatan skala throughput akan dijeda. Proses ini akan dilanjutkan secara otomatis setelah operasi gagal alih atau tambah/hapus wilayah selesai.

  • Penurunan skala secara instan:

    • Untuk operasi penurunan skala, Azure Cosmos DB tidak perlu membagi atau menambahkan partisi baru.
    • Sebagai hasilnya, operasi langsung selesai dan RU/s tersedia untuk digunakan.
    • Hasil utama dari operasi ini adalah bahwa RU per partisi fisik berkurang.

Cara meningkatkan RU tanpa mengubah tata letak partisi

Langkah 1: Temukan jumlah partisi fisik saat ini

Arahkan ke Insights>Throughput>Normalized RU Consumption (%) By PartitionKeyRangeID. Hitung jumlah PartitionKeyRangeIds yang berbeda.

Cuplikan layar memperlihatkan jumlah PartitionKeyRangeIds yang berbeda dalam bagan Konsumsi RU yang Dinormalisasi oleh PartitionKeyRangeID.

Nota

Bagan hanya menampilkan maksimum 50 Partition Key Range Ids. Jika sumber daya Anda memiliki lebih dari 50, Anda dapat menggunakan Azure Cosmos DB REST API untuk menghitung jumlah total partisi.

Setiap PartitionKeyRangeId dipetakan ke satu partisi fisik dan ditugaskan untuk menyimpan data dalam rentang nilai hash yang mungkin.

Azure Cosmos DB mendistribusikan data Anda di seluruh partisi logis dan fisik berdasarkan kunci partisi Anda untuk mengaktifkan penskalaan horizontal. Saat data ditulis, Azure Cosmos DB menggunakan hash dari nilai kunci partisi untuk menentukan partisi logis dan fisik mana yang menjadi tempat data hidup.

Langkah 2: Hitung throughput maksimum secara default

RU tertinggi yang dapat Anda skalakan tanpa memicu Azure Cosmos DB untuk membagi partisi sama dengan Current number of physical partitions * 10,000 RU/s.

Anda bisa mendapatkan nilai ini dari penyedia sumber daya Azure Cosmos DB. Lakukan permintaan GET pada database atau objek pengaturan throughput kontainer Anda dan ambil instantMaximumThroughput properti. Nilai ini juga tersedia di halaman Skala dan Pengaturan database atau kontainer Anda di portal.

Example

Misalkan Anda memiliki kontainer yang ada dengan lima partisi fisik dan 30.000 RU/s throughput yang ditetapkan secara manual. Anda dapat meningkatkan RU/dtk menjadi 5 * 10,000 RU/s = 50,000 RU/s secara instan. Demikian pula jika kita memiliki kontainer dengan RU maks otomatis 30.000 RU (timbangan antara 3000 - 30.000 RU), kita dapat meningkatkan RU maks kita menjadi 50.000 RU secara instan (timbangan antara 5000 - 50.000 RU).

Tip

Jika Anda meningkatkan RU/dtk untuk menanggapi pengecualian akibat tingkat permintaan yang terlalu besar (kode 429), disarankan untuk terlebih dahulu meningkatkan RU/dtk sampai batas tertinggi yang didukung oleh konfigurasi partisi fisik saat ini dan menilai apakah peningkatan ini sudah memenuhi kebutuhan sebelum meningkat lebih jauh.

Cara memastikan distribusi data genap selama penskalaan asinkron

Latar belakang

Saat Anda meningkatkan RU/detik melebihi jumlah physical partitions * 10,000 RU/s saat ini, Azure Cosmos DB akan membagi partisi yang ada sampai jumlah partisi baru menjadi ROUNDUP(requested RU/s / 10,000 RU/s). Pada saat pemisahan, partisi induk dibagi menjadi dua partisi anak.

Misalnya, Anda memiliki kontainer dengan tiga partisi fisik dan 30.000 RU/dtk kapasitas pemrosesan yang disediakan secara manual. Jika Anda meningkatkan throughput menjadi 45.000 RU/dtk, Azure Cosmos DB akan membagi dua partisi fisik yang ada sehingga secara total, terdapat ROUNDUP(45,000 RU/s / 10,000 RU/s) = 5 physical partitions.

Nota

Aplikasi dapat mengonsumsi atau meminta data kapan saja selama pembagian. SDK dan layanan klien Azure Cosmos DB secara otomatis menangani skenario ini dan memastikan bahwa permintaan dirutekan ke partisi fisik yang benar, sehingga tidak ada tindakan pengguna lain yang diperlukan.

Jika Anda memiliki beban kerja yang didistribusikan secara merata sehubungan dengan penyimpanan dan volume permintaan—biasanya dicapai dengan pemartisian dengan bidang kardinalitas tinggi seperti /id—disarankan untuk mengatur RU sedemikian rupa sehingga semua partisi dibagi secara merata saat Anda meningkatkan skala.

Untuk melihat alasannya, mari kita ambil contoh di mana Anda memiliki kontainer yang ada dengan dua partisi fisik, 20.000 RU/s, dan data 80 GB.

Berkat memilih kunci partisi yang baik dengan kardinalitas tinggi, data secara kasar didistribusikan secara merata di kedua partisi fisik. Setiap partisi fisik diberi sekitar 50% dari keyspace, yang didefinisikan sebagai kisaran total nilai hash yang mungkin.

Selain itu, Azure Cosmos DB mendistribusikan RU secara merata di semua partisi fisik. Akibatnya, setiap partisi fisik memiliki 10.000 RU/s dan 50% (40 GB) dari total data. Diagram berikut menunjukkan keadaan kita saat ini.

Diagram memperlihatkan dua PartitionKeyRangeIds, masing-masing dengan 10.000 RU per detik, 40 GB, dan 50% dari total keyspace.

Sekarang, misalkan Anda ingin meningkatkan RU kami dari 20.000 RU menjadi 30.000 RU/s.

Jika Anda hanya meningkatkan RU/dtk menjadi 30.000 RU/dtk, salah satu saja dari partisi tersebut akan dipecah. Setelah pemisahan, Anda memiliki:

  • Satu partisi yang berisi 50% data (partisi ini tidak dibagi).
  • Dua partisi masing-masing berisi 25% data (ini adalah partisi anak yang dihasilkan dari pemisahan partisi induk).

Karena Azure Cosmos DB mendistribusikan RU/s secara merata di semua partisi fisik, setiap partisi fisik masih mendapatkan 10.000 RU/s. Namun, sekarang terdapat ketidakseimbangan dalam penyimpanan dan distribusi permintaan.

Dalam diagram berikut, Partisi 3 dan 4 (partisi anak Partisi 2) masing-masing memiliki 10.000 RU/dtk untuk melayani permintaan data 20 GB, sedangkan Partisi 1 memiliki 10.000 RU/dtk untuk melayani permintaan dua kali jumlah data (40 GB).

Diagram yang menunjukkan ada 3 PartitionKeyRangeIds, masing-masing dengan 10.000 RU/dtk, setelah pemisahan. Salah satu PartitionKeyRangeIds memiliki 50% dari total keyspace, sementara dua PartitionKeyRangeIds memiliki 25% dari total keyspace.

Untuk mempertahankan distribusi penyimpanan yang merata, Anda dapat terlebih dahulu meningkatkan RU/dtk untuk memastikan setiap partisi terpecah. Kemudian, Anda dapat menurunkan RU/s Anda kembali ke tingkat yang diinginkan.

Jadi, jika Anda mulai dengan dua partisi fisik, untuk menjamin bahwa partisi merata setelah pemisahan, Anda perlu mengatur RU/detik sedemikian rupa sehingga Anda berakhir dengan empat partisi fisik. Untuk mencapai ini, set RU/s = 4 * 10,000 RU/s per partition = 40,000 RU/spertama . Kemudian, setelah pemisahan selesai, turunkan RU/s Anda menjadi 30.000 RU/s.

Akibatnya, setiap partisi fisik 30,000 RU/s / 4 = 7500 RU/s dapat melayani permintaan data sebesar 20 GB. Secara keseluruhan, Anda mempertahankan penyimpanan yang merata dan meminta distribusi di seluruh partisi.

Diagram yang menunjukkan RU/s telah diturunkan dari 40.000 RU/s menjadi 30.000 RU/s. Ada 4 PartitionKeyRangeIds, masing-masing dengan 7500 RU/s dan 25% dari total keyspace.

Rumus Umum

Langkah 1: Tingkatkan RU Anda untuk memastikan bahwa semua partisi terbagi rata

Secara umum, jika Anda memiliki jumlah awal partisi fisik P, dan ingin mengatur RU/s yang diinginkan S:

Tingkatkan RU Anda menjadi: 10,000 * P * (2 ^ (ROUNDUP(LOG_2 (S/(10,000 * P)))). Ini memberikan RU/dtk terdekat dengan nilai yang diinginkan yang memastikan semua partisi dibagi secara merata.

Nota

Ketika Anda meningkatkan RU/dtk dalam database atau kontainer, hal ini dapat memengaruhi batas minimum RU/dtk yang dapat Anda atur di masa mendatang. Biasanya, unit permintaan per detik (RU/dtk) minimum sama dengan MAX(400 RU/s, Current storage in GB * 1 RU/s, Highest RU/s ever provisioned / 100). Misalnya, jika RU tertinggi yang pernah Anda skala adalah 100.000 RU, RU terendah yang dapat Anda tetapkan di masa depan adalah 1000 RU. Pelajari lebih lanjut tentang RU/detik minimum.

Langkah 2: Turunkan nilai RU Anda ke nilai RU yang diinginkan

Sebagai contoh, misalkan kita memiliki lima partisi fisik, 50.000 RU per detik dan ingin meningkatkan skala ke 150.000 RU per detik. Kita harus terlebih dahulu mengatur: 10,000 * 5 * (2 ^ (ROUND(LOG_2(150,000/(10,000 * 5)))) = 200,000 RU/s, dan kemudian lebih rendah menjadi 150.000 RU/s.

Ketika kita meningkatkan kapasitas hingga 200.000 RU/d, RU/d manual terendah yang dapat kita tetapkan ke depan adalah 2000 RU/d. RU/s maksimal autoscale terendah yang dapat kita atur adalah 20.000 RU/s (berkisar antara 2000 - 20.000 RU/s). Karena target RU/s kami adalah 150.000 RU/s, kami tidak terpengaruh oleh RU/s minimum.

Cara mengoptimalkan RU/s untuk pemrosesan data dalam jumlah besar

Saat Anda berencana untuk memigrasikan atau memasukkan sejumlah besar data ke dalam Azure Cosmos DB, disarankan untuk mengatur RU/s kontainer sehingga Azure Cosmos DB melakukan praprovisi partisi fisik yang diperlukan untuk menyimpan jumlah total data yang Anda rencanakan untuk dimasukkan sejak awal. Jika tidak, selama proses penyerapan data, Azure Cosmos DB mungkin harus membagi partisi-partisi, yang menambahkan waktu tambahan ke penyerapan data.

Kita dapat memanfaatkan fakta bahwa selama pembuatan kontainer, Azure Cosmos DB menggunakan rumus heuristik dari RU/s awal untuk menghitung jumlah partisi fisik yang akan diinisialisasi.

Langkah 1: Tinjau pilihan kunci partisi

Ikuti praktik terbaik untuk memilih kunci partisi guna memastikan Anda memiliki distribusi volume permintaan dan penyimpanan yang merata setelah migrasi.

Langkah 2: Menghitung jumlah partisi fisik yang Anda butuhkan

Number of physical partitions = Total data size in GB / Target data per physical partition in GB

Setiap partisi fisik dapat menampung maksimum penyimpanan 50 GB (30 GB untuk API untuk Cassandra). Nilai yang harus Anda pilih untuk Data target per partisi fisik dalam GB tergantung pada seberapa penuh Anda ingin partisi fisik diisi, dan seberapa banyak pertumbuhan penyimpanan yang Anda harapkan setelah migrasi.

Misalnya, jika Anda mengantisipasi bahwa penyimpanan akan terus bertambah, Anda dapat memilih untuk mengatur nilai menjadi 30 GB. Dengan asumsi Anda memilih kunci partisi yang baik yang mendistribusikan penyimpanan secara merata, setiap partisi adalah ~60% penuh (30 GB dari 50 GB). Saat data masa depan ditulis, data tersebut dapat disimpan pada set partisi fisik yang ada, tanpa memerlukan layanan untuk segera menambahkan partisi fisik yang lebih banyak.

Sebaliknya, jika Anda yakin bahwa penyimpanan tidak akan tumbuh secara signifikan pascamigrasi, Anda dapat memilih untuk menetapkan nilai lebih tinggi, misalnya 45 GB. Ini berarti setiap partisi ~ 90% penuh (45 GB dari 50 GB). Ini meminimalkan jumlah partisi fisik yang tersebar di data Anda, yang berarti setiap partisi fisik bisa mendapatkan fraksi yang lebih besar dari total RU yang disediakan.

Langkah 3: Hitung jumlah RU/s yang akan digunakan sebagai awal untuk semua partisi

Starting RU/s for all partitions = Number of physical partitions * Initial throughput per physical partition

Mari kita mulai dengan contoh yang memiliki jumlah target RU/detik per partisi fisik.

  • Initial throughput per physical partition = 10,000 RU/s per physical partition saat menggunakan database autoscale atau throughput bersama
  • Initial throughput per physical partition = 6000 RU/s per physical partition saat menggunakan throughput manual

Example

Katakanlah Anda memiliki 1 TB (1.000 GB) data untuk diserap dan Anda ingin menggunakan throughput manual. Setiap partisi fisik di Azure Cosmos DB memiliki kapasitas 50 GB. Mari kita asumsikan Anda bertujuan untuk mengemas partisi menjadi 80% penuh (40 GB), meninggalkan ruang untuk pertumbuhan di masa depan.

Ini berarti bahwa untuk 1 TB data, Anda memerlukan 1000 GB / 40 GB = 25 partisi fisik. Untuk memastikan Anda mendapatkan 25 partisi fisik, dengan menggunakan throughput manual, terlebih dahulu Anda perlu menyediakan 25 * 6000 RU/s = 150,000 RU/s. Kemudian, setelah kontainer dibuat, untuk mempercepat proses input, tingkatkan RU/s menjadi 250.000 sebelum proses dimulai (dilakukan secara instan karena Anda sudah memiliki 25 partisi fisik). Hal ini memungkinkan setiap partisi untuk mendapatkan maksimum 10.000 RU/detik.

Jika Anda menggunakan throughput skala otomatis atau database throughput bersama, untuk mendapatkan 25 partisi fisik, Anda akan terlebih dahulu menyediakan 25 * 10,000 RU/s = 250,000 RU/s. Karena Anda sudah berada di RU/s tertinggi yang dapat didukung dengan 25 partisi fisik, kami tidak akan lebih meningkatkan RU/s yang kami sediakan sebelum proses pengambilan data.

Secara teori, dengan 250.000 RU/s dan 1 TB data, jika kita mengasumsikan dokumen 1 kb dan 10 RU yang diperlukan untuk menulis, ingesti dapat secara teoritis selesai dalam: 1000 GB * (1,000,000 kb / 1 GB) * (1 document / 1 kb) * (10 RU / document) * (1 sec / 250,000 RU) * (1 hour / 3600 seconds) = 11.1 hours.

Perhitungan ini adalah perkiraan dengan asumsi klien yang melakukan ingesti dapat sepenuhnya menjenuhkan throughput dan mendistribusikan penulisan ke semua partisi fisik. Sebagai praktik terbaik, disarankan untuk mengacak data Anda di sisi klien. Ini memastikan bahwa setiap detik, klien menulis ke banyak partisi logis (dan dengan demikian fisik) yang berbeda.

Setelah migrasi selesai, Anda dapat menurunkan RU/dtk atau mengaktifkan skala otomatis sesuai kebutuhan.

Langkah berikutnya

  • Last updated on