Pemartisian dan penskalaan horizontal di Azure Cosmos DB

  • Artikel

BERLAKU UNTUK: Nosql MongoDB Cassandra Gremlin Meja

Azure Cosmos DB menggunakan pemartisian untuk menskalakan masing-masing kontainer dalam database untuk memenuhi kebutuhan performa aplikasi Anda. Item dalam kontainer dibagi menjadi subset yang berbeda yang disebut partisi logis. Partisi logis dibentuk berdasarkan nilai kunci partisi yang dikaitkan 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 adalah keputusan penting yang 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. Tidak perlu memahami detail internal ini untuk memilih kunci partisi Anda tetapi kami membahasnya sehingga Anda dapat 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. Saat item baru ditambahkan ke kontainer, sistem secara transparan membuat partisi logis baru. Anda tidak perlu khawatir tentang menghapus partisi logis ketika data yang mendasarinya dihapus.

Tidak ada batasan jumlah partisi logis dalam kontainer Anda. Setiap partisi logis dapat menyimpan hingga 20 GB data. 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.

Anda dapat menggunakan Peringatan Azure Monitor untuk memantau apakah ukuran partisi logis mendekati 20 GB.

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 adalah implementasi internal sistem dan Azure Cosmos DB sepenuhnya mengelola partisi fisik.

Jumlah partisi fisik dalam kontainer Anda tergantung pada karakteristik 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 hingga 50 GB data).

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 jumlah total partisi fisik dalam kontainer Anda. Seiring bertambahnya throughput atau ukuran data yang disediakan, Azure Cosmos DB secara otomatis membuat partisi fisik baru dengan memisahkan yang sudah ada. Pemisahan partisi fisik tidak memengaruhi 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 mungkin menghasilkan terlalu banyak permintaan yang diarahkan ke subset kecil partisi yang menjadi "panas." Partisi panas mengarah pada penggunaan throughput yang diprovisikan dengan cara yang tidak efisien, yang mungkin menghasilkan pembatasan tingkat dan biaya yang lebih tinggi.

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

Screenshot of Azure Cosmos DB classic metrics displaying the number of physical partitions.

Misalnya, pertimbangkan kontainer dengan jalur /foodGroup yang ditentukan sebagai kunci partisi. Kontainer dapat memiliki sejumlah partisi fisik, tetapi dalam contoh ini kami menganggapnya memiliki tiga. Partisi fisik tunggal dapat berisi beberapa kunci partisi. Sebagai contoh, partisi fisik terbesar dapat berisi tiga partisi logis ukuran paling signifikan: Beef Products, , Vegetable and Vegetable Productsdan Soups, Sauces, and Gravies.

Jika Anda menetapkan throughput 18.000 unit permintaan per detik (RU/dtk), maka masing-masing dari tiga partisi fisik dapat menggunakan 1/3 dari total throughput yang disediakan. 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 disediakan dibagi secara merata di seluruh partisi fisik kontainer Anda, penting untuk memilih kunci partisi yang secara merata mendistribusikan konsumsi throughput. Untuk informasi selengkapnya, lihat 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 logis. 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.

Rangkaian replika

Setiap partisi fisik terdiri dari satu set replika, yang disebut sebagai set replika. Setiap replika meng-hosting satu instans mesin database. Set replika membuat penyimpanan data dalam partisi fisik tahan lama, sangat tersedia, 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 satu partisi fisik, tetapi masih memiliki setidaknya empat 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:

An image that demonstrates Azure Cosmos DB partitioning

Pilih tombol partisi

Kunci partisi memiliki dua komponen: jalur kunci partisi dan nilai kunci partisi. Misalnya, pertimbangkan bahwa item { "userId" : "Andrew", "worksFor": "Microsoft" } jika Anda memilih "userId" sebagai kunci partisi, dan berikut ini 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, tidak dimungkinkan untuk mengubahnya di tempat. Jika Anda perlu mengubah kunci partisi, Anda harus memindahkan data Anda ke kontainer baru dengan kunci partisi baru yang Anda inginkan. (Pekerjaan salinan kontainer membantu proses ini.)

Untuk semua kontainer, kunci partisi Anda harus:

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

  • Hanya boleh berisi String nilai - atau angka idealnya harus dikonversi menjadi String, jika ada kemungkinan bahwa nilai tersebut berada di luar batas angka presisi ganda sesuai dengan IEEE 754 binary64. Spesifikasi Json menyebutkan alasan mengapa menggunakan nomor di luar batas ini secara umum merupakan praktik yang buruk karena kemungkinan masalah interoperabilitas. Kekhawatiran ini sangat relevan untuk kolom kunci partisi, karena tidak dapat diubah dan memerlukan migrasi data untuk mengubahnya nanti.

  • Memiliki kardinalitas yang 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. Penyebaran ini memastikan penggunaan RU dan distribusi penyimpanan yang merata di seluruh partisi fisik Anda.

  • Memiliki nilai yang tidak lebih besar dari 2048 byte biasanya, atau 101 byte jika kunci partisi besar tidak diaktifkan. Untuk informasi selengkapnya, lihat kunci partisi besar

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

Catatan

Jika Anda hanya memiliki satu partisi fisik, nilai kunci partisi mungkin tidak relevan karena semua kueri akan menargetkan partisi fisik yang sama.

Kunci partisi untuk kontainer read-heavy

Untuk sebagian besar kontainer, kriteria di atas adalah semua 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.

Properti ini bisa menjadi pilihan kunci partisi yang baik jika sebagian besar permintaan beban kerja Anda adalah kueri dan sebagian besar kueri Anda memiliki filter kesetaraan pada properti yang sama. 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 partisi fisik yang cukup untuk perlu khawatir tentang 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 memerlukan lebih dari beberapa partisi fisik ketika salah satu dari yang berikut ini benar:

  • Kontainer Anda memiliki lebih dari 30.000 RU yang disediakan

  • Kontainer Anda menyimpan lebih dari 100 GB data

Menggunakan ID item sebagai kunci partisi

Catatan

Bagian ini terutama berlaku untuk API untuk NoSQL. API lain, seperti API untuk Gremlin, tidak mendukung pengidentifikasi unik sebagai kunci partisi.

Jika kontainer Anda memiliki properti yang memiliki berbagai nilai yang mungkin, kemungkinan itu adalah pilihan kunci partisi yang bagus. Salah satu contoh properti seperti di atas adalah ID item. Untuk kontainer baca-berat kecil atau kontainer tulis-berat dengan ukuran apa pun, ID item (/id) secara alami merupakan pilihan yang bagus untuk kunci partisi.

ID item properti sistem tersedia pada setiap item dalam kontainer Anda. Anda mungkin memiliki properti lain yang mewakili ID logis item Anda. Dalam banyak kasus, ID ini juga merupakan pilihan kunci partisi yang bagus karena alasan yang sama dengan 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 melakukan pekerjaan yang bagus dalam menyeimbangkan konsumsi RU dan penyimpanan data secara merata.
  • Anda dapat dengan mudah melakukan pembacaan titik yang efisien karena Anda selalu tahu kunci partisi item jika Anda mengetahui ID itemnya.

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

  • Jika ID item adalah kunci partisi, id tersebut menjadi pengidentifikasi unik di seluruh kontainer Anda. Anda tidak dapat membuat item yang memiliki ID item duplikat.
  • Jika Anda memiliki kontainer baca-berat dengan banyak partisi fisik, kueri lebih efisien jika memiliki filter kesetaraan dengan ID item.
  • Anda tidak dapat menjalankan prosedur tersimpan atau pemicu yang menargetkan beberapa partisi logis.

Langkah berikutnya