Share via

Praktik terbaik untuk menskalakan throughput yang disediakan (RU)

  • Artikel

BERLAKU UNTUK: Nosql MongoDB Cassandra Gremlin Meja

Artikel ini menjelaskan praktik dan strategi terbaik untuk meningkatkan throughput (RU) dari database atau kontainer Anda (kumpulan, tabel, atau grafik). Konsep ini berlaku saat Anda meningkatkan RU manual yang disediakan atau RU maks skala otomatis dari sumber daya apa pun untuk semua API Azure Cosmos DB.

Prasyarat

Latar belakang penskalaan RU

Ketika Anda mengirim permintaan untuk meningkatkan RU dari database atau kontainer Anda, tergantung pada RU yang Anda minta dan tata letak partisi fisik Anda saat ini, operasi peningkatan akan selesai secara instan atau asinkron (biasanya 4-6 jam).

  • Peningkatan 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 segera selesai dan RU tersedia untuk digunakan.
  • Peningkatan Asinkron
    • Ketika RU yang diminta lebih tinggi dari apa yang dapat didukung oleh tata letak partisi fisik, Azure Cosmos DB akan 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 maksimum 10.000 RU (berlaku untuk semua API) throughput dan 50 GB penyimpanan (berlaku untuk semua API, kecuali Cassandra, yang memiliki 30 GB penyimpanan).

Catatan

Jika Anda melakukan operasi failover wilayah manual atau menambahkan/menghapus wilayah baru saat operasi peningkatan skala asinkron sedang berlangsung, operasi peningkatan skala throughput akan dijeda. Operasi ini akan dilanjutkan secara otomatis ketika operasi failover atau tambahkan/hapus wilayah selesai.

  • Menurunkan skala secara instan
    • Untuk menurunkan skala operasi Azure Cosmos DB tidak perlu membagi atau menambahkan partisi baru.
    • Sebagai hasilnya, operasi segera selesai dan RU tersedia untuk digunakan.
    • Hasil utama dari operasi ini adalah bahwa RU per partisi fisik akan berkurang.

Cara meningkatkan RU tanpa mengubah tata letak partisi

Langkah 1: Temukan jumlah partisi fisik saat ini.

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

Hitung jumlah PartitionKeyRangeIds yang berbeda dalam bagan Konsumsi RU yang dinormalisasi (%) oleh PartitionKeyRangeID

Catatan

Bagan hanya akan menampilkan maksimal 50 PartitionKeyRangeIds. Jika sumber daya Anda memiliki lebih dari 50, Anda dapat menggunakan Azure Cosmos DB REST API untuk menghitung jumlah total partisi.

Setiap peta PartitionKeyRangeId ke satu partisi fisik dan ditugaskan untuk menyimpan data untuk berbagai nilai hash yang mungkin.

Azure Cosmos DB mendistribusikan data Anda di seluruh partisi logis dan fisik berdasarkan tombol 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 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.

Contoh

Misalnya, kita memiliki kontainer yang ada dengan lima partisi fisik dan 30.000 RU throughput yang disediakan manual. Kita dapat meningkatkan RU ke 5 * 10.000 RU = 50.000 RU langsung. 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 untuk menanggapi tingkat permintaan pengecualian terlalu besar (429s), disarankan untuk terlebih dahulu meningkatkan RU ke RU tertinggi yang didukung oleh tata letak partisi fisik Anda saat ini dan menilai apakah RU baru cukup sebelum meningkat lebih lanjut.

Cara memastikan distribusi data genap selama penskalaan asinkron

Latar belakang

Ketika Anda meningkatkan RU melebihi jumlah partisi fisik saat ini * 10.000 RU, Azure Cosmos DB membagi partisi yang ada, sampai jumlah partisi baru = ROUNDUP(requested RU/s / 10,000 RU/s). Selama pemisahan, partisi induk dibagi menjadi dua partisi anak.

Sebagai contoh, kita memiliki kontainer dengan tiga partisi fisik dan 30.000 RU throughput yang disediakan manual. Jika kita meningkatkan throughput menjadi 45.000 RU, Azure Cosmos DB akan membagi dua partisi fisik yang ada sehingga secara total, ada ROUNDUP(45,000 RU/s / 10,000 RU/s) = 5 partisi fisik.

Catatan

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 diarahkan ke partisi fisik yang benar, sehingga tidak diperlukan tindakan pengguna tambahan.

Jika Anda memiliki beban kerja yang sangat merata sehubungan dengan volume penyimpanan dan permintaan — biasanya dilakukan dengan partisi oleh bidang kardinalitas tinggi seperti /id—disarankan ketika Anda meningkatkan, atur RU sedemikian rupa sehingga semua partisi dibagi secara merata.

Untuk mengetahui alasannya, mari kita ambil contoh di mana kita memiliki kontainer yang sudah ada dengan 2 partisi fisik, 20.000 RU, 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 dan 50% (40 GB) dari total data. Diagram berikut menunjukkan keadaan kita saat ini.

Two PartitionKeyRangeIds, masing-masing dengan 10.000 RU, 40 GB, dan 50% dari total keyspace

Sekarang, misalkan kita ingin meningkatkan RU kita dari 20.000 RU menjadi 30.000 RU.

Jika kita hanya meningkatkan RU menjadi 30.000 RU, hanya satu dari partisi yang akan dibagi. Setelah perpecahan, kita akan memiliki:

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

Karena Azure Cosmos DB mendistribusikan RU secara merata di semua partisi fisik, setiap partisi fisik masih akan mendapatkan 10.000 RU. Namun, kita sekarang memiliki kecondongan dalam penyimpanan dan distribusi permintaan.

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

Setelah pemisahan, ada 3 PartitionKeyRangeIds, masing-masing dengan 10.000 RU. Namun, salah satu PartitionKeyRangeIds memiliki 50% dari total keyspace (40 GB), sementara dua dari PartitionKeyRangeIds memiliki 25% dari total keyspace (20 GB)

Untuk mempertahankan distribusi penyimpanan yang merata, pertama-tama kita dapat meningkatkan RU untuk memastikan setiap partisi terbagi. Kemudian, kita dapat menurunkan RU kita kembali ke keadaan yang diinginkan.

Jadi, jika kita mulai dengan dua partisi fisik, untuk menjamin bahwa partisi bahkan pasca-split, kita perlu mengatur RU sedemikian rupa sehingga kita akan berakhir dengan empat partisi fisik. Untuk mencapai hal ini, pertama-tama kita akan mengatur RU = 4 * 10.000 RU per partisi = 40.000 RU. Kemudian, setelah pemisahan selesai, kita dapat menurunkan RU menjadi 30.000 RU.

Sebagai hasilnya, kita melihat dalam diagram berikut bahwa setiap partisi fisik mendapat 30.000 RU / 4 = 7500 RU untuk melayani permintaan untuk 20 GB data. Secara keseluruhan, kita mempertahankan bahkan penyimpanan dan meminta distribusi di seluruh partisi.

Setelah pemisahan selesai dan RU telah diturunkan dari 40.000 RU menjadi 30.000 RU, ada 4 PartitionKeyRangeIds, masing-masing dengan 7500 RU dan 25% dari total keyspace (20 GB)

Rumus Umum

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

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

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

Catatan

Ketika Anda meningkatkan RU dari database atau kontainer, ini dapat mempengaruhi RU minimum Anda dapat menurunkan ke di masa depan. Biasanya, RU/dtk minimum sama dengan MAX(400 RU/dtk, Penyimpanan saat ini dalam GB * 1 RU/dtk, RU Tertinggi yang pernah disediakan/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 minimum.

Langkah 2: Turunkan RU Anda ke RU yang diinginkan

Sebagai contoh, misalkan kita memiliki lima partisi fisik, 50.000 RU dan ingin skala ke 150.000 RU. Pertama-tama kita harus menetapkan: 10,000 * 5 * (2 ^ (ROUND(LOG_2(150,000/(10,000 * 5)))) = 200.000 RU, lalu turunkan ke 150.000 RU.

Ketika kita meningkatkan hingga 200.000 RU, RU manual terendah yang sekarang dapat kita tetapkan selanjutnya adalah 2000 RU. Autoscale max RU terendah yang dapat kita atur adalah 20.000 RU (skala antara 2000 - 20.000 RU). Karena target RU kita adalah 150.000 RU, kita tidak terpengaruh oleh RU minimum.

Cara mengoptimalkan RU untuk konsumsi data besar

Saat Anda berencana untuk memigrasikan atau menyerap data dalam jumlah besar ke Azure Cosmos DB, disarankan untuk mengatur RU kontainer sehingga Azure Cosmos DB melakukan pra-penyediaan partisi fisik yang diperlukan untuk menyimpan jumlah total data yang Anda rencanakan untuk diserap di muka. Jika tidak, selama konsumsi, Azure Cosmos DB mungkin harus membagi partisi, yang menambah lebih banyak waktu untuk konsumsi data.

Kita dapat memanfaatkan fakta bahwa selama pembuatan kontainer, Azure Cosmos DB menggunakan rumus heuristik memulai RU untuk menghitung jumlah partisi fisik untuk memulai.

Langkah 1: Tinjau pilihan kunci partisi

Ikuti praktik terbaik untuk memilih kunci partisi untuk memastikan Anda bahkan memiliki distribusi volume permintaan dan penyimpanan pasca-migrasi.

Langkah 2: Hitung jumlah partisi fisik yang Anda perlukan

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 Target data per physical partition in GB tergantung pada seberapa penuh Anda ingin partisi fisik menjadi dan berapa banyak Anda mengharapkan penyimpanan tumbuh pasca-migrasi.

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

Sebaliknya, jika Anda yakin bahwa penyimpanan tidak akan tumbuh secara signifikan pasca-migrasi, Anda dapat memilih untuk menetapkan nilai yang lebih tinggi, misalnya 45 GB. Ini berarti setiap partisi akan ~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/dtk yang akan dimulai untuk semua partisi

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

Mari kita mulai dengan contoh dengan jumlah ru/dtk target per partisi fisik.

  • Initial throughput per physical partition = 10.000 RU/dtk per partisi fisik saat menggunakan database skala otomatis atau throughput bersama
  • Initial throughput per physical partition = 6000 RU/dtk per partisi fisik saat menggunakan throughput manual

Contoh

Anggap kita memiliki 1 TB (1000 GB) data yang kita rencanakan untuk dicerna dan kita ingin menggunakan throughput manual. Setiap partisi fisik di Azure Cosmos DB memiliki kapasitas 50 GB. Mari anggap tujuan kita adalah untuk mengemas partisi menjadi 80% penuh (40 GB), memberi kita ruang untuk pertumbuhan di masa mendatang.

Ini berarti bahwa untuk 1 TB data, kita akan membutuhkan 1000 GB / 40 GB = 25 partisi fisik. Untuk memastikan kita akan mendapatkan 25 partisi fisik, jika kita menggunakan throughput manual, pertama kita menyediakan 25 * 6000 RU = 150.000 RU. Kemudian, setelah kontainer dibuat, untuk membantu konsumsi kita berjalan lebih cepat, kita meningkatkan RU menjadi 250.000 RU sebelum konsumsi dimulai (terjadi langsung karena kita sudah memiliki 25 partisi fisik). Hal ini memungkinkan setiap partisi untuk mendapatkan maksimum 10.000 RU.

Jika kita menggunakan throughput skala otomatis atau database throughput bersama, untuk mendapatkan 25 partisi fisik, pertama-tama kita akan menyediakan 25 * 10.000 RU = 250.000 RU. Karena kita sudah berada di RU tertinggi yang dapat didukung dengan 25 partisi fisik, kita tidak akan lebih meningkatkan RU yang kita sediakan sebelum penggunaan.

Secara teori, dengan 250.000 RU dan 1 TB data, jika kita mengasumsikan dokumen 1-kb dan 10 RU yang diperlukan untuk menulis, konsumsi secara teoritis dapat menyelesaikan dalam: 1000 GB * (1.000.000 kb / 1 GB) * (1 dokumen / 1 kb) * (10 RU / dokumen) * (1 detik / 250.000 RU) * (1 jam / 3600 detik) = 11,1 jam.

Perhitungan ini adalah perkiraan dengan asumsi klien yang melakukan konsumsi dapat sepenuhnya menjenuhkan throughput dan mendistribusikan menulis di 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, kita dapat menurunkan RU atau mengaktifkan skala otomatis sesuai kebutuhan.

Langkah berikutnya