Kebijakan pengindeksan di Azure Cosmos DB

BERLAKU UNTUK: NoSQL

Di Azure Cosmos DB, setiap kontainer memiliki kebijakan pengindeksan yang menentukan cara item kontainer harus diindeks. Kebijakan pengindeksan default untuk kontainer yang baru dibuat akan mengindeks setiap properti dari setiap item dan memberlakukan indeks rentang untuk string atau angka apa pun. Dengan demikian, Anda akan mendapatkan performa kueri yang tinggi tanpa harus memikirkan pengindeksan dan pengelolaan indeks di awal.

Dalam beberapa situasi, Anda mungkin ingin mengambil alih perilaku otomatis ini agar lebih sesuai dengan kebutuhan Anda. Anda dapat menyesuaikan kebijakan pengindeksan kontainer dengan mengatur mode pengindeksannya, dan menyertakan atau mengecualikan jalur properti.

Catatan

Metode memperbarui kebijakan pengindeksan yang dijelaskan dalam artikel ini hanya berlaku untuk API Azure Cosmos DB untuk NoSQL. Pelajari cara membuat indeks di API Azure Cosmos DB untuk MongoDB

Mode pengindeksan

Azure Cosmos DB mendukung dua mode pengindeksan:

• Konsisten: Indeks diperbarui secara sinkron saat Anda membuat, memperbarui, atau menghapus item. Ini berarti bahwa konsistensi kueri baca Anda akan menjadi konsistensi yang dikonfigurasi untuk akun.
• Tidak ada: Pengindeksan pada kontainer dinonaktifkan. Mode ini umumnya digunakan ketika kontainer digunakan sebagai penyimpanan kunci-nilai murni tanpa perlu indeks sekunder. Ini juga dapat digunakan untuk meningkatkan performa operasi massal. Setelah operasi massal selesai, mode indeks dapat diatur ke Konsisten lalu dipantau menggunakan IndexTransformationProgress hingga selesai.

Catatan

Azure Cosmos DB juga mendukung mode pengindeksan Malas. Pengindeksan malas melakukan pembaruan indeks pada tingkat prioritas yang jauh lebih rendah, saat komputer tidak melakukan pekerjaan lain. Ini dapat menghasilkan kueri yang tidak konsisten atau tidak lengkap. Jika Anda berencana untuk mengkueri kontainer Azure Cosmos DB, Anda tidak boleh memilih pengindeksan malas. Kontainer baru tidak dapat memilih pengindeksan malas. Anda dapat meminta pengecualian dengan menghubungi cosmosdbindexing@microsoft.com (kecuali jika Anda menggunakan akun Azure Cosmos DB dalam mode tanpa server yang tidak mendukung pengindeksan malas).

Secara default, kebijakan pengindeksan diatur ke automatic. Hal ini dicapai dengan menetapkan automatic properti dalam kebijakan pengindeksan ke true. Mengatur properti ini untuk true memungkinkan Azure Cosmos DB mengindeks item secara otomatis saat ditulis.

Ukuran indeks

Di Azure Cosmos DB, total penyimpanan yang digunakan adalah kombinasi dari ukuran Data dan ukuran Indeks. Berikut ini adalah beberapa fitur ukuran indeks:

• Ukuran indeks tergantung pada kebijakan pengindeksan. Jika semua properti diindeks, maka ukuran indeks bisa lebih besar dari ukuran data.
• Saat data dihapus, indeks dipadatkan hampir terus-menerus. Namun, untuk penghapusan data kecil, Anda mungkin tidak segera mengamati penurunan ukuran indeks.
• Ukuran Indeks dapat bertambah sementara saat partisi fisik terbagi. Ruang indeks dilepaskan setelah pembagian partisi selesai.

Mencakup dan mengecualikan jalur properti

Kebijakan pengindeksan kustom dapat menentukan jalur properti yang secara eksplisit disertakan atau dikecualikan dari pengindeksan. Dengan mengoptimalkan jumlah jalur yang diindeks, Anda dapat secara substansial mengurangi latensi dan biaya operasi tulis RU. Jalur ini didefinisikan mengikuti metode yang dijelaskan di bagian gambaran umum pengindeksan dengan penambahan berikut:

• jalur yang mengarah ke nilai skalar (string atau angka) diakhiri dengan /?
• elemen dari sebuah array dialamatkan bersama melalui /[] notasi (bukan /0, /1 dll.)
• /*kartubebas dapat digunakan untuk mencocokkan elemen apa pun di bawah simpul

Mengambil contoh yang sama lagi:

    {
        "locations": [
            { "country": "Germany", "city": "Berlin" },
            { "country": "France", "city": "Paris" }
        ],
        "headquarters": { "country": "Belgium", "employees": 250 },
        "exports": [
            { "city": "Moscow" },
            { "city": "Athens" }
        ]
    }

• headquarters‘s employees jalur adalah /headquarters/employees/?

• locations‘ country jalur adalah /locations/[]/country/?

• jalur menuju apa pun yang ada di bawah headquarters adalah /headquarters/*

Misalnya, kita bisa menyertakan /headquarters/employees/? jalur. Jalur ini akan memastikan bahwa kami mengindeks employees properti tetapi tidak akan mengindeks JSON berlapis tambahan dalam properti ini.

Menyertakan/mengecualikan strategi

Setiap kebijakan pengindeksan harus menyertakan jalur akar /* sebagai jalur yang disertakan atau dikecualikan.

• Sertakan jalur akar untuk secara selektif mengecualikan jalur yang tidak perlu diindeks. Pendekatan ini direkomendasikan karena memungkinkan Azure Cosmos DB secara proaktif mengindeks properti baru apa pun yang mungkin ditambahkan ke model Anda.

• Sertakan jalur akar untuk secara selektif menyertakan jalur yang perlu diindeks. Jalur properti kunci partisi tidak diindeks secara default dengan strategi pengecualian dan harus disertakan secara eksplisit jika diperlukan.

• Untuk jalur dengan karakter reguler yang mencakup: alfanumerik dan _ (garis bawah), Anda tidak perlu melepaskan string jalur di sekitar tanda kutip ganda (misalnya, "/path/?"). Untuk jalur dengan karakter khusus lainnya, Anda perlu melepaskan string jalur di sekitar tanda kutip ganda (misalnya, "/"path-abc"/?"). Jika Anda mengharapkan karakter khusus di jalur Anda, Anda dapat melepaskan setiap jalur agar aman. Secara fungsional, itu tidak membuat perbedaan jika Anda keluar dari setiap jalur atau hanya yang memiliki karakter khusus.

• Properti sistem _etag dikecualikan dari pengindeksan secara default, kecuali etag ditambahkan ke jalur yang disertakan untuk pengindeksan.

• Jika mode pengindeksan diatur ke konsisten, properti sistem id dan _ts secara otomatis diindeks.

• Jika jalur yang diindeks secara eksplisit tidak ada dalam item, nilai ditambahkan ke indeks untuk menunjukkan bahwa jalur tidak ditentukan.

Semua jalur yang disertakan secara eksplisit memiliki nilai yang ditambahkan ke indeks untuk setiap item dalam kontainer, bahkan jika jalur tidak ditentukan untuk item tertentu.

Lihat bagian ini untuk contoh kebijakan pengindeksan untuk menyertakan dan mengecualikan jalur.

Menyertakan/mengecualikan prioritas

Jika jalur yang Anda sertakan dan jalur yang dikecualikan memiliki konflik, jalur yang lebih tepat lebih diutamakan.

Berikut contohnya:

Jalur yang Disertakan: /food/ingredients/nutrition/*

Jalur yang Dikecualikan: /food/ingredients/*

Dalam hal ini, jalur yang disertakan lebih diutamakan daripada jalur yang dikecualikan karena lebih tepat. Berdasarkan jalur ini, data apa pun di food/ingredients jalur atau yang bertumpuk di dalamnya akan dikecualikan dari indeks. Pengecualian akan menjadi data dalam jalur yang disertakan: /food/ingredients/nutrition/*, yang akan diindeks.

Berikut adalah beberapa aturan untuk prioritas jalur yang disertakan dan dikecualikan dalam Azure Cosmos DB:

• Jalur yang lebih dalam lebih tepat dibandingkan jalur yang lebih sempit. misalnya: /a/b/? lebih tepat dibandingkan /a/?.

• /? Lebih tepat dibandingkan /*. Misalnya /a/? lebih tepat dibandingkan /a/* jadi /a/? menentukan prioritas.

• Jalur /* harus berupa jalur yang disertakan atau jalur yang dikecualikan.

Indeks vektor

Catatan

Anda harus mendaftar di fitur pratinjau Indeks Vektor NoSQL Azure Cosmos DB untuk menentukan kebijakan pengindeksan vektor.>

Indeks vektor meningkatkan efisiensi saat melakukan pencarian vektor menggunakan VectorDistance fungsi sistem. Pencarian vektor memiliki latensi yang lebih rendah, throughput yang lebih tinggi, dan konsumsi RU yang lebih sedikit saat menerapkan indeks vektor. Anda dapat menentukan jenis kebijakan indeks vektor berikut:

Tipe	Deskripsi	Dimensi maks
flat	Menyimpan vektor pada indeks yang sama dengan properti terindeks lainnya.	505
quantizedFlat	Mengukur (mengompresi) vektor sebelum menyimpan pada indeks. Ini dapat meningkatkan latensi dan throughput dengan biaya akurasi dalam jumlah kecil.	4096
diskANN	Membuat indeks berdasarkan DiskANN untuk perkiraan pencarian yang cepat dan efisien.	4096

Beberapa poin yang perlu diperhatikan:

• Jenis flat indeks dan quantizedFlat menerapkan indeks Azure Cosmos DB untuk menyimpan dan membaca setiap vektor saat melakukan pencarian vektor. Pencarian vektor dengan flat indeks adalah pencarian brute-force dan menghasilkan akurasi atau pengenalan 100%. Artinya, dijamin untuk menemukan vektor yang paling mirip dalam himpunan data. Namun, ada batasan 505 dimensi untuk vektor pada indeks datar.

• Indeks quantizedFlat menyimpan vektor kuantisasi (terkompresi) pada indeks. Pencarian vektor dengan quantizedFlat indeks juga merupakan pencarian brute-force, namun akurasinya mungkin sedikit kurang dari 100% karena vektor diukur sebelum ditambahkan ke indeks. Namun, pencarian vektor dengan quantized flat harus memiliki latensi yang lebih rendah, throughput yang lebih tinggi, dan biaya RU yang lebih rendah daripada pencarian vektor pada flat indeks. Ini adalah opsi yang baik untuk skenario di mana Anda menggunakan filter kueri untuk mempersempit pencarian vektor ke sekumpulan vektor yang relatif kecil, dan akurasi tinggi diperlukan.

• Indeks diskANN adalah indeks terpisah yang didefinisikan khusus untuk vektor yang menerapkan DiskANN, serangkaian algoritma pengindeksan vektor performa tinggi yang dikembangkan oleh Microsoft Research. Indeks DiskANN dapat menawarkan beberapa latensi terendah, throughput tertinggi, dan kueri biaya RU terendah, sambil tetap mempertahankan akurasi tinggi. Namun, karena DiskANN adalah perkiraan indeks tetangga terdekat (ANN), akurasinya mungkin lebih rendah dari quantizedFlat atau flat.

Berikut adalah contoh kebijakan pengindeksan dengan indeks vektor:

{
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/*"
        }
    ],
    "excludedPaths": [
        {
            "path": "/_etag/?",
        },
        {
            "path": "/vector/*"
        }
    ],
    "vectorIndexes": [
        {
            "path": "/vector",
            "type": "diskANN"
        }
    ]
}

Penting

Kebijakan pengindeksan vektor harus berada di jalur yang ditentukan dalam kebijakan vektor kontainer. Pelajari selengkapnya tentang kebijakan vektor kontainer. Indeks vektor juga harus ditentukan pada saat pembuatan Kontainer dan tidak dapat dimodifikasi setelah dibuat. Dalam rilis mendatang, indeks vektor akan dapat dimodifikasi.

Penting

Jalur vektor ditambahkan ke bagian "excludedPaths" dari kebijakan pengindeksan untuk memastikan performa yang dioptimalkan untuk penyisipan. Tidak menambahkan jalur vektor ke "excludedPaths" akan mengakibatkan biaya RU dan latensi yang lebih tinggi untuk penyisipan vektor.

Indeks spasial

Saat menentukan jalur spasial dalam kebijakan pengindeksan, Anda harus menentukan indeks mana type yang harus diterapkan ke jalur tersebut. Jenis yang mungkin untuk indeks spasial meliputi:

• Titik

• Poligon

• MultiPolygon

• LineString

Azure Cosmos DB, secara default, tidak akan membuat indeks spasial apa pun. Jika ingin menggunakan fungsi bawaan SQL spasial, Anda harus membuat indeks spasial pada properti yang diperlukan. Lihat bagian ini untuk contoh kebijakan pengindeksan untuk menambahkan indeks spasial.

Indeks komposit

Kueri yang memiliki ORDER BY klausul dengan dua properti atau lebih memerlukan indeks komposit. Anda juga dapat menentukan indeks komposit untuk meningkatkan performa banyak kueri persamaan dan rentang. Secara default, tidak ada indeks komposit yang didefinisikan sehingga Anda harus menambahkan indeks komposit sesuai kebutuhan.

Tidak seperti jalur yang disertakan atau dikecualikan, Anda tidak dapat membuat jalur dengan /* kartubebas. Setiap jalur komposit memiliki implisit /? di akhir jalur yang tidak perlu Anda tentukan. Jalur komposit mengarah ke nilai skalar yang merupakan satu-satunya nilai yang disertakan dalam indeks komposit. Jika jalur dalam indeks komposit tidak ada dalam item atau mengarah ke nilai nonscalar, nilai ditambahkan ke indeks untuk menunjukkan bahwa jalur tidak terdefinisi.

Saat mendefinisikan indeks komposit, Anda menentukan:

• Dua atau beberapa jalur properti. Urutan di mana jalur properti didefinisikan penting.

• Urutan (naik atau turun).

Catatan

Saat Anda menambahkan indeks komposit, kueri akan menggunakan indeks rentang yang ada hingga penambahan indeks komposit baru selesai. Oleh karena itu, ketika Anda menambahkan indeks komposit, Anda mungkin tidak segera mengamati peningkatan performa. Dimungkinkan untuk melacak kemajuan transformasi indeks dengan menggunakan salah satu SDKs.

Kueri ORDER BY pada beberapa properti:

Pertimbangan berikut digunakan saat menggunakan indeks komposit untuk kueri dengan ORDER BY klausul dengan dua properti atau lebih:

• Jika jalur indeks komposit tidak cocok dengan urutan properti dalam ORDER BY klausa, maka indeks komposit tidak dapat mendukung kueri.

• Urutan jalur indeks komposit (naik atau turun) juga harus cocok dengan order dalam ORDER BY klausul.

• Indeks komposit juga mendukung ORDER BY klausul dengan urutan yang berlawanan pada semua jalur.

Pertimbangkan contoh berikut di mana indeks komposit ditentukan pada nama properti, usia, dan _ts:

Indeks Komposit	Kueri Sampel ORDER BY	Didukung oleh Indeks Komposit?
(name ASC, age ASC)	SELECT * FROM c ORDER BY c.name ASC, c.age asc	Yes
(name ASC, age ASC)	SELECT * FROM c ORDER BY c.age ASC, c.name asc	No
(name ASC, age ASC)	SELECT * FROM c ORDER BY c.name DESC, c.age DESC	Yes
(name ASC, age ASC)	SELECT * FROM c ORDER BY c.name ASC, c.age DESC	No
(name ASC, age ASC, timestamp ASC)	SELECT * FROM c ORDER BY c.name ASC, c.age ASC, timestamp ASC	Yes
(name ASC, age ASC, timestamp ASC)	SELECT * FROM c ORDER BY c.name ASC, c.age ASC	No

Anda harus menyesuaikan kebijakan pengindeksan sehingga Anda dapat melayani semua kueri ORDER BY yang diperlukan.

Kueri dengan filter pada beberapa properti

Jika kueri memiliki filter pada dua properti atau lebih, mungkin berguna untuk membuat indeks komposit untuk properti ini.

Misalnya, pertimbangkan kueri berikut yang memiliki filter kesetaraan dan rentang:

SELECT *
FROM c
WHERE c.name = "John" AND c.age > 18

Kueri ini lebih efisien, membutuhkan lebih sedikit waktu dan memakan lebih sedikit RU, jika dapat menerapkan indeks komposit pada (name ASC, age ASC).

Kueri dengan beberapa filter rentang juga dapat dioptimalkan dengan indeks komposit. Namun, setiap indeks komposit individu hanya dapat mengoptimalkan filter rentang tunggal. Filter rentang termasuk >, <, <=, >=, dan !=. Filter rentang harus ditentukan terakhir dalam indeks komposit.

Pertimbangkan kueri berikut dengan filter kesamaan dan dua filter rentang:

SELECT *
FROM c
WHERE c.name = "John" AND c.age > 18 AND c._ts > 1612212188

Kueri ini lebih efisien dengan indeks komposit pada (name ASC, age ASC) dan (name ASC, _ts ASC). Namun, kueri tidak akan menggunakan indeks komposit karena (age ASC, name ASC) properti dengan filter kesetaraan harus ditentukan terlebih dahulu dalam indeks komposit. Dua indeks komposit terpisah diperlukan, bukan indeks komposit tunggal pada (name ASC, age ASC, _ts ASC) karena setiap indeks komposit hanya dapat mengoptimalkan satu filter rentang.

Pertimbangan berikut digunakan saat membuat indeks komposit untuk kueri dengan filter pada beberapa properti

• Ekspresi filter bisa menggunakan beberapa indeks komposit.
• Properti dalam filter kueri harus cocok dengan properti dalam indeks komposit. Jika properti berada dalam indeks komposit tetapi tidak disertakan dalam kueri sebagai filter, kueri tidak akan menggunakan indeks komposit.
• Jika kueri memiliki properti lain dalam filter yang tidak ditentukan dalam indeks komposit, kombinasi indeks komposit dan rentang digunakan untuk mengevaluasi kueri. Ini membutuhkan lebih sedikit RU daripada secara eksklusif menggunakan indeks rentang.
• Jika properti memiliki filter rentang (>, <, <=, >=, atau !=), maka properti ini harus ditentukan terakhir dalam indeks komposit. Jika kueri memiliki lebih dari satu filter rentang, kueri mungkin mendapat manfaat dari beberapa indeks komposit.
• Saat membuat indeks komposit untuk mengoptimalkan kueri dengan beberapa filter, ORDER indeks komposit tidak berdampak pada hasilnya. Properti ini bersifat opsional.

Pertimbangkan contoh berikut di mana indeks komposit ditentukan pada nama properti, usia, dan tanda waktu:

Indeks Komposit	Contoh Kueri	Didukung oleh Indeks Komposit?
(name ASC, age ASC)	SELECT * FROM c WHERE c.name = "John" AND c.age = 18	Yes
(name ASC, age ASC)	SELECT * FROM c WHERE c.name = "John" AND c.age > 18	Yes
(name ASC, age ASC)	SELECT COUNT(1) FROM c WHERE c.name = "John" AND c.age > 18	Yes
(name DESC, age ASC)	SELECT * FROM c WHERE c.name = "John" AND c.age > 18	Yes
(name ASC, age ASC)	SELECT * FROM c WHERE c.name != "John" AND c.age > 18	No
(name ASC, age ASC, timestamp ASC)	SELECT * FROM c WHERE c.name = "John" AND c.age = 18 AND c.timestamp > 123049923	Yes
(name ASC, age ASC, timestamp ASC)	SELECT * FROM c WHERE c.name = "John" AND c.age < 18 AND c.timestamp = 123049923	No
(name ASC, age ASC) and (name ASC, timestamp ASC)	SELECT * FROM c WHERE c.name = "John" AND c.age < 18 AND c.timestamp > 123049923	Yes

Kueri dengan filter dan ORDER BY

Jika kueri memfilter pada satu atau beberapa properti dan memiliki properti yang berbeda dalam klausa ORDER BY, mungkin berguna untuk menambahkan properti dalam filter ke ORDER BY klausa.

Misalnya, dengan menambahkan properti dalam filter ke ORDER BY klausa, kueri berikut dapat ditulis ulang untuk menerapkan indeks komposit:

Kueri menggunakan indeks rentang:

SELECT *
FROM c 
WHERE c.name = "John" 
ORDER BY c.timestamp

Kueri menggunakan indeks komposit:

SELECT * 
FROM c 
WHERE c.name = "John"
ORDER BY c.name, c.timestamp

Pengoptimalan kueri yang sama dapat digeneralisasikan untuk setiap ORDER BY kueri dengan filter, mengingat bahwa indeks komposit individu hanya dapat mendukung, paling banyak, satu filter rentang.

Kueri menggunakan indeks rentang:

SELECT * 
FROM c 
WHERE c.name = "John" AND c.age = 18 AND c.timestamp > 1611947901 
ORDER BY c.timestamp

Kueri menggunakan indeks komposit:

SELECT * 
FROM c 
WHERE c.name = "John" AND c.age = 18 AND c.timestamp > 1611947901 
ORDER BY c.name, c.age, c.timestamp

Selain itu, Anda dapat menggunakan indeks komposit untuk mengoptimalkan kueri dengan fungsi sistem dan ORDER BY:

Kueri menggunakan indeks rentang:

SELECT * 
FROM c 
WHERE c.firstName = "John" AND Contains(c.lastName, "Smith", true) 
ORDER BY c.lastName

Kueri menggunakan indeks komposit:

SELECT * 
FROM c 
WHERE c.firstName = "John" AND Contains(c.lastName, "Smith", true) 
ORDER BY c.firstName, c.lastName

Pertimbangan berikut berlaku saat membuat indeks komposit untuk mengoptimalkan kueri dengan filter dan ORDER BY klausul:

• Jika Anda tidak menentukan indeks komposit pada kueri dengan filter pada satu properti dan klausa terpisah ORDER BY menggunakan properti lain, kueri akan tetap berhasil. Namun, biaya RU kueri dapat dikurangi dengan indeks komposit, terutama jika properti dalam ORDER BY klausul memiliki kardinalitas tinggi.
• Jika kueri memfilter properti, properti ini harus disertakan terlebih dahulu dalam ORDER BY klausa.
• Jika filter kueri pada beberapa properti, filter kesamaan harus menjadi properti pertama dalam ORDER BY klausul.
• Jika filter kueri pada beberapa properti, Anda bisa memiliki maksimum satu filter rentang atau fungsi sistem yang digunakan per indeks komposit. Properti yang digunakan dalam filter rentang atau fungsi sistem harus didefinisikan terakhir dalam indeks komposit.
• Semua pertimbangan untuk membuat indeks komposit untuk ORDER BY kueri dengan beberapa properti dan kueri dengan filter pada beberapa properti masih berlaku.

Indeks Komposit	Kueri Sampel ORDER BY	Didukung oleh Indeks Komposit?
(name ASC, timestamp ASC)	SELECT * FROM c WHERE c.name = "John" ORDER BY c.name ASC, c.timestamp ASC	Yes
(name ASC, timestamp ASC)	SELECT * FROM c WHERE c.name = "John" AND c.timestamp > 1589840355 ORDER BY c.name ASC, c.timestamp ASC	Yes
(timestamp ASC, name ASC)	SELECT * FROM c WHERE c.timestamp > 1589840355 AND c.name = "John" ORDER BY c.timestamp ASC, c.name ASC	No
(name ASC, timestamp ASC)	SELECT * FROM c WHERE c.name = "John" ORDER BY c.timestamp ASC, c.name ASC	No
(name ASC, timestamp ASC)	SELECT * FROM c WHERE c.name = "John" ORDER BY c.timestamp ASC	No
(age ASC, name ASC, timestamp ASC)	SELECT * FROM c WHERE c.age = 18 and c.name = "John" ORDER BY c.age ASC, c.name ASC,c.timestamp ASC	Yes
(age ASC, name ASC, timestamp ASC)	SELECT * FROM c WHERE c.age = 18 and c.name = "John" ORDER BY c.timestamp ASC	No

Kueri dengan filter dan agregat

Jika kueri memfilter pada satu atau beberapa properti dan memiliki fungsi sistem agregat, mungkin berguna untuk membuat indeks komposit untuk properti dalam fungsi sistem filter dan agregat. Pengoptimalan ini berlaku untuk fungsi sistem SUM dan AVG.

Pertimbangan berikut berlaku saat membuat indeks komposit untuk mengoptimalkan kueri dengan filter dan fungsi sistem agregat.

• Indeks komposit bersifat opsional saat menjalankan kueri dengan agregat. Namun, biaya RU kueri sering kali dapat dikurangi dengan indeks komposit.
• Jika filter kueri pada beberapa properti, filter kesamaan harus menjadi properti pertama dalam indeks komposit.
• Anda dapat memiliki maksimum satu rentang filter per indeks komposit dan harus berada di properti dalam fungsi sistem agregat.
• Properti dalam fungsi sistem agregat harus ditentukan terakhir dalam indeks komposit.
• ( orderASC atau DESC) tidak masalah.

Indeks Komposit	Contoh Kueri	Didukung oleh Indeks Komposit?
(name ASC, timestamp ASC)	SELECT AVG(c.timestamp) FROM c WHERE c.name = "John"	Yes
(timestamp ASC, name ASC)	SELECT AVG(c.timestamp) FROM c WHERE c.name = "John"	No
(name ASC, timestamp ASC)	SELECT AVG(c.timestamp) FROM c WHERE c.name > "John"	No
(name ASC, age ASC, timestamp ASC)	SELECT AVG(c.timestamp) FROM c WHERE c.name = "John" AND c.age = 25	Yes
(age ASC, timestamp ASC)	SELECT AVG(c.timestamp) FROM c WHERE c.name = "John" AND c.age > 25	No

Mengubah kebijakan pengindeksan

Kebijakan pengindeksan kontainer dapat diperbarui kapan saja dengan menggunakan portal Microsoft Azure atau salah satu SDKs yang didukung. Pembaruan pada kebijakan pengindeksan memicu transformasi dari indeks lama ke yang baru, yang dilakukan secara online dan di tempat (sehingga tidak ada ruang penyimpanan tambahan yang digunakan selama operasi). Kebijakan pengindeksan lama secara efisien ditransformasikan ke kebijakan baru tanpa memengaruhi ketersediaan tulis, ketersediaan baca, atau throughput yang disediakan pada kontainer. Transformasi indeks adalah operasi asinkron, dan waktu yang diperlukan untuk menyelesaikan tergantung pada throughput yang disediakan, jumlah item, dan ukurannya. Jika beberapa pembaruan kebijakan pengindeksan harus dilakukan, disarankan untuk melakukan semua perubahan sebagai operasi tunggal agar transformasi indeks selesai secepat mungkin.

Penting

Transformasi indeks adalah operasi yang menggunakan unit permintaan.

Catatan

Anda dapat melacak kemajuan transformasi indeks di portal Azure atau dengan menggunakan salah satu SDK.

Tidak ada dampak untuk menulis ketersediaan selama transformasi indeks apa pun. Transformasi indeks menggunakan RUs yang disediakan tetapi pada prioritas yang lebih rendah dibandingkan operasi atau kueri CRUD Anda.

Tidak ada dampak untuk membaca ketersediaan saat menambahkan jalur terindeks baru. Kueri hanya akan menggunakan jalur terindeks baru setelah transformasi indeks selesai. Dengan kata lain, saat menambahkan jalur terindeks baru, kueri yang mendapat manfaat dari jalur terindeks tersebut memiliki performa yang sama sebelum dan selama transformasi indeks. Setelah transformasi indeks selesai, mesin kueri akan mulai menggunakan jalur terindeks baru.

Saat menghapus jalur terindeks, Anda harus mengelompokkan semua perubahan menjadi satu transformasi kebijakan pengindeksan. Jika Anda menghapus beberapa indeks dan melakukannya dalam satu perubahan kebijakan pengindeksan tunggal, mesin kueri memberikan hasil yang konsisten dan lengkap selama transformasi indeks. Namun, jika Anda menghapus indeks melalui beberapa perubahan kebijakan pengindeksan, mesin kueri tidak akan memberikan hasil yang konsisten atau lengkap sampai semua transformasi indeks selesai. Sebagian besar pengembang tidak menghilangkan indeks dan kemudian segera mencoba menjalankan kueri yang menggunakan indeks ini sehingga, dalam praktiknya, situasi ini tidak mungkin terjadi.

Saat Anda menghilangkan jalur terindeks, mesin kueri akan segera berhenti menggunakannya, dan akan melakukan pemindaian penuh sebagai gantinya.

Catatan

Jika memungkinkan, Anda harus selalu mencoba mengelompokkan beberapa penghapusan indeks menjadi satu modifikasi kebijakan pengindeksan tunggal.

Penting

Menghapus indeks akan segera berlaku, sedangkan menambahkan indeks baru membutuhkan waktu karena memerlukan transformasi pengindeksan. Saat mengganti satu indeks dengan indeks lain (misalnya, mengganti indeks properti tunggal dengan indeks komposit) pastikan untuk menambahkan indeks baru terlebih dahulu lalu menunggu transformasi indeks selesai sebelum Anda menghapus indeks sebelumnya dari kebijakan pengindeksan. Jika tidak, ini akan berdampak negatif pada kemampuan Anda untuk mengkueri indeks sebelumnya dan mungkin merusak beban kerja aktif apa pun yang mereferensikan indeks sebelumnya.

Kebijakan pengindeksan dan TTL

Menggunakan fitur Time-to-Live (TTL) memerlukan pengindeksan. Ini berarti bahwa:

• tidak dimungkinkan untuk mengaktifkan TTL pada kontainer tempat mode pengindeksan diatur ke none,
• tidak dimungkinkan untuk mengatur mode pengindeksan ke Tidak Ada pada kontainer tempat TTL diaktifkan.

Untuk skenario di mana tidak ada jalur properti yang perlu diindeks, tetapi TTL diperlukan, Anda dapat menggunakan kebijakan pengindeksan dengan mode pengindeksan yang diatur ke consistent, tidak ada jalur yang disertakan, dan /* sebagai satu-satunya jalur yang dikecualikan.

Konten terkait

• Gambaran umum pengindeksan
• Cara mengelola kebijakan pengindeksan