Azure Cosmos DB 'de dizin oluşturma ilkeleriIndexing policies in Azure Cosmos DB

Azure Cosmos DB, her kapsayıcının kapsayıcının öğelerinin nasıl dizine alınacağını belirleyen bir dizin oluşturma ilkesi vardır.In Azure Cosmos DB, every container has an indexing policy that dictates how the container's items should be indexed. Yeni oluşturulan kapsayıcılar için varsayılan dizin oluşturma ilkesi her öğenin her bir özelliğini dizinleyen, herhangi bir dize veya sayı için Aralık dizini uygulayan ve tür noktası olan herhangi bir GeoJSON nesnesi için uzamsal dizinler.The default indexing policy for newly created containers indexes every property of every item, enforcing range indexes for any string or number, and spatial indexes for any GeoJSON object of type Point. Bu, dizin oluşturma ve dizin yönetimi ile ilgili düşünmek zorunda kalmadan yüksek sorgu performansı almanızı sağlar.This allows you to get high query performance without having to think about indexing and index management upfront.

Bazı durumlarda, gereksinimlerinize daha iyi uyacak şekilde bu otomatik davranışı geçersiz kılmak isteyebilirsiniz.In some situations, you may want to override this automatic behavior to better suit your requirements. Dizin oluşturma modunuayarlayarak bir kapsayıcının dizin oluşturma ilkesini özelleştirebilir ve özellik yollarınıdahil edebilir veya dışlayabilirsiniz.You can customize a container's indexing policy by setting its indexing mode, and include or exclude property paths.

Not

Bu makalede açıklanan dizin oluşturma ilkelerini güncelleştirme yöntemi yalnızca Azure Cosmos DB SQL (Core) API 'SI için geçerlidir.The method of updating indexing policies described in this article only applies to Azure Cosmos DB's SQL (Core) API.

Dizin oluşturma moduIndexing mode

Azure Cosmos DB iki dizin oluşturma modunu destekler:Azure Cosmos DB supports two indexing modes:

  • Tutarlı: Öğe oluşturma, güncelleştirme veya silme işlemi sırasında dizin zaman uyumlu olarak güncelleştirilir.Consistent: The index is updated synchronously as you create, update or delete items. Bu, okuma sorgularınızın tutarlılığı, hesap için yapılandırılmış tutarlılığasahip olacağı anlamına gelir.This means that the consistency of your read queries will be the consistency configured for the account.
  • Hiçbiri: Dizin oluşturma, kapsayıcıda devre dışı bırakıldı.None: Indexing is disabled on the container. Bu genellikle bir kapsayıcı, ikincil dizinlere gerek olmadan saf anahtar-değer deposu olarak kullanıldığında kullanılır.This is commonly used when a container is used as a pure key-value store without the need for secondary indexes. Toplu işlemlerin performansını artırmak için de kullanılabilir.It can also be used to improve the performance of bulk operations. Toplu işlemler tamamlandıktan sonra, dizin modu tutarlı olarak ayarlanabilir ve sonra, Işlem tamamlanana kadar ındexdönüşümle ilerlemesi kullanılarak izlenebilir.After the bulk operations are complete, the index mode can be set to Consistent and then monitored using the IndexTransformationProgress until complete.

Not

Cosmos DB, yavaş dizin oluşturma modunu da destekler.Cosmos DB also supports a Lazy indexing mode. Yavaş dizin oluşturma, altyapı başka bir iş gerçekleştirmediğinden daha düşük bir öncelik düzeyinde dizinde güncelleştirmeler gerçekleştirir.Lazy indexing performs updates to the index at a much lower priority level when the engine is not doing any other work. Bu, tutarsız veya tamamlanmamış sorgu sonuçlarının oluşmasına neden olabilir.This can result in inconsistent or incomplete query results. Ayrıca, toplu işlemler için ' none ' yerine yavaş dizin oluşturma özelliği, Dizin modunda yapılan herhangi bir değişiklik dizinin bırakılmasına ve yeniden oluşturulmasına neden olacağı için de hiçbir avantaj sağlamaz.Additionally, using Lazy indexing in place of 'None' for bulk operations also provides no benefit as any change to the Index Mode will cause the index to be dropped and recreated. Bu nedenlerden dolayı müşterileri kullanan müşterilere karşı öneririz.For these reasons we recommend against customers using it. Toplu işlemlere yönelik performansı artırmak için, Dizin modunu None olarak ayarlayın, ardından tutarlı moda geri dönün ve işlem tamamlanana IndexTransformationProgress kadar kapsayıcıda özelliği izleyin.To improve performance for bulk operations, set index mode to None, then return to Consistent mode and monitor the IndexTransformationProgress property on the container until complete.

Varsayılan olarak, dizin oluşturma ilkesi olarak automaticayarlanır.By default, indexing policy is set to automatic. Dizin oluşturma ilkesindeki automatic özelliği olarak trueayarlanarak elde edilir.It's achieved by setting the automatic property in the indexing policy to true. Bu özelliği ayarlamak için true Azure cosmosdb 'nin belgeleri yazıldığı gibi otomatik olarak dizin oluşturulmasına izin verir.Setting this property to true allows Azure CosmosDB to automatically index documents as they are written.

Özellik yollarını dahil etme ve hariç tutmaIncluding and excluding property paths

Özel bir dizin oluşturma ilkesi, dizin oluşturma işleminden açıkça dahil edilen veya dışlanan Özellik yollarını belirtebilir.A custom indexing policy can specify property paths that are explicitly included or excluded from indexing. Dizini oluşturulmuş yolların sayısını en iyi duruma getirerek, Kapsayıcınız tarafından kullanılan depolama miktarını düşürebilirsiniz ve yazma işlemlerinin gecikme süresini artırabilirsiniz.By optimizing the number of paths that are indexed, you can lower the amount of storage used by your container and improve the latency of write operations. Bu yollar, Dizin oluşturma genel bakış bölümünde açıklanan yöntemi aşağıdaki eklemelerle izleyerek tanımlanmıştır:These paths are defined following the method described in the indexing overview section with the following additions:

  • skaler bir değere (dize veya sayı) öndeki bir yol, şununla biter/?a path leading to a scalar value (string or number) ends with /?
  • bir dizideki öğeler /[] /0, Gösterim (yerine, /1 vb.) ile birlikte karşılanırelements from an array are addressed together through the /[] notation (instead of /0, /1 etc.)
  • /* joker karakter, düğümün altındaki herhangi bir öğeyi eşleştirmek için kullanılabilirthe /* wildcard can be used to match any elements below the node

Aynı örneği yeniden almak:Taking the same example again:

    {
        "locations": [
            { "country": "Germany", "city": "Berlin" },
            { "country": "France", "city": "Paris" }
        ],
        "headquarters": { "country": "Belgium", "employees": 250 }
        "exports": [
            { "city": "Moscow" },
            { "city": "Athens" }
        ]
    }
  • headquartersyolu employees``/headquarters/employees/?the headquarters's employees path is /headquarters/employees/?

  • locations' yolcountry``/locations/[]/country/?the locations' country path is /locations/[]/country/?

  • altında headquarters herhangi bir şeyin yolu/headquarters/*the path to anything under headquarters is /headquarters/*

Örneğin, /headquarters/employees/? yolunu dahil eteceğiz.For example, we could include the /headquarters/employees/? path. Bu yol çalışanlar özelliğini dizinliyoruz, ancak bu özellik içinde iç içe geçmiş JSON dizinini dizinliyoruz.This path would ensure that we index the employees property but would not index additional nested JSON within this property.

Dahil etme/hariç tutma stratejisiInclude/exclude strategy

Herhangi bir dizin oluşturma ilkesinin kök yolu /* dahil edilen ya da hariç tutulmuş bir yol olarak içermesi gerekmez.Any indexing policy has to include the root path /* as either an included or an excluded path.

  • Dizin oluşturma gerektirmeyen yolları seçmeli olarak hariç tutmak için kök yolu ekleyin.Include the root path to selectively exclude paths that don't need to be indexed. Bu, modelinize eklenebilen yeni bir özelliğin Azure Cosmos DB proaktif olarak dizinlemenizi sağlayan bu, önerilen yaklaşımdır.This is the recommended approach as it lets Azure Cosmos DB proactively index any new property that may be added to your model.

  • Dizine eklenmesi gereken yolları seçmeli olarak dahil etmek için kök yolu hariç tutun.Exclude the root path to selectively include paths that need to be indexed.

  • : Alfasayısal karakterler ve _ (alt çizgi) içeren normal karakter içeren yollar için, yol dizesinin çift tırnak etrafında (örneğin, "/path/?") kaçış olması gerekmez.For paths with regular characters that include: alphanumeric characters and _ (underscore), you don’t have to escape the path string around double quotes (for example, "/path/?"). Diğer özel karakterlere sahip yollar için, yol dizesini çift tırnak etrafında (örneğin, "/"Path-ABC"/?") kaçış yapmanız gerekir.For paths with other special characters, you need to escape the path string around double quotes (for example, "/"path-abc"/?"). Yolunuzda özel karakterler bekleliyorsanız, güvenlik için her yolu da kaçış yapabilirsiniz.If you expect special characters in your path, you can escape every path for safety. İşlevsel olarak, tüm yolları yalnızca özel karakterlere sahip olanlara karşı atladıysanız herhangi bir farklılık yapmaz.Functionally it doesn’t make any difference if you escape every path Vs just the ones that have special characters.

  • "ETag" sistem özelliği dizin oluşturma için eklenen yola eklenemediği takdirde varsayılan olarak dizin oluşturma işleminden çıkarılır.The system property "etag" is excluded from indexing by default, unless the etag is added to the included path for indexing.

Yolları dahil etme ve hariç tutma sırasında aşağıdaki özniteliklerle karşılaşabilirsiniz:When including and excluding paths, you may encounter the following attributes:

  • kind``range yahashda olabilir.kind can be either range or hash. Aralık dizini işlevselliği bir karma dizinin tüm işlevlerini sağlar, bu nedenle bir Aralık dizini kullanmanızı öneririz.Range index functionality provides all of the functionality of a hash index, so we recommend using a range index.

  • precision, eklenen yollar için dizin düzeyinde tanımlanmış bir sayıdır.precision is a number defined at the index level for included paths. Değeri en fazla -1 duyarlığı gösterir.A value of -1 indicates maximum precision. Bu değeri her zaman olarak -1ayarlamayı öneririz.We recommend always setting this value to -1.

  • dataType``String yaNumberda olabilir.dataType can be either String or Number. Bu, dizine eklenecek JSON özelliklerinin türlerini gösterir.This indicates the types of JSON properties which will be indexed.

Belirtilmediğinde, bu özellikler aşağıdaki varsayılan değerlere sahip olur:When not specified, these properties will have the following default values:

Özellik adıProperty Name Varsayılan değerDefault Value
kind range
precision -1
dataType String ve NumberString and Number

Yolların dahil edilmesi ve dışlanması için ilke örneklerinin dizinini oluşturma bölümüne bakın.See this section for indexing policy examples for including and excluding paths.

Uzamsal dizinlerSpatial indexes

Dizin oluşturma ilkesinde bir uzamsal yol tanımladığınızda, bu yola hangi dizinin type uygulanacağını tanımlamanız gerekir.When you define a spatial path in the indexing policy, you should define which index type should be applied to that path. Uzamsal dizinler için olası türler şunlardır:Possible types for spatial indexes include:

  • SeçeneğininPoint

  • GenPolygon

  • MultiPolygonMultiPolygon

  • LineStringLineString

Azure Cosmos DB, varsayılan olarak hiçbir uzamsal dizin oluşturmaz.Azure Cosmos DB, by default, will not create any spatial indexes. Uzamsal SQL yerleşik işlevlerini kullanmak isterseniz, gereken özelliklerde bir uzamsal dizin oluşturmanız gerekir.If you would like to use spatial SQL built-in functions, you should create a spatial index on the required properties. Uzamsal dizinler eklemeye yönelik dizin oluşturma örnekleri için Bu bölüme bakın.See this section for indexing policy examples for adding spatial indexes.

Bileşik dizinlerComposite indexes

İki veya daha fazla ORDER BY özelliği olan bir yan tümcesine sahip sorgular bileşik bir dizin gerektirir.Queries that have an ORDER BY clause with two or more properties require a composite index. Ayrıca, birçok eşitlik ve Aralık sorgusunun performansını artırmak için bir bileşik dizin tanımlayabilirsiniz.You can also define a composite index to improve the performance of many equality and range queries. Varsayılan olarak, bir bileşik dizin tanımlanmadığında, gereken şekilde Bileşik dizinler eklemelisiniz .By default, no composite indexes are defined so you should add composite indexes as needed.

Bileşik dizin tanımlarken şunu belirtirsiniz:When defining a composite index, you specify:

  • İki veya daha fazla özellik yolu.Two or more property paths. Özellik yollarının önemli olarak tanımlandığı sıra.The sequence in which property paths are defined matters.

  • Sıra (artan veya azalan).The order (ascending or descending).

Not

Diğer dizin türlerinde olduğu gibi bileşik bir dizin eklerken, Dizin güncelleştirildiğinden sorgular tutarsız sonuçlar döndürebilir.When adding a composite index, as with other index types, queries may return inconsistent results as the index is being updated.

Birden çok özelliklerde sorguya göre sırala:ORDER BY queries on multiple properties:

İki veya daha fazla özelliği olan bir ORDER BY yan tümcesine sahip sorgular için Bileşik dizinler kullanılırken aşağıdaki noktalar kullanılır:The following considerations are used when using composite indexes for queries with an ORDER BY clause with two or more properties:

  • Bileşik dizin yolları ORDER BY yan tümcesindeki özelliklerin dizisiyle eşleşmezse, bileşik dizin sorguyu desteklemiyor.If the composite index paths do not match the sequence of the properties in the ORDER BY clause, then the composite index can't support the query.

  • Bileşik dizin yollarının sırası (artan veya azalan), order ORDER BY yan tümcesindeki ile de eşleşmelidir.The order of composite index paths (ascending or descending) should also match the order in the ORDER BY clause.

  • Bileşik dizin aynı zamanda tüm yollarda ORDER BY ters sırada olan bir yan tümceyi destekler.The composite index also supports an ORDER BY clause with the opposite order on all paths.

Bir bileşik dizinin özellikler adı, yaşı ve _ts üzerinde tanımlandığı aşağıdaki örneği göz önünde bulundurun:Consider the following example where a composite index is defined on properties name, age, and _ts:

Bileşik DizinComposite Index Örnek ORDER BY sorguSample ORDER BY Query Bileşik dizin tarafından destekleniyor mu?Supported by Composite Index?
(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

Tüm gerekli ORDER BY sorgulara hizmeti sağlamak için dizin oluşturma ilkenizi özelleştirmeniz gerekir.You should customize your indexing policy so you can serve all necessary ORDER BY queries.

Birden çok özelliklerde filtre içeren sorgularQueries with filters on multiple properties

Bir sorgu iki veya daha fazla özelliğe filtre içeriyorsa, bu özellikler için bileşik bir dizin oluşturmak yararlı olabilir.If a query has filters on two or more properties, it may be helpful to create a composite index for these properties.

Örneğin, iki özellik üzerinde bir eşitlik filtresi bulunan aşağıdaki sorguyu göz önünde bulundurun:For example, consider the following query which has an equality filter on two properties:

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

Bu sorgu daha verimli olacaktır, daha az zaman alır ve bir bileşik dizinden yararlanıyorsa daha az RU (ad ASC, Age ASC).This query will be more efficient, taking less time and consuming fewer RU's, if it is able to leverage a composite index on (name ASC, age ASC).

Aralık filtreleri içeren sorgular da bileşik bir dizinle iyileştirilebilir.Queries with range filters can also be optimized with a composite index. Ancak, sorgu yalnızca tek bir Aralık filtresine sahip olabilir.However, the query can only have a single range filter. >Aralık filtreleri < ,>=,, ve!=içerir. <=Range filters include >, <, <=, >=, and !=. Aralık filtresi, en son bileşik dizinde tanımlanmalıdır.The range filter should be defined last in the composite index.

Aşağıdaki sorguyu hem eşitlik hem de Aralık filtreleriyle göz önünde bulundurun:Consider the following query with both equality and range filters:

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

Bu sorgu, üzerinde bileşik bir dizin ile daha verimli olacaktır (ad ASC, Age ASC).This query will be more efficient with a composite index on (name ASC, age ASC). Ancak, sorgu (Age ASC, ad ASC) üzerinde bir bileşik dizin kullanmaz, çünkü eşitlik filtreleri ilk olarak bileşik dizinde tanımlanmalıdır.However, the query would not utilize a composite index on (age ASC, name ASC) because the equality filters must be defined first in the composite index.

Birden çok özelliklerde filtre içeren sorgular için Bileşik dizinler oluşturulurken aşağıdaki noktalar kullanılırThe following considerations are used when creating composite indexes for queries with filters on multiple properties

  • Sorgunun filtresindeki özellikler, bileşik dizinindekilerle eşleşmelidir.The properties in the query's filter should match those in composite index. Bir özellik bileşik dizindaysa, ancak sorguya filtre olarak eklenmemelidir, sorgu bileşik dizinden yararlanmaz.If a property is in the composite index but is not included in the query as a filter, the query will not utilize the composite index.
  • Bir sorguda, bir bileşik dizinde tanımlanmayan ek özellikler varsa, sorguyu değerlendirmek için bileşik ve Aralık dizinlerinin bir birleşimi kullanılır.If a query has additional properties in the filter that were not defined in a composite index, then a combination of composite and range indexes will be used to evaluate the query. Bu, Aralık dizinleri kullanılarak özel olarak daha az RU gerektirir.This will require fewer RU's than exclusively using range indexes.
  • Bir özelliğin Aralık filtresi varsa (> <=, < >=,, veya !=), bu özellik bileşik dizinde son olarak tanımlanmalıdır.If a property has a range filter (>, <, <=, >=, or !=), then this property should be defined last in the composite index. Bir sorguda birden fazla Aralık filtresi varsa, bileşik dizinden yararlanmaz.If a query has more than one range filter, it will not utilize the composite index.
  • Birden çok filtre içeren sorguları iyileştirmek için bir bileşik dizin oluştururken, ORDER bileşik dizinin sonuçları üzerinde hiçbir etkisi olmayacaktır.When creating a composite index to optimize queries with multiple filters, the ORDER of the composite index will have no impact on the results. Bu özellik isteğe bağlıdır.This property is optional.
  • Birden çok özelliklerde filtre içeren bir sorgu için bileşik dizin tanımlamadıysanız sorgu yine de başarılı olur.If you do not define a composite index for a query with filters on multiple properties, the query will still succeed. Ancak, sorgunun RU maliyeti bir bileşik dizinle azaltılabilir.However, the RU cost of the query can be reduced with a composite index.

Bir bileşik dizinin özellikler adı, yaşı ve zaman damgasında tanımlandığı aşağıdaki örnekleri göz önünde bulundurun:Consider the following examples where a composite index is defined on properties name, age, and timestamp:

Bileşik DizinComposite Index Örnek sorguSample Query Bileşik dizin tarafından destekleniyor mu?Supported by Composite Index?
(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 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

Bir filtrenin yanı sıra ORDER BY yan tümcesini içeren sorgularQueries with a filter as well as an ORDER BY clause

Bir sorgu bir veya daha fazla özellik üzerinde filtreleyip order by yan tümcesinde farklı özelliklere sahipse, filtrenin ORDER BY içindeki özellikleri yan tümcesine eklemek yararlı olabilir.If a query filters on one or more properties and has different properties in the ORDER BY clause, it may be helpful to add the properties in the filter to the ORDER BY clause.

Örneğin, filtreye ORDER BY yan tümcesine eklenen özellikleri ekleyerek, bir bileşik dizinden yararlanmak için aşağıdaki sorgu yeniden yazılabilir:For example, by adding the properties in the filter to the ORDER BY clause, the following query could be rewritten to leverage a composite index:

Aralık dizinini kullanan sorgu:Query using range index:

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

Bileşik dizin kullanarak sorgula:Query using composite index:

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

Aynı model ve sorgu iyileştirmeleri, birden çok eşitlik filtresi içeren sorgular için genelleştirilerek bulunabilir:The same pattern and query optimizations can be generalized for queries with multiple equality filters:

Aralık dizinini kullanan sorgu:Query using range index:

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

Bileşik dizin kullanarak sorgula:Query using composite index:

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

Bir sorguyu bir filtre ve ORDER BY yan tümcesiyle iyileştirmek için Bileşik dizinler oluşturulurken aşağıdaki noktalar kullanılır:The following considerations are used when creating composite indexes to optimize a query with a filter and ORDER BY clause:

  • Sorgu, özelliklere filtre uygular, bu, ilk olarak ORDER BY yan tümcesine eklenmelidir.If the query filters on properties, these should be included first in the ORDER BY clause.
  • Bir özellikte filtre içeren bir sorgu üzerinde bir bileşik dizin tanımlamadıysanız ve farklı bir özellik kullanarak ayrı ORDER BY bir yan tümce kullanırsanız, sorgu yine de başarılı olur.If you do not define a composite index on a query with a filter on one property and a separate ORDER BY clause using a different property, the query will still succeed. Ancak, özellikle ORDER BY yan tümcesindeki özelliğin yüksek bir kardinalite özelliği varsa, sorgunun ru maliyeti bileşik bir dizinle azaltılabilir.However, the RU cost of the query can be reduced with a composite index, particularly if the property in the ORDER BY clause has a high cardinality.
  • Birden çok özelliği olan sorgular için ORDER BY Bileşik dizinler oluşturmaya yönelik tüm hususlar ve birden çok özelliklerde filtre içeren sorgular hala geçerlidir.All considerations for creating composite indexes for ORDER BY queries with multiple properties as well as queries with filters on multiple properties still apply.
Bileşik DizinComposite Index Örnek ORDER BY sorguSample ORDER BY Query Bileşik dizin tarafından destekleniyor mu?Supported by Composite Index?
(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" 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

Dizin oluşturma ilkesini değiştirmeModifying the indexing policy

Kapsayıcının dizin oluşturma ilkesi , Azure Portal veya desteklenen SDK 'lardan birini kullanarakdilediğiniz zaman güncelleştirilemeyebilir.A container's indexing policy can be updated at any time by using the Azure portal or one of the supported SDKs. Dizin oluşturma ilkesi için bir güncelleştirme, eski dizinden yeni bir dönüştürmeyi tetikler ve bu, çevrimiçi ve yerinde gerçekleştirilir (Bu nedenle işlem sırasında ek depolama alanı tüketilmelidir).An update to the indexing policy triggers a transformation from the old index to the new one, which is performed online and in place (so no additional storage space is consumed during the operation). Eski ilkenin dizini, yazma kullanılabilirliğini etkilemeden ve kapsayıcıda sağlanan aktarım hızını etkilemeden etkili bir şekilde yeni ilkeye dönüştürülür.The old policy's index is efficiently transformed to the new policy without affecting the write availability or the throughput provisioned on the container. Dizin dönüştürme zaman uyumsuz bir işlemdir ve tamamlanmak üzere gereken süre, sağlanan aktarım hızına, öğe sayısına ve bunların boyutuna bağlıdır.Index transformation is an asynchronous operation, and the time it takes to complete depends on the provisioned throughput, the number of items and their size.

Not

Yeniden dizin oluşturma işlemi devam ederken, sorgular tüm eşleşen sonuçları döndürmeyebilir ve hata döndürmeksizin bunu yapacaktır.While re-indexing is in progress, queries may not return all the matching results, and will do so without returning any errors. Bu, sorgu sonuçlarının Dizin dönüştürmesi tamamlanana kadar tutarlı olamayacağı anlamına gelir.This means that query results may not be consistent until the index transformation is completed. SDK 'lardan birini kullanarakDizin dönüşümünün ilerlemesini izlemek mümkündür.It is possible to track the progress of index transformation by using one of the SDKs.

Yeni dizin oluşturma ilkesinin modu tutarlı olarak ayarlandıysa, Dizin dönüştürme işlemi devam ederken başka bir dizin oluşturma ilkesi değişikliği uygulanabilir.If the new indexing policy's mode is set to Consistent, no other indexing policy change can be applied while the index transformation is in progress. Çalışan bir dizin dönüştürmesi, dizin oluşturma ilkesinin modu None olarak ayarlanarak iptal edilebilir (Bu, dizini hemen bırakacak).A running index transformation can be canceled by setting the indexing policy's mode to None (which will immediately drop the index).

Dizin oluşturma ilkeleri ve TTLIndexing policies and TTL

Yaşam süresi (TTL) özelliği , dizin oluşturmanın açık olduğu kapsayıcıda etkin olmasını gerektirir.The Time-to-Live (TTL) feature requires indexing to be active on the container it is turned on. Bunun anlamı:This means that:

  • Dizin oluşturma modunun None olarak ayarlandığı bir kapsayıcıda TTL 'yi etkinleştirmek mümkün değildir,it is not possible to activate TTL on a container where the indexing mode is set to None,
  • TTL 'nin etkinleştirildiği bir kapsayıcıda dizin oluşturma modunun hiçbiri olarak ayarlanması mümkün değildir.it is not possible to set the indexing mode to None on a container where TTL is activated.

Hiçbir özellik yolunun dizine alınması gereken ancak TTL 'nin gerekli olduğu senaryolarda, ile bir dizin oluşturma ilkesi kullanabilirsiniz:For scenarios where no property path needs to be indexed, but TTL is required, you can use an indexing policy with:

  • bir dizin oluşturma modu tutarlı olarak ayarlanır vean indexing mode set to Consistent, and
  • dahil edilen yol yok veno included path, and
  • /*yalnızca Dışlanan yol olarak./* as the only excluded path.

Sonraki adımlarNext steps

Aşağıdaki makalelerde dizin oluşturma hakkında daha fazla bilgi edinin:Read more about the indexing in the following articles: