Pemartisian dan penskalaan horizontal di Azure Cosmos DB

BERLAKU UNTUK: SQL API Cassandra API Gremlin API Table API Azure Cosmos DB API untuk MongoDB

Azure Cosmos DB menggunakan pemartisian untuk menskalakan masing-masing kontainer dalam database untuk memenuhi kebutuhan performa aplikasi Anda. Dalam pemartisian, item dalam kontainer dibagi menjadi beberapa subset yang berbeda, yang disebut partisi logis. Partisi logis dibentuk berdasarkan nilai kunci partisi yang terkait dengan setiap item dalam kontainer. Semua item dalam partisi logis memiliki nilai kunci partisi yang sama.

Misalnya, kontainer menyimpan beberapa item. Setiap item memiliki nilai unik untuk properti UserID. Jika UserID berfungsi sebagai kunci partisi untuk item dalam kontainer dan ada 1.000 nilai UserID yang unik, maka 1.000 partisi logis dibuat untuk kontainer tersebut.

Selain kunci partisi yang menentukan partisi logis item, setiap item dalam wadah memiliki ID item (unik dalam partisi logis). Menggabungkan kunci partisi dan ID item akan menghasilkan indeks item, yang secara unik mengidentifikasi item tersebut. Memilih kunci partisi merupakan keputusan penting yang akan memengaruhi performa aplikasi Anda.

Artikel ini menjelaskan hubungan antara partisi logis dan partisi fisik. Artikel ini juga membahas praktik terbaik untuk pemartisian dan memberikan ulasan mendalam tentang cara kerja penskalaan horizontal di Azure Cosmos DB. Anda tidak perlu memahami detail internal ini untuk memilih kunci partisi Anda, tetapi kami membahasnya agar Anda memiliki kejelasan tentang cara kerja Azure Cosmos DB.

Partisi logis

Partisi logis terdiri dari satu set item yang memiliki kunci partisi yang sama. Misalnya, dalam kontainer yang berisi data tentang nutrisi makanan, semua item memiliki properti foodGroup. Anda dapat menggunakan foodGroup sebagai kunci partisi untuk kontainer tersebut. Grup item yang memiliki nilai khusus untuk foodGroup, misalnya Beef Products, Baked Products, dan Sausages and Luncheon Meats, membentuk partisi logis yang berbeda.

Partisi logis juga menentukan cakupan transaksi database. Anda dapat memperbarui item dalam partisi logis dengan menggunakan transaksi dengan isolasi rekam jepret. Ketika item baru ditambahkan ke kontainer, partisi logis baru dibuat secara transparan oleh sistem. Anda tidak perlu khawatir tentang menghapus partisi logis ketika data yang mendasarinya dihapus.

Tidak ada batasan untuk jumlah partisi logis dalam kontainer Anda. Setiap partisi logis dapat menyimpan data hingga 20GB. Pilihan kunci partisi yang baik memiliki banyak nilai yang memungkinkan. Misalnya, dalam kontainer tempat semua item memuat properti foodGroup, data dalam partisi logis Beef Products bisa mencapai 20 GB. Memilih kunci partisi dengan banyak nilai yang memungkinkan akan memastikan bahwa kontainer tersebut mampu diskalakan.

Partisi fisik

Kontainer diskalakan dengan cara mendistribusikan data dan throughput di seluruh partisi fisik. Secara internal, satu partisi logis atau lebih dipetakan ke partisi fisik tunggal. Biasanya, kontainer yang lebih kecil memiliki banyak partisi logis, tetapi hanya memerlukan satu partisi fisik. Tidak seperti partisi logis, partisi fisik merupakan implementasi internal dalam sistem dan sepenuhnya dikelola oleh Azure Cosmos DB.

Jumlah partisi fisik dalam kontainer Anda tergantung pada hal-hal berikut:

  • Jumlah throughput yang tersedia (setiap partisi fisik individu dapat menghasilkan throughput hingga 10.000 unit permintaan per detik). Batas 10.000 RU/dtk untuk partisi fisik menyiratkan bahwa partisi logis juga memiliki batas 10.000 RU/dtk, karena setiap partisi logis hanya dipetakan ke satu partisi fisik.

  • Total penyimpanan data (setiap partisi fisik individu dapat menyimpan data hingga 50GB).

Catatan

Partisi fisik merupakan implementasi internal dalam sistem dan sepenuhnya dikelola oleh Azure Cosmos DB. Saat mengembangkan solusi Anda, jangan berfokus pada partisi fisik, karena Anda tidak dapat mengontrolnya. Sebaliknya, fokuslah pada kunci partisi Anda. Jika Anda memilih kunci partisi yang secara merata mendistribusikan konsumsi throughput di seluruh partisi logis, Anda bisa memastikan bahwa konsumsi throughput di seluruh partisi fisik seimbang.

Tidak ada batasan untuk jumlah partisi fisik total dalam kontainer Anda. Seiring dengan bertambahnya ukuran throughput atau data yang tersedia, Azure Cosmos DB akan secara otomatis membuat partisi fisik baru dengan memisahkan yang sudah ada. Pemisahan partisi fisik tidak berpengaruh atas ketersediaan aplikasi Anda. Setelah pemisahan partisi fisik, semua data dalam satu partisi logis akan tetap disimpan pada partisi fisik yang sama. Pemisahan partisi fisik hanya menciptakan pemetaan baru dari partisi logis ke partisi fisik.

Throughput yang tersedia untuk kontainer dibagi secara merata di antara partisi fisik. Desain kunci partisi yang tidak mendistribusikan permintaan secara merata dapat mengakibatkan adanya terlalu banyak permintaan yang diarahkan ke subset kecil partisi yang menjadi "panas." Partisi panas menyebabkan penggunaan yang tidak efisien atas throughput yang tersedia, yang dapat mengakibatkan pembatasan tarif dan biaya yang lebih tinggi.

Anda dapat melihat partisi fisik kontainer di bagian Penyimpanan pada bilah Metrik portal Microsoft Azure:

Melihat jumlah partisi fisik

Dalam cuplikan layar di atas, kontainer memiliki /foodGroup sebagai kunci partisi. Masing-masing dari ketiga batang dalam grafik mewakili partisi fisik. Dalam gambar, rentang kunci partisi sama dengan partisi fisik. Partisi fisik yang dipilih memuat 3 partisi logis berukuran paling signifikan: Beef Products, Vegetable and Vegetable Products, dan Soups, Sauces, and Gravies.

Jika Anda menyediakan throughput 18.000 unit permintaan per detik (RU/dtk), maka masing-masing dari tiga partisi fisik tersebut dapat menggunakan 1/3 dari total throughput yang tersedia. Dalam partisi fisik yang dipilih, kunci partisi logis Beef Products, Vegetable and Vegetable Products, dan Soups, Sauces, and Gravies secara kolektif dapat menggunakan partisi fisik 6.000 RU/dtk yang tersedia. Karena throughput yang tersedia dibagi secara merata di seluruh partisi fisik kontainer Anda, penting untuk memilih kunci partisi yang membagi rata konsumsi throughput dengan memilih kunci partisi logis yang tepat.

Mengelola partisi logis

Azure Cosmos DB secara transparan dan otomatis mengelola penempatan partisi logis pada partisi fisik untuk memenuhi kebutuhan skalabilitas dan performa dari kontainer secara efisien. Seiring dengan meningkatnya persyaratan throughput dan penyimpanan dari suatu aplikasi, Azure Cosmos DB memindahkan partisi logis untuk menyebarkan beban ke lebih banyak partisi fisik secara otomatis. Anda dapat belajar lebih lanjut tentang partisi fisik.

Azure Cosmos DB menggunakan pemartisian berbasis hash untuk menyebarkan partisi logis di seluruh partisi fisik. Azure Cosmos DB menerapkan hash atas nilai kunci partisi suatu item. Hasil hash menentukan partisi fisiknya. Kemudian, Azure Cosmos DB mengalokasikan ruang kunci dari hash kunci partisi secara merata di seluruh partisi fisik.

Transaksi (dalam prosedur atau pemicu yang tersimpan) bisa dilakukan hanya terhadap item dalam satu partisi logis.

Set replika

Setiap partisi fisik terdiri dari satu set replika, yang disebut sebagai set replika. Setiap set replika meng-hosting satu instans mesin database. Set replika membuat data yang disimpan dalam partisi fisik tahan lama, tersedia dalam jumlah yang banyak, dan konsisten. Setiap replika yang membentuk partisi fisik mewarisi kuota penyimpanan partisi tersebut. Semua replika dari satu partisi fisik secara kolektif mendukung throughput yang dialokasikan untuk partisi fisik tersebut. Azure Cosmos DB mengelola set replika secara otomatis.

Biasanya, kontainer yang lebih kecil hanya memerlukan partisi fisik tunggal, tetapi tetap memiliki minimal 4 replika.

Gambar berikut menunjukkan cara partisi logis dipetakan ke partisi fisik yang didistribusikan secara global. Partisi yang diatur dalam gambar mengacu pada sekelompok partisi fisik yang mengelola tombol partisi logis yang sama di beberapa wilayah:

Gambar yang menunjukkan pemartisian Azure Cosmos DB

Memilih kunci partisi

Kunci partisi memiliki dua komponen: jalur kunci partisi dan nilai kunci partisi. Misalnya, pertimbangkan item { "userId" : "Andrew", "worksFor": "Microsoft" } jika Anda memilih "userId" sebagai kunci partisi, berikut adalah dua komponen kunci partisi:

  • Jalur kunci partisi (misalnya: "/userId"). Jalur kunci partisi menerima karakter alfanumerik dan garis bawah(_). Anda juga dapat menggunakan objek berlapis dengan menggunakan notasi jalur standar(/).

  • Nilai kunci partisi (misalnya: "Andrew"). Nilai kunci partisi dapat berupa jenis string atau jenis numerik.

Untuk mempelajari tentang batasan throughput, penyimpanan, dan panjang kunci partisi, lihat artikel kuota layanan Azure Cosmos DB.

Memilih kunci partisi Anda merupakan pilihan desain yang sederhana tetapi penting di Azure Cosmos DB. Setelah Anda memilih kunci partisi, Anda tidak bisa mengubahnya di tempat. Jika Anda perlu mengubah kunci partisi, Anda harus memindahkan data Anda ke kontainer baru dengan kunci partisi baru yang Anda inginkan.

Untuk semua kontainer, kunci partisi Anda harus:

  • Merupakan properti dengan nilai yang tidak berubah. Jika properti adalah kunci partisi Anda, Anda tidak dapat memperbarui nilai properti tersebut.

  • Memiliki kardinalitas tinggi. Dengan kata lain, properti tersebut harus memiliki banyak nilai yang memungkinkan.

  • Menyebarkan konsumsi unit permintaan (RU) dan penyimpanan data secara merata di seluruh partisi logis. Ini memastikan konsumsi RU dan distribusi penyimpanan yang merata di seluruh partisi fisik Anda.

Jika Anda memerlukan transaksi ACID multi-item di Azure Cosmos DB, Anda harus menggunakan prosedur atau pemicu tersimpan. Semua prosedur dan pemicu tersimpan berbasis JavaScript dicakup ke satu partisi logis.

Kunci partisi untuk kontainer read-heavy

Untuk sebagian besar kontainer, kriteria di atas adalah satu-satunya hal yang perlu Anda pertimbangkan saat memilih kunci partisi. Namun, untuk kontainer read-heavy yang besar, Anda mungkin ingin memilih kunci partisi yang sering muncul sebagai filter dalam kueri Anda. Kueri dapat dirutekan secara efisien ke partisi fisik yang relevan saja dengan menyertakan kunci partisi dalam predikat filter.

Jika sebagian besar permintaan beban kerja Anda adalah kueri, dan sebagian besar kueri Anda memiliki filter kesetaraan pada properti yang sama, properti ini bisa menjadi pilihan kunci partisi yang baik. Misalnya, jika Anda sering menjalankan kueri yang memfilter UserID, maka memilih UserID sebagai kunci partisi akan mengurangi jumlah kueri lintas-partisi.

Namun, jika kontainer Anda kecil, Anda mungkin tidak memiliki cukup partisi fisik yang perlu dikhawatirkan tentang dampak performa kueri lintas partisi. Sebagian besar kontainer kecil di Azure Cosmos DB hanya memerlukan satu atau dua partisi fisik.

Jika kontainer Anda dapat berkembang hingga lebih dari beberapa partisi fisik, maka Anda harus memastikan bahwa Anda memilih kunci partisi yang meminimalkan kueri lintas partisi. Kontainer Anda akan memerlukan lebih dari beberapa partisi fisik ketika salah satu dari yang berikut ini terjadi:

  • Kontainer Anda akan memiliki lebih dari 30.000 RU yang tersedia

  • Kontainer Anda akan menyimpan data lebih dari 100 GB

Menggunakan ID item sebagai kunci partisi

Jika kontainer Anda memiliki properti yang memiliki banyak nilai yang mungkin, kemungkinan itu merupakan pilihan kunci partisi yang bagus. Salah satu contoh properti seperti di atas adalah ID item. Untuk kontainer read-heavy kecil atau kontainer write-heavy dalam berbagai ukuran, ID item secara alami merupakan pilihan yang bagus untuk kunci partisi.

ID item properti sistem tersedia pada setiap item dalam kontainer Anda. Anda mungkin memiliki berbagai properti lain yang mewakili ID logis item Anda. Sering kali, ini juga merupakan pilihan kunci partisi yang bagus untuk alasan yang sama seperti ID item.

ID item adalah pilihan kunci partisi yang bagus untuk alasan berikut:

  • Ada banyak nilai yang memungkinkan (satu ID item unik per item).
  • Karena ada ID item unik per item, ID item berfungsi dengan sangat baik dalam menyeimbangkan konsumsi RU dan penyimpanan data secara merata.
  • Anda dapat dengan mudah melakukan pembacaan titik secara efisien karena Anda akan selalu mengetahui kunci partisi suatu item jika Anda tahu ID item-nya.

Beberapa hal yang perlu dipertimbangkan saat memilih ID item sebagai kunci partisi antara lain:

  • Jika ID item adalah kunci partisi, itu akan menjadi pengidentifikasi unik di seluruh kontainer Anda. Anda tidak akan bisa memiliki item yang memiliki ID item duplikat.
  • Jika Anda memiliki kontainer read-heavy yang memiliki banyak partisi fisik, kueri akan lebih efisien jika mereka memiliki filter kesetaraan dengan ID item.
  • Anda tidak dapat menjalankan prosedur atau pemicu yang tersimpan di beberapa partisi logis.

Langkah berikutnya