Pemartisian dan penskalaan horizontal di Azure Cosmos DB

Azure Cosmos DB menggunakan partisi untuk menskalakan kontainer dalam database untuk memenuhi kebutuhan performa aplikasi Anda. Item dalam kontainer dibagi menjadi subset yang berbeda yang disebut partisi logis. Bentuk partisi logis 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.

Setiap item dalam kontainer memiliki kunci partisi yang menentukan partisi logis dan ID item yang unik dalam partisi tersebut. 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.

Nota

Dalam beberapa sistem database terdistribusi dan materi pembelajaran, istilah kunci shard digunakan untuk menjelaskan properti yang menentukan bagaimana data didistribusikan di seluruh pecahan. Di Azure Cosmos DB, konsep yang sama ini disebut kunci partisi.

Kedua istilah mengacu pada nilai yang digunakan untuk mendistribusikan dan menemukan data, tetapi kunci partisi adalah istilah resmi dan benar yang digunakan di seluruh dokumentasi dan API Azure Cosmos DB.

Artikel ini menjelaskan hubungan antara partisi logis dan fisik, membahas praktik terbaik untuk partisi, dan memberikan tampilan mendalam tentang cara kerja penskalaan horizontal di Azure Cosmos DB. Anda tidak perlu memahami detail internal ini untuk memilih kunci partisi Anda, tetapi artikel ini membahasnya untuk mengklarifikasi cara kerja Azure Cosmos DB.

Partisi logis

Partisi logis adalah sekumpulan item yang memiliki kunci partisi yang sama. Misalnya, dalam kontainer yang berisi data tentang nutrisi makanan, semua item memiliki properti foodGroup. Gunakan foodGroup sebagai kunci partisi untuk kontainer. 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. Setiap partisi logis dapat menyimpan hingga 20 GB data. Kunci partisi yang efektif memiliki berbagai nilai yang mungkin. 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.

Jika Anda memiliki skenario di mana kunci partisi dapat melebihi 20 GB data menggunakan kunci partisi hierarkis dapat membantu. Jika Anda menggunakan fitur ini, Anda dapat mengonfigurasi hingga hierarki tiga tingkat untuk kunci partisi Anda untuk lebih mengoptimalkan distribusi data dan untuk tingkat penskalaan yang lebih tinggi. Lihatgambaran umum kunci partisi hierarkis.

Gunakan Pemberitahuan Azure Monitor untuk memantau apakah ukuran partisi logis mendekati 20 GB.

Partisi fisik

Kontainer menskalakan dengan mendistribusikan data dan throughput di seluruh partisi fisik. Di dalamnya, satu atau lebih partisi logis terhubung ke satu partisi fisik. Biasanya, kontainer yang lebih kecil memiliki banyak partisi logis tetapi hanya memerlukan satu partisi fisik. Tidak seperti partisi logis, partisi fisik adalah implementasi sistem internal, dan Azure Cosmos DB sepenuhnya mengelolanya.

Jumlah partisi fisik dalam kontainer tergantung pada karakteristik ini:

• 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 gigabyte data).

Nota

Partisi fisik adalah implementasi sistem internal, dikelola sepenuhnya oleh Azure Cosmos DB. Saat mengembangkan solusi Anda, jangan berfokus pada partisi fisik, karena Anda tidak dapat mengontrolnya. Sebagai gantinya, fokus pada kunci partisi. Memilih kunci partisi yang secara merata mendistribusikan konsumsi throughput di seluruh partisi logis memastikan konsumsi throughput yang seimbang di seluruh partisi fisik.

Tidak ada batasan jumlah total partisi fisik dalam kontainer. 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 disediakan untuk sebuah kontainer dibagikan merata di antara partisi fisik. Desain kunci partisi yang tidak mendistribusikan permintaan secara merata dapat mengakibatkan terlalu banyak permintaan yang diarahkan ke subset kecil partisi yang menjadi "panas." Partisi panas menyebabkan penggunaan throughput yang disediakan yang tidak efisien, yang dapat mengakibatkan pembatasan tarif dan biaya yang lebih tinggi.

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 sebesar 18.000 unit permintaan per detik (RU/dtk), masing-masing dari tiga partisi fisik menggunakan sepertiga dari total throughput yang telah dialokasikan. 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 rata di seluruh partisi fisik kontainer Anda, penting untuk memilih kunci partisi yang dapat mendistribusikan konsumsi throughput secara seimbang. Untuk informasi selengkapnya, lihat Memilih kunci partisi logis yang tepat.

Mengelola partisi logis

Azure Cosmos DB secara otomatis mengelola penempatan partisi logis pada partisi fisik untuk memenuhi skalabilitas dan kebutuhan performa kontainer. Ketika persyaratan throughput dan penyimpanan aplikasi meningkat, Azure Cosmos DB memindahkan partisi logis untuk menyebarkan beban di lebih banyak partisi fisik. Pelajari selengkapnya tentang partisi fisik.

Azure Cosmos DB menggunakan partisi berbasis hash untuk mendistribusikan partisi logis di seluruh partisi fisik. Azure Cosmos DB menerapkan hash atas nilai kunci partisi suatu item. Hasil dari 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 tersimpan hanya diperbolehkan untuk item dalam satu partisi logis.

Set replika

Setiap partisi fisik terdiri dari satu set replika, juga disebut set replika. Setiap replika menyelenggarakan sebuah instance mesin database. Set replika membuat penyimpanan data dalam partisi fisik tahan lama, sangat tersedia, dan konsisten. Setiap replika dalam partisi fisik mewarisi kuota penyimpanan partisi. Semua replika partisi fisik secara kolektif mendukung throughput yang dialokasikan untuk partisi fisik tersebut. Azure Cosmos DB mengelola set replika secara otomatis.

Kontainer yang lebih kecil biasanya memerlukan satu partisi fisik, tetapi mereka masih memiliki setidaknya empat replika.

Gambar ini menunjukkan cara partisi logis dipetakan ke partisi fisik yang tersebar secara global. Set Partisi dalam gambar mengacu pada sekelompok partisi fisik yang mengelola kunci partisi logis yang sama di berbagai wilayah.

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 dapat 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.

Pelajari tentang batasan throughput, penyimpanan, dan panjang kunci partisi dalam artikel kuota layanan Azure Cosmos DB .

Memilih kunci partisi Anda merupakan pilihan desain yang sederhana tetapi penting di Azure Cosmos DB. Setelah memilih kunci partisi, Anda tidak dapat mengubahnya di tempat. Jika Anda perlu mengubah kunci partisi, pindahkan data Anda ke kontainer baru dengan kunci partisi yang Anda inginkan. Pekerjaan penyalinan kontainer membantu proses ini. Secara bergantian, Anda dapat menambahkan indeks sekunder global (pratinjau) untuk membuat salinan data Anda dengan kunci partisi yang berbeda yang dioptimalkan untuk pola kueri tertentu.

Untuk semua kontainer, kunci partisi harus:

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

• Hanya mengandung nilai String—atau konversikan angka menjadi String jika mungkin melebihi batas angka presisi ganda menurut standar Institute of Electrical and Electronics Engineers (IEEE) 754 format biner64. Spesifikasi Json menjelaskan mengapa menggunakan angka di luar batas ini adalah praktik yang buruk karena masalah interoperabilitas. Kekhawatiran ini sangat relevan untuk kolom kunci partisi karena tidak dapat diubah dan memerlukan migrasi data untuk berubah nanti.

• Memiliki tingkat 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.

Nota

Jika Anda hanya memiliki satu partisi fisik, atau jumlah partisi kecil, misalnya <= 5, nilai kunci partisi mungkin tidak relevan. Untuk kueri, overhead memeriksa setiap partisi fisik tambahan ketika kunci partisi tidak disertakan adalah 2-3 RU untuk setiap partisi fisik. Pelajari selengkapnya tentang partisi fisik.

Jenis kunci partisi

Strategi pemartisian	Kapan digunakan	Keuntungan	Kontra
Kunci Partisi Biasa (misalnya, CustomerId, OrderId)	Gunakan saat kunci partisi memiliki kardinalitas tinggi dan selaras dengan pola kueri (misalnya, pemfilteran menurut CustomerId). Cocok untuk beban kerja di mana kueri sebagian besar menargetkan satu data pelanggan (misalnya, mengambil semua pesanan untuk pelanggan).	Mudah dikelola. Kueri yang efisien saat pola akses cocok dengan kunci partisi (misalnya, mengkueri semua pesanan menurut CustomerId). Mencegah kueri lintas partisi jika pola akses konsisten.	Risiko terjadinya partisi panas jika beberapa nilai (misalnya, beberapa pelanggan dengan aktivitas tinggi) menghasilkan lebih banyak data daripada yang lain. Mungkin mencapai batas 20 GB per partisi logis jika volume data untuk kunci tertentu tumbuh dengan cepat.
Kunci Partisi Sintetis (misalnya, CustomerId + OrderDate)	Gunakan ketika tidak ada bidang tunggal yang memiliki kardinalitas tinggi dan cocok dengan pola kueri. Baik untuk beban kerja tulis-berat di mana data perlu didistribusikan secara merata di seluruh partisi fisik (misalnya, banyak pesanan yang ditempatkan pada tanggal yang sama).	Membantu mendistribusikan data secara merata di seluruh partisi, mengurangi terjadinya partisi yang terlalu aktif (misalnya, mendistribusikan pesanan berdasarkan CustomerId dan OrderDate). Menyebarluaskan penulisan di beberapa partisi dan meningkatkan throughput.	Kueri yang hanya memfilter berdasarkan satu bidang (misalnya, hanya CustomerId) dapat mengakibatkan kueri lintas partisi. Kueri lintas partisi dapat menyebabkan konsumsi RU yang lebih tinggi (biaya tambahan 2-3 RU/dtk untuk setiap partisi fisik yang ada) dan menyebabkan latensi tambahan.
Kunci Partisi Hierarkis (HPK) (misalnya, IdPelanggan/IdPesanan, IdToko/IdProduk)	Gunakan saat Anda memerlukan partisi multi-tingkat untuk mendukung himpunan data skala besar. Ideal ketika kueri memfilter pada tingkat pertama dan kedua hierarki.	Membantu menghindari batas 20 GB dengan membuat beberapa tingkat partisi. Kueri yang efisien pada kedua tingkat hierarki (misalnya, memfilter lebih dulu berdasarkan CustomerID, kemudian berdasarkan OrderID). Meminimalkan kueri lintas partisi untuk kueri yang menargetkan tingkat atas (misalnya, mengambil semua data dari CustomerID tertentu).	Memerlukan perencanaan yang cermat untuk memastikan kunci tingkat pertama memiliki kardinalitas tinggi dan disertakan dalam sebagian besar kueri. Lebih kompleks untuk dikelola daripada kunci partisi biasa. Jika kueri tidak selaras dengan hierarki (misalnya, pemfilteran hanya menurut OrderID saat CustomerID adalah tingkat pertama), performa kueri mungkin terpengaruh.
Indeks Sekunder Global (GSI) - pratinjau (misalnya, sumber menggunakan IdPelanggan, GSI menggunakan IdPesanan)	Gunakan saat Anda tidak dapat menemukan satu kunci partisi yang berfungsi untuk semua pola kueri. Ideal untuk beban kerja yang perlu dikueri oleh beberapa properti independen secara efisien dan memiliki sejumlah besar partisi fisik.	Menghilangkan kueri lintas partisi saat menggunakan kunci partisi GSI. Memungkinkan beberapa pola kueri pada data yang sama dengan sinkronisasi otomatis dari kontainer sumber. Isolasi performa antar beban kerja.	Setiap GSI memiliki biaya penyimpanan tambahan dan biaya RU. Data dalam GSI pada akhirnya konsisten dengan kontainer sumber.

Kunci partisi untuk kontainer yang banyak membaca

Untuk sebagian besar kontainer, kriteria ini 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. Termasuk kunci partisi dalam predikat filter memungkinkan kueri dirutekan secara efisien hanya ke partisi fisik yang relevan.

Properti ini adalah pilihan kunci partisi yang baik jika sebagian besar permintaan beban kerja Anda adalah kueri dan sebagian besar kueri Anda menggunakan 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.

Jika kontainer Anda kecil, Anda mungkin tidak memiliki partisi fisik yang cukup untuk 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 membutuhkan lebih dari beberapa partisi fisik jika salah satu skenario berikut ini benar:

• Kontainer Anda memiliki lebih dari 30.000 unit permintaan yang dipra-sediakan

• Kontainer Anda menyimpan lebih dari 100 GB data

Indeks sekunder global untuk kueri lintas partisi

Jika aplikasi Anda perlu mengkueri data menggunakan beberapa properti yang berbeda secara efisien, indeks sekunder global (pratinjau) menyediakan alternatif untuk menggunakan satu strategi kunci partisi untuk himpunan data. Indeks sekunder global adalah kontainer tambahan dengan kunci partisi yang berbeda, secara otomatis disinkronkan dengan data dari kontainer sumber Anda.

Pertimbangkan indeks sekunder global saat:

• Anda memiliki beberapa pola kueri yang tidak dapat dipenuhi oleh strategi kunci partisi tunggal
• Mengubah kunci partisi yang ada akan mengganggu
• Anda perlu mengisolasi beban kerja analitik atau pencarian dari operasi transaksional

Indeks sekunder global membantu menghindari kueri lintas partisi dengan menyimpan data yang sama dengan kunci partisi yang berbeda yang dioptimalkan untuk pola kueri tertentu. Pendekatan ini dapat secara signifikan mengurangi konsumsi RU dan meningkatkan performa kueri untuk skenario di mana pengoptimalan kunci partisi saja tidak cukup.

Menggunakan ID item sebagai kunci partisi

Nota

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 dengan berbagai nilai yang mungkin, itu kemungkinan merupakan pilihan kunci partisi yang baik. Contoh properti tersebut 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 ada di setiap item dalam kontainer Anda. Anda mungkin memiliki properti lain yang mewakili ID logis item Anda. Dalam banyak kasus, pengidentifikasi unik ini juga merupakan pilihan kunci partisi yang hebat 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.

Pertimbangkan peringatan berikut saat memilih ID item sebagai kunci partisi:

• Jika ID item adalah kunci partisi, id tersebut menjadi pengidentifikasi unik untuk seluruh kontainer Anda. Anda tidak dapat membuat item dengan pengidentifikasi duplikat.
• Jika Anda memiliki kontainer yang memprioritaskan pembacaan dengan banyak partisi fisik, kueri akan lebih efisien jika memiliki filter kesetaraan dengan ID item.
• Prosedur atau pemicu tersimpan tidak dapat menargetkan beberapa partisi logis.

Konten terkait

• Throughput yang disediakan di Azure Cosmos DB
• Distribusi global di Azure Cosmos DB
• Pelatihan: memodelkan dan mempartisi data Anda di Azure Cosmos DB