Veri bölümlendirme stratejileriData partitioning strategies

Bu makalede, çeşitli Azure veri depolarında bölümleme için bazı stratejiler açıklanmaktadır.This article describes some strategies for partitioning data in various Azure data stores. Verileri bölümlemek ve en iyi yöntemler konusunda genel yönergeler için bkz bölümleme verileriFor general guidance about when to partition data and best practices, see Data partitioning

Azure SQL veritabanı bölümlemePartitioning Azure SQL Database

Tek bir SQL veritabanının içerebileceği veri miktarı sınırlıdır.A single SQL database has a limit to the volume of data that it can contain. Aktarım hızı mimari faktörler ve desteklediği eş zamanlı bağlantı sayısıyla sınırlandırılmıştır.Throughput is constrained by architectural factors and the number of concurrent connections that it supports.

Elastik havuzlar bir SQL veritabanı için yatay ölçeklendirmeyi destekler.Elastic pools support horizontal scaling for a SQL database. Elastik havuzlar kullanarak verilerinizi arasında birden çok SQL veritabanına yayılan parçalar halinde bölümleyebilirsiniz.Using elastic pools, you can partition your data into shards that are spread across multiple SQL databases. Ayrıca işlemeniz gereken veriler arttıkça ve azaldıkça parçalar ekleyebilir ve kaldırabilirsiniz.You can also add or remove shards as the volume of data that you need to handle grows and shrinks. Elastik havuzlar, yükü veritabanları arasında dağıtarak çekişmeyi azaltmak da yardımcı olabilir.Elastic pools can also help reduce contention by distributing the load across databases.

Her parça bir SQL veritabanı olarak uygulanır.Each shard is implemented as a SQL database. Bir parça birden fazla veri kümesi içerebilir (adlı bir parçacık).A shard can hold more than one dataset (called a shardlet). Her veritabanında, içerdiği parçacıkları açıklayan meta veriler bulunur.Each database maintains metadata that describes the shardlets that it contains. Parçacık tek bir veri öğesi ya da aynı parçacık anahtarını paylaşan bir öğe grubunu olabilir.A shardlet can be a single data item, or a group of items that share the same shardlet key. Örneğin, çok kiracılı bir uygulama, parçacık anahtarı Kiracı kimliği olabilir ve bir kiracının tüm verileri aynı parçacık içinde tutulabilir.For example, in a multitenant application, the shardlet key can be the tenant ID, and all data for a tenant can be held in the same shardlet.

İstemci uygulamaları, bir veri kümesini parçacık anahtarıyla ilişkilendirmek için sorumludur.Client applications are responsible for associating a dataset with a shardlet key. Ayrı bir SQL veritabanı genel parça eşleme yöneticisi işlevi görür.A separate SQL database acts as a global shard map manager. Bu veritabanı sistemdeki tüm parçalar ve Parçacıkların listesi vardır.This database has a list of all the shards and shardlets in the system. Uygulamanın bir kopyasını bir parça eşlemesini almak için parça eşleme Yöneticisi veritabanına bağlanır.The application connects to the shard map manager database to obtain a copy of the shard map. Parça eşlemesi yerel olarak önbelleğe alır ve veri isteklerini uygun parçaya yönlendirir için eşleme kullanır.It caches the shard map locally, and uses the map to route data requests to the appropriate shard. Bu işlev, bir dizi bulunan API Gezgini'nin elastik veritabanı istemci Kitaplığı, Java ve .NET için kullanılabilen.This functionality is hidden behind a series of APIs that are contained in the Elastic Database client library, which is available for Java and .NET.

Elastik havuzlar hakkında daha fazla bilgi için bkz: Azure SQL veritabanı ile ölçek genişletme.For more information about elastic pools, see Scaling out with Azure SQL Database.

Gecikme süresini azaltmak ve kullanılabilirliği geliştirmek için global parça eşleme Yöneticisi veritabanını çoğaltabilirsiniz.To reduce latency and improve availability, you can replicate the global shard map manager database. Premium ücretlendirme katmanları, etkin coğrafi verileri farklı bölgelerdeki veritabanlarına sürekli olarak kopyalamak için çoğaltma yapılandırabilirsiniz.With the Premium pricing tiers, you can configure active geo-replication to continuously copy data to databases in different regions.

Alternatif olarak, Azure SQL Data Sync veya Azure Data Factory parça eşleme Yöneticisi veritabanını bölgeler arasında çoğaltmak için.Alternatively, use Azure SQL Data Sync or Azure Data Factory to replicate the shard map manager database across regions. Bu biçimdeki bir çoğaltma düzenli aralıklarla çalıştırılır ve parça eşlemesi seyrek değişen ve Premium katman gerekmez daha uygundur.This form of replication runs periodically and is more suitable if the shard map changes infrequently, and does not require Premium tier.

Elastik Veritabanı verileri parçacıklara eşlemek ve bunları parçalarda depolamak için iki düzen sağlar:Elastic Database provides two schemes for mapping data to shardlets and storing them in shards:

  • A liste parça eşlemesi parçacık tek bir anahtara ilişkilendirir.A list shard map associates a single key to a shardlet. Örneğin, çok kiracılı bir sistemde her kiracının verileri benzersiz bir anahtarla ilişkilendirilebilir ve kendi parçacığında depolanabilir.For example, in a multitenant system, the data for each tenant can be associated with a unique key and stored in its own shardlet. Yalıtım sağlamak için her parçacık kendi parçası içinde tutulabilir.To guarantee isolation, each shardlet can be held within its own shard.

    Kiracı verilerini ayrı parçalarda depolamak için liste parça eşlemesi kullanma

  • A aralık parça eşlemesi bir dizi bitişik anahtar değeriyle parçacık için ilişkilendirir.A range shard map associates a set of contiguous key values to a shardlet. Örneğin, verileri bir dizi kiracının (her biri kendi anahtar) aynı parçacık içinde gruplandırabilirsiniz.For example, you can group the data for a set of tenants (each with their own key) within the same shardlet. Bu düzen ilk ucuz, çünkü kiracılar veri depolama paylaşır, ancak daha az Yalıtımın sahiptir.This scheme is less expensive than the first, because tenants share data storage, but has less isolation.

    Bir aralıktaki kiracıların verilerini parçada depolamak için aralık parça eşlemesi kullanma

Tek bir parçanın çeşitli parçacıklardaki verileri içerebilir.A single shard can contain the data for several shardlets. Örneğin, liste parçacıklarını kullanarak bitişik olmayan farklı kiracıların verilerini aynı parçada depolayabilirsiniz.For example, you can use list shardlets to store data for different non-contiguous tenants in the same shard. Bunlar farklı eşlemeler belirtilecektir de aralık parçacıklarıyla liste parçacıklarını aynı parça içinde karıştırabilirsiniz.You can also mix range shardlets and list shardlets in the same shard, although they will be addressed through different maps. Aşağıdaki diyagramda bu yaklaşım gösterilmektedir:The following diagram shows this approach:

Birden çok parça eşlemesi gerçekleştirme

Elastik havuzlar eklemek ve veri hacmi küçüldükçe ve büyüdükçe parçalar kaldırmak mümkün kılar.Elastic pools makes it possible to add and remove shards as the volume of data shrinks and grows. İstemci uygulamaları oluşturmak ve parçaları dinamik olarak silin ve parça eşleme yöneticisini saydam bir şekilde güncelleştirin.Client applications can create and delete shards dynamically, and transparently update the shard map manager. Bununla birlikte, parçanın kaldırılması bu parçadaki tüm verilerin de silinmesini gerektiren zararlı bir işlemdir.However, removing a shard is a destructive operation that also requires deleting all the data in that shard.

Uygulamanın bir parçayı iki ayrı parçalardaki veya birleştirme parçalara bölmek gerekir, kullanın bölme-birleştirme aracını.If an application needs to split a shard into two separate shards or combine shards, use the split-merge tool. Bu araç, bir Azure web hizmeti olarak çalışır ve verileri parçalar arasında güvenle geçirir.This tool runs as an Azure web service, and migrates data safely between shards.

Bölümleme düzeni, sisteminizin performansı önemli ölçüde etkileyebilir.The partitioning scheme can significantly impact the performance of your system. Ayrıca, parçalar eklendiğinde veya kaldırıldığında gerekir veya verilerin parçalar arasında yeniden bölümlenmesi gerekir oranı etkileyebilir.It can also affect the rate at which shards have to be added or removed, or that data must be repartitioned across shards. Aşağıdaki noktaları göz önünde bulundurun:Consider the following points:

  • Aynı parçada birlikte kullanılan verileri gruplandırmak ve birden çok parçadan verilere erişen işlemlerden kaçının.Group data that is used together in the same shard, and avoid operations that access data from multiple shards. Bir parçanın kendi başına bir SQL veritabanı olduğunu ve istemci tarafında veritabanları arasındaki birleştirmeleri gerçekleştirilmesi gerekir.A shard is a SQL database in its own right, and cross-database joins must be performed on the client side.

    SQL veritabanı veritabanları arasındaki birleştirmeleri desteklemiyor olsa da, elastik veritabanı araçlarını gerçekleştirmek için kullanabileceğiniz aktarılacaksa parçalar arasında sorgu.Although SQL Database does not support cross-database joins, you can use the Elastic Database tools to perform mutli-shard queries. Çok parçalı sorgu her bir veritabanı için her sorgu gönderir ve sonuçları birleştirir.A multi-shard query sends individual queries to each database and merges the results.

  • Parçalar arasında bağımlılıklar bulunan bir sistem tasarlamayın.Don't design a system that has dependencies between shards. Başvuru bütünlük kısıtlamaları, tetikleyiciler ve saklı yordamlar bir veritabanındaki nesneleri başka bir başvuru yapamaz.Referential integrity constraints, triggers, and stored procedures in one database cannot reference objects in another.

  • Sorgular tarafından sık kullanılan başvuru verileri varsa, bu verilerin parçalar arasında çoğaltılması göz önünde bulundurun.If you have reference data that is frequently used by queries, consider replicating this data across shards. Bu yaklaşım, veritabanları arasında veri birleştirmek için ihtiyacını ortadan kaldırabilir.This approach can remove the need to join data across databases. İdeal olarak, bu tür verilerin statik veya yavaş hareket eden, çoğaltma çalışmalarını azaltmak ve olasılığını azaltmak için olmalıdır.Ideally, such data should be static or slow-moving, to minimize the replication effort and reduce the chances of it becoming stale.

  • Ayrı parça eşlemesine ait parçacıklarda aynı şemaya sahip olmalıdır.Shardlets that belong to the same shard map should have the same schema. Bu kural, SQL veritabanı, ancak veri yönetimi tarafından zorlanmaz ve sorgulama her parçacığın farklı bir şeması varsa çok karmaşık hale gelir.This rule is not enforced by SQL Database, but data management and querying becomes very complex if each shardlet has a different schema. Bunun yerine, her bir şema için ayrı parça eşlemesi oluşturun.Instead, create separate shard maps for each schema. Farklı parçacıklara ait verileri aynı parçada olabileceğini unutmayın.Remember that data belonging to different shardlets can be stored in the same shard.

  • İşlem çalışmaları yalnızca veri parça içindeki, parçalar arasında desteklenmez desteklenir.Transactional operations are only supported for data within a shard, and not across shards. İşlemler, aynı parçaya ait olmak koşuluyla parçacıklar arasında yayılabilir.Transactions can span shardlets as long as they are part of the same shard. Bu nedenle, iş mantığınız işlemler gerçekleştirmek gerekiyorsa, verileri aynı parçada depolayın veya son tutarlılık gerçekleştirin.Therefore, if your business logic needs to perform transactions, either store the data in the same shard or implement eventual consistency.

  • Parçalar bu parçalardaki verilere erişen kullanıcıların yakınına yerleştirin.Place shards close to the users that access the data in those shards. Bu strateji gecikmeyi azaltmaya yardımcı olur.This strategy helps reduce latency.

  • Son derece aktif ve görece etkin olmayan parçaları bir karışımını olmamasına özen gösterin.Avoid having a mixture of highly active and relatively inactive shards. Yükü parçalar arasında eşit yaymayı deneyin.Try to spread the load evenly across shards. Bu işlem, parçalama anahtarları karması gerekebilir.This might require hashing the sharding keys. Parçaları coğrafi olarak konumlandırıyorsanız, parçacıklara eşlenen karma anahtarların bu verilere erişen kullanıcıların yakınındaki parçalarda depolandığından emin olun.If you are geo-locating shards, make sure that the hashed keys map to shardlets held in shards stored close to the users that access that data.

Azure tablo depolamasını bölümlemePartitioning Azure table storage

Azure tablo depolaması bölümleme çerçevesinde tasarlanmış bir anahtar-değer deposudur.Azure table storage is a key-value store that's designed around partitioning. Tüm varlıklar bir bölümde depolanır ve bölümler Azure tablo depolaması tarafından dahili olarak yönetilir.All entities are stored in a partition, and partitions are managed internally by Azure table storage. Tabloda depolanan her varlık içeren iki bölümlü bir anahtar sağlamalıdır:Each entity stored in a table must provide a two-part key that includes:

  • Bölüm anahtarı.The partition key. Azure tablo depolamasının varlığı koyacağı bölüm belirleyen bir dize değeri budur.This is a string value that determines the partition where Azure table storage will place the entity. Aynı bölüm anahtarına sahip olan tüm varlıklar aynı bölümde depolanır.All entities with the same partition key are stored in the same partition.

  • Satır anahtarı.The row key. Bu varlığı bölüm içinde tanımlayan bir dize değeridir.This is a string value that identifies the entity within the partition. Bölüm içindeki tüm varlıklar bu anahtara göre sözcük temelinde artan düzende sıralanır.All entities within a partition are sorted lexically, in ascending order, by this key. Her varlığın bölüm anahtarı/satır anahtarı bileşimi benzersiz olmalıdır ve uzunluğu 1 KB'yi aşmamalıdır.The partition key/row key combination must be unique for each entity and cannot exceed 1 KB in length.

Varlık daha önce kullanılmamış bir bölüm anahtarıyla tabloya eklenirse, Azure tablo depolaması bu varlık için yeni bir bölüm oluşturur.If an entity is added to a table with a previously unused partition key, Azure table storage creates a new partition for this entity. Aynı bölüm anahtarına sahip olan diğer varlıklar aynı bölümde depolanır.Other entities with the same partition key will be stored in the same partition.

Bu mekanizma otomatik ölçek genişletme stratejisini etkili bir şekilde uygular.This mechanism effectively implements an automatic scale-out strategy. Her bölüm, bir Azure veri merkezinde tek bölümden veri alan sorguların hızlı çalıştırılmasına yardımcı olmak için aynı sunucuda depolanır.Each partition is stored on the same server in an Azure datacenter to help ensure that queries that retrieve data from a single partition run quickly.

Microsoft yayımlanan ölçeklenebilirlik hedefleri Azure depolama için.Microsoft has published scalability targets for Azure Storage. Sisteminizin bu sınırları aşma olasılığı varsa, varlıklar birden çok tabloya bölmeyi göz önünde bulundurun.If your system is likely to exceed these limits, consider splitting entities into multiple tables. Dikey bölümleme kullanarak birlikte erişilme olasılıkları en yüksek olan alanları gruplara ayırın.Use vertical partitioning to divide the fields into the groups that are most likely to be accessed together.

Aşağıdaki diyagramda, örnek depolama hesabının mantıksal yapısı gösterilmektedir.The following diagram shows the logical structure of an example storage account. Depolama hesabı üç tablo içerir: Müşteri bilgileri, ürün bilgileri ve sipariş bilgileri.The storage account contains three tables: Customer Info, Product Info, and Order Info.

Örnek depolama hesabındaki tablolar ve bölümler

Her tablonun birden çok bölümü vardır.Each table has multiple partitions.

  • Müşteri bilgileri tablosunda, veriler müşterinin bulunduğu şehirlere göre bölümlenir.In the Customer Info table, the data is partitioned according to the city where the customer is located. Satır anahtarı müşteri kimliğini içerir.The row key contains the customer ID.
  • Ürün bilgileri tablosunda, ürünler ürün kategorisine göre bölümlenmiştir ve satır anahtarı ürün numarasını içerir.In the Product Info table, products are partitioned by product category, and the row key contains the product number.
  • Sipariş bilgileri tablosunda, siparişler sıra tarihe göre bölümlenmiştir ve satır anahtarı siparişin alındığı zamanı belirtir.In the Order Info table, the orders are partitioned by order date, and the row key specifies the time the order was received. Her bölümde tüm verilerin satır anahtarına göre sıralandığına dikkat edin.Note that all data is ordered by the row key in each partition.

Azure tablo depolaması için varlıklarınızı tasarlarken aşağıdaki noktaları göz önünde bulundurun:Consider the following points when you design your entities for Azure table storage:

  • Bölüm anahtarını ve satır anahtarı verileri nasıl erişilir tarafından seçin.Select a partition key and row key by how the data is accessed. Sorgularınızın çoğunluğunu destekleyen bir bölüm anahtarı/satır anahtarı bileşimi seçin.Choose a partition key/row key combination that supports the majority of your queries. En verimli sorgular bölüm anahtarını ve satır anahtarını belirterek verileri alır.The most efficient queries retrieve data by specifying the partition key and the row key. Bir bölüm anahtarı ve bir dizi satır anahtarı belirten sorgular tek bölümü tarayarak tamamlanabilir.Queries that specify a partition key and a range of row keys can be completed by scanning a single partition. Veriler satır anahtarı sırasına göre tutulduğunda bu görece hızlı çalışır.This is relatively fast because the data is held in row key order. Sorgular hangi bölümün belirtmezseniz, her bölüm taranan gerekir.If queries don't specify which partition to scan, every partition must be scanned.

  • Varlığın tek bir doğal anahtarı varsa, bölüm anahtarı olarak onu kullanın ve satır anahtarı olarak boş bir dize belirtin.If an entity has one natural key, then use it as the partition key and specify an empty string as the row key. Varlığın iki özelliklerini içeren bir bileşik anahtarı varsa, en yavaş değişen özelliği bölüm anahtarını ve satır anahtarı olarak da diğerini seçin.If an entity has a composite key consisting of two properties, select the slowest changing property as the partition key and the other as the row key. Varlığın ikiden fazla anahtar özelliği varsa, bölüm ve satır anahtarlarını oluşturmak için birleştirilmiş özellikleri kullanın.If an entity has more than two key properties, use a concatenation of properties to provide the partition and row keys.

  • Düzenli olarak bölüm ve satır anahtarları yerine alanları kullanarak verilerini aramanız sorguları gerçekleştirmek, uygulamayı düşünün dizin tablosu düzeni, veya dizin oluşturma, Cosmos DB gibi destekleyen farklı bir veri deposu kullanmayı düşünün .If you regularly perform queries that look up data by using fields other than the partition and row keys, consider implementing the Index Table pattern, or consider using a different data store that supports indexing, such as Cosmos DB.

  • Bölüm anahtarlarını oluştururken monoton bir sıra (örneğin, "0001", "0002", "0003") kullanarak oluşturun ve her bölüm yalnızca sınırlı miktarda veri içeriyorsa, Azure tablo depolaması bu bölümleri aynı sunucuda birlikte fiziksel olarak gruplandırabilirsiniz.If you generate partition keys by using a monotonic sequence (such as "0001", "0002", "0003") and each partition only contains a limited amount of data, Azure table storage can physically group these partitions together on the same server. Azure depolama, uygulama bölümleri (aralık sorguları) bir aralıkta arasında sorguları gerçekleştirmek büyük olasılıkla ve bu durum için en iyi duruma getirilmiş varsayar.Azure Storage assumes that the application is most likely to perform queries across a contiguous range of partitions (range queries) and is optimized for this case. Ancak, yeni varlıklar tüm eklemeleri aralığındaki bir sonunda yoğun olası olduğundan bu yaklaşım, etkin noktalarına yol açabilir.However, this approach can lead to hotspots, because all insertions of new entities are likely to be concentrated at one end the contiguous range. Ayrıca ölçeklenebilirliği de azaltabilir.It can also reduce scalability. Yükü daha eşit yaymak için bölüm anahtarını karma göz önünde bulundurun.To spread the load more evenly, consider hashing the partition key.

  • Azure tablo depolaması aynı bölüme ait varlıklar için işlemsel çalışmaları destekler.Azure table storage supports transactional operations for entities that belong to the same partition. Bir uygulama birden çok ekleme, güncelleştirme, Sil, Değiştir veya birleştirme işlemleri bir atomik birim olarak işlemin 100'den fazla varlık içermemesi ve isteğin yükünün 4 MB'yi aşmaması koşuluyla gerçekleştirebilirsiniz.An application can perform multiple insert, update, delete, replace, or merge operations as an atomic unit, as long as the transaction doesn't include more than 100 entities and the payload of the request doesn't exceed 4 MB. Birden çok bölüme yayılan işlemler, işlemsel değildir ve son tutarlılığı gerektirebilir.Operations that span multiple partitions are not transactional, and might require you to implement eventual consistency. Tablo depolama ve işlemler hakkında daha fazla bilgi için bkz: Varlık Grup İşlemleri Gerçekleştirme.For more information about table storage and transactions, see Performing entity group transactions.

  • Bölüm anahtarının ayrıntı göz önünde bulundurun:Consider the granularity of the partition key:

    • Her varlık için aynı bölüm anahtarını kullanarak tek sunucuda tutulan tek bir bölüm sonuçlanır.Using the same partition key for every entity results in a single partition that's held on one server. Bu bölüm, Ölçek genişletmesi engellenir ve yük tek sunucuya odaklanır.This prevents the partition from scaling out and focuses the load on a single server. Sonuç olarak, bu yaklaşım yalnızca az sayıda varlığı depolamak için uygundur.As a result, this approach is only suitable for storing a small number of entities. Ancak, tüm varlıkların varlık grubu işlemlerine katılabilmesi olun.However, it does ensure that all entities can participate in entity group transactions.

    • Her varlık için benzersiz bir bölüm anahtarının kullanılması tablo depolama hizmeti, büyük olasılıkla çok sayıda küçük bölüme bunun sonucunda, her varlık için ayrı bir bölüm oluşturmasına neden olur.Using a unique partition key for every entity causes the table storage service to create a separate partition for each entity, possibly resulting in a large number of small partitions. Bu yaklaşım tek bölüm anahtarı kullanmaktan daha iyi ölçeklenebilir ama varlık grubu işlemleri yapmak mümkün olmaz.This approach is more scalable than using a single partition key, but entity group transactions are not possible. Ayrıca, birden fazla varlık getiren sorguların birden çok sunucudan okuması gerekebilir.Also, queries that fetch more than one entity might involve reading from more than one server. Uygulama aralık sorguları gerçekleştiriyorsa, ancak ardından bölüm anahtarlarını oluştururken monoton bir sıra kullanarak bu sorguların iyileştirilmesine yardımcı olabilir.However, if the application performs range queries, then using a monotonic sequence for the partition keys might help to optimize these queries.

    • Bölüm anahtarı varlıkların bir alt paylaşımı mümkün kılar grubuna ilgili varlıkları aynı bölümde.Sharing the partition key across a subset of entities makes it possible to group related entities in the same partition. İlgili varlıkları içeren işlemler varlık grubu işlemleri kullanılarak gerçekleştirilebilir ve bir dizi ilgili varlığı getiren sorgular tek sunucuya erişerek bunu yapabilirler.Operations that involve related entities can be performed by using entity group transactions, and queries that fetch a set of related entities can be satisfied by accessing a single server.

Daha fazla bilgi için Tablo Depolama Tablo Tasarımı Kılavuzu.For more information, see Azure storage table design guide.

Azure blob depolamasını bölümlemePartitioning Azure blob storage

Azure blob depolama, büyük ikili nesnelerin barındırılmasını mümkün kılar.Azure blob storage makes it possible to hold large binary objects. Blok blobları karşıya yükleme veya büyük hacimli verileri hızlıca yüklemek gereken senaryolarda kullanın.Use block blobs in scenarios when you need to upload or download large volumes of data quickly. Verilerin bölümlerine seri yerine rastgele erişim gerektiren uygulamalar için sayfa bloblarını kullanın.Use page blobs for applications that require random rather than serial access to parts of the data.

Her blob (blok veya sayfa) Azure depolama hesabında bir kapsayıcıda tutulur.Each blob (either block or page) is held in a container in an Azure storage account. Aynı güvenlik gereksinimleri olan birbiriyle ilgili blobları gruplandırmak için kapsayıcıları kullanabilirsiniz.You can use containers to group related blobs that have the same security requirements. Bu gruplandırma fiziksel değil mantıksaldır.This grouping is logical rather than physical. Kapsayıcının içinde, her blobun benzersiz bir adı vardır.Inside a container, each blob has a unique name.

Blobun bölüm anahtarı hesap adı + kapsayıcı adı + blob adı şeklindedir.The partition key for a blob is account name + container name + blob name. Bölüm anahtarı, aralıkları ve bu aralıklar veri yük sistem dengeli bölüm için kullanılır.The partition key is used to partition data into ranges and these ranges are load-balanced across the system. Bloblar, bunlara yönelik erişimin ölçeğini genişletmek için birden çok sunucuya dağıtılabilir, ama tek bir blob tek bir sunucudan hizmet alabilir.Blobs can be distributed across many servers in order to scale out access to them, but a single blob can only be served by a single server.

Zaman damgaları ve sayısal tanımlayıcı adlandırma düzeninizi kullanılıyorsa, açabilir sistemden etkili bir şekilde sınırlama bir bölümüne giderek aşırı trafik için Yük Dengeleme.If your naming scheme uses timestamps or numerical identifiers, it can lead to excessive traffic going to one partition, limiting the system from effectively load balancing. Örneğin, bir blob nesnesi gibi bir zaman damgası ile kullandığınız günlük işlemler varsa yyyy-aa-gg, bu işlem için tüm trafik tek bölüm sunucuya çıkacak.For instance, if you have daily operations that use a blob object with a timestamp such as yyyy-mm-dd, all the traffic for that operation would go to a single partition server. Bunun yerine, 3 haneli karma adını göz önünde bulundurun.Instead, consider prefixing the name with a 3-digit hash. Daha fazla bilgi için bölüm adlandırma kuralıFor more information, see Partition Naming Convention

Bir tek blok veya sayfa yazma eylemleri atomiktir, ama Bloklar, sayfalar veya bloblar arasına yayılan işlemler atomik değildir.The actions of writing a single block or page are atomic, but operations that span blocks, pages, or blobs are not. Bloklar, sayfalar ve bloblar arasında yazma işlemleri gerçekleştirirken tutarlılığı güvence altına almanız gerekiyorsa, bir blob kiralaması kullanarak yazma kilidi alın.If you need to ensure consistency when performing write operations across blocks, pages, and blobs, take out a write lock by using a blob lease.

Azure depolama kuyruklarını bölümlemePartitioning Azure storage queues

Azure depolama kuyrukları işlemler arasında zaman uyumsuz ileti alışverişi gerçekleştirmenize olanak tanır.Azure storage queues enable you to implement asynchronous messaging between processes. Azure depolama hesabı istenen sayıda kuyruk içerebilir ve her kuyruk istenen sayıda ileti içerebilir.An Azure storage account can contain any number of queues, and each queue can contain any number of messages. Tek sınırlama depolama hesabında kullanılabilen alan miktarıdır.The only limitation is the space that's available in the storage account. Tek bir iletinin boyut üst sınırı 64 KB'dir.The maximum size of an individual message is 64 KB. Bundan daha büyük iletilere ihtiyacınız varsa, bunun yerine Azure Service Bus kuyruklarını kullanmayı düşünün.If you require messages bigger than this, then consider using Azure Service Bus queues instead.

Her depolama kuyruğunun bunu içeren depolama hesabı içinde benzersiz bir adı vardır.Each storage queue has a unique name within the storage account that contains it. Azure kuyrukları ada göre bölümler.Azure partitions queues based on the name. Aynı kuyruğun tüm iletileri aynı bölümde depolanır ve bu bölüm tek bir sunucu tarafından denetlenir.All messages for the same queue are stored in the same partition, which is controlled by a single server. Yükü dengelemeye yardımcı olmak için farklı kuyruklar farklı sunucular tarafından yönetilebilir.Different queues can be managed by different servers to help balance the load. Kuyrukların sunuculara ayrılması, uygulamalar ve kullanıcılar açısından saydam bir işlemdir.The allocation of queues to servers is transparent to applications and users.

Büyük ölçekli bir uygulamada, uygulamanın tüm örnekleri için aynı depolama kuyruğunu kullanmayın çünkü bu yaklaşım kuyruğu barındıran sunucunun bir etkin noktaya dönüşmesine neden olabilir.In a large-scale application, don't use the same storage queue for all instances of the application because this approach might cause the server that's hosting the queue to become a hotspot. Bunun yerine, uygulamanın farklı işlevsel alanları için farklı kuyruklar kullanın.Instead, use different queues for different functional areas of the application. Azure depolama kuyrukları işlemleri desteklemez, dolayısıyla iletilerin farklı kuyruklara yönlendirilmesi ileti tutarlılığı üzerinde önemli bir etki yaratmaz.Azure storage queues do not support transactions, so directing messages to different queues should have little impact on messaging consistency.

Azure depolama kuyruğu saniyede en çok 2.000 ileti işleyebilir.An Azure storage queue can handle up to 2,000 messages per second. İletileri bundan daha yüksek bir hızda işlemeniz gerekiyorsa, birden çok kuyruk oluşturmayı göz önünde bulundurun.If you need to process messages at a greater rate than this, consider creating multiple queues. Örneğin, global bir uygulamada her bölgede çalıştırılan uygulama örneklerini işlemek üzere ayrı depolama hesaplarında ayrı depolama kuyrukları oluşturun.For example, in a global application, create separate storage queues in separate storage accounts to handle application instances that are running in each region.

Azure Service Bus bölümlemePartitioning Azure Service Bus

Azure Service Bus, Service Bus kuyruğuna veya konusuna gönderilen iletileri işlemek için bir ileti aracısı kullanır.Azure Service Bus uses a message broker to handle messages that are sent to a Service Bus queue or topic. Varsayılan olarak, kuyruğa veya konuya gönderilen iletiler aynı ileti aracısı işlemiyle işlenir.By default, all messages that are sent to a queue or topic are handled by the same message broker process. Bu mimari ileti kuyruğunun genel aktarım hızına bir sınırlama getirebilir.This architecture can place a limitation on the overall throughput of the message queue. Öte yandan, kuyruğu veya konuyu oluşturulduktan sonra da bölümleyebilirsiniz.However, you can also partition a queue or topic when it is created. Bunu yapmak için kuyruk veya konu açıklamasının EnablePartitioning özelliğini true olarak ayarlarsınız.You do this by setting the EnablePartitioning property of the queue or topic description to true.

Bölümlenmiş bir kuyruk veya konu birden çok parçaya bölünür ve bunların her biri ayrı ileti deposu ve ileti aracısı tarafından desteklenir.A partitioned queue or topic is divided into multiple fragments, each of which is backed by a separate message store and message broker. Service Bus bu parçaları oluşturma ve yönetme sorumluluğunu üstlenir.Service Bus takes responsibility for creating and managing these fragments. Uygulama bölümlenmiş bir sorgu veya konuya ileti gönderdiğinde, Service Bus iletiyi söz konusu kuyruk veya konunun bir parçasına atar.When an application posts a message to a partitioned queue or topic, Service Bus assigns the message to a fragment for that queue or topic. Uygulama bir kuyruk veya abonelikten ileti aldığında, Service Bus kullanılabilir bir sonraki ileti için her parçayı denetler ve ardından bunu işlenmek üzere uygulamaya geçirir.When an application receives a message from a queue or subscription, Service Bus checks each fragment for the next available message and then passes it to the application for processing.

Bu yapı ileti aracıları ve ileti depoları arasında yükü dağıtmaya yardımcı olarak ölçeklenebilirliği artırır ve kullanılabilirliği geliştirir.This structure helps distribute the load across message brokers and message stores, increasing scalability and improving availability. Bir parçanın ileti aracısı veya ileti deposu geçici olarak kullanılamaz durumdaysa, Service Bus iletileri diğer kullanılabilir parçaların birinden alabilir.If the message broker or message store for one fragment is temporarily unavailable, Service Bus can retrieve messages from one of the remaining available fragments.

Service Bus iletiyi bir parçaya şu şekilde atar:Service Bus assigns a message to a fragment as follows:

  • İleti bir oturuma aitse, tüm iletiler için aynı değere sahip SessionID özelliği, aynı parçaya gönderilir.If the message belongs to a session, all messages with the same value for the SessionId property are sent to the same fragment.

  • İleti bir oturuma ait değilse ama gönderen PartitionKey özelliği için bir değer belirtmişse, PartitionKey değeri aynı olan tüm iletiler aynı parçaya gönderilir.If the message does not belong to a session, but the sender has specified a value for the PartitionKey property, then all messages with the same PartitionKey value are sent to the same fragment.

    Not

    SessionId ve PartitionKey özelliklerinin her ikisi de belirtilmişse, bunların aynı değere ayarlanmış olması gerekir yoksa ileti reddedilir.If the SessionId and PartitionKey properties are both specified, then they must be set to the same value or the message will be rejected.

  • İletinin SessionId ve PartitionKey özellikleri belirtilmemişse ama yinelenen öğe algılaması etkinleştirilmişse, MessageId özelliği kullanılır.If the SessionId and PartitionKey properties for a message are not specified, but duplicate detection is enabled, the MessageId property will be used. Aynı MessageId değerine sahip tüm iletiler aynı parçaya yönlendirilir.All messages with the same MessageId will be directed to the same fragment.

  • İletilerin SessionId, PartitionKey veya MessageId özelliği yoksa, Service Bus iletileri parçalara sıralı olarak atar.If messages do not include a SessionId, PartitionKey, or MessageId property, then Service Bus assigns messages to fragments sequentially. Bir parça kullanılamaz durumdaysa Service Bus bir sonraki parçaya geçer.If a fragment is unavailable, Service Bus will move on to the next. Başka bir deyişle, ileti altyapısındaki geçici bir hata ileti gönderme işleminin başarısız olmasına neden olmaz.This means that a temporary fault in the messaging infrastructure does not cause the message-send operation to fail.

Service Bus ileti kuyruğu veya konusunun bölümlenip bölümlenmeyeceğine veya nasıl bölümleneceğine karar verirken aşağıdaki noktaları göz önünde bulundurun:Consider the following points when deciding if or how to partition a Service Bus message queue or topic:

  • Service Bus kuyrukları ve konuları Service Bus ad alanı kapsamında oluşturulur.Service Bus queues and topics are created within the scope of a Service Bus namespace. Service Bus şu anda ad alanı başına en çok 100 bölümlenmiş kuyruğa veya konuya izin vermektedir.Service Bus currently allows up to 100 partitioned queues or topics per namespace.

  • Her Service Bus ad alanı kullanılabilir kaynaklarla ilgili olarak, konu başına abonelik sayısı, saniyede eş zamanlı gönderme ve alma isteklerinin sayısı ve kurulabilecek eş zamanlı bağlantı sayısı üst sınırı gibi kotalar belirler.Each Service Bus namespace imposes quotas on the available resources, such as the number of subscriptions per topic, the number of concurrent send and receive requests per second, and the maximum number of concurrent connections that can be established. Bu kotalar bölümünde belgelendirilen Service Bus kotaları.These quotas are documented in Service Bus quotas. Bu değerleri aşacağınızı tahmin ediyorsanız, kendi kuyrukları ve konularıyla ek ad alanları oluşturun ve çalışmayı bu ad alanlarına yayın.If you expect to exceed these values, then create additional namespaces with their own queues and topics, and spread the work across these namespaces. Örneğin, global bir uygulamada her bölgede ayrı ad alanları oluşturun ve uygulama örneklerini en yakın ad alanındaki kuyrukları ve konuları kullanacak şekilde yapılandırın.For example, in a global application, create separate namespaces in each region and configure application instances to use the queues and topics in the nearest namespace.

  • Bir işlem kapsamında gönderilen iletilerin bölüm anahtarını belirtmesi gerekir.Messages that are sent as part of a transaction must specify a partition key. Bu anahtar SessionId, PartitionKey veya MessageId özelliği olabilir.This can be a SessionId, PartitionKey, or MessageId property. Aynı işlem kapsamında gönderilen tüm iletiler aynı bölüm anahtarını belirtmelidir çünkü bunların aynı ileti aracısı işlemi tarafından işlenmesi gerekir.All messages that are sent as part of the same transaction must specify the same partition key because they must be handled by the same message broker process. Aynı işlem içinde farklı kuyruklara veya konulara ileti gönderemezsiniz.You cannot send messages to different queues or topics within the same transaction.

  • Bölümlenmiş kuyruklar ve konular, boşta kaldıklarında otomatik olarak silinecek şekilde yapılandırılamaz.Partitioned queues and topics can't be configured to be automatically deleted when they become idle.

  • Platformlar arası veya karma çözümler oluşturuyorsanız, bölümlenmiş kuyruklar ve konular şu anda Gelişmiş İleti Sıraya Alma Protokolü (AMQP) ile kullanılamaz.Partitioned queues and topics can't currently be used with the Advanced Message Queuing Protocol (AMQP) if you are building cross-platform or hybrid solutions.

Cosmos DB bölümlemePartitioning Cosmos DB

Azure Cosmos DB, Azure Cosmos DB SQL API'sinin kullanarak JSON belgelerini depolayabilen bir NoSQL veritabanıdır.Azure Cosmos DB is a NoSQL database that can store JSON documents using the Azure Cosmos DB SQL API. Cosmos DB veritabanındaki belge, bir nesnenin veya başka bir veri parçasının seri hale getirilmiş JSON gösterimidir.A document in a Cosmos DB database is a JSON-serialized representation of an object or other piece of data. Her belgenin benzersiz bir kimlik içermesi gereksinimi dışında, zorunlu tutulan sabit şemalar yoktur.No fixed schemas are enforced except that every document must contain a unique ID.

Belgeler, koleksiyonlar halinde düzenlenir.Documents are organized into collections. İlgili belgeleri bir koleksiyonda bir arada gruplandırabilirsiniz.You can group related documents together in a collection. Örneğin, blog gönderilerinin tutulduğu bir sistemde her blog gönderisinin içeriğini koleksiyonda bir belge olarak depolayabilirsiniz.For example, in a system that maintains blog postings, you can store the contents of each blog post as a document in a collection. Ayrıca her konu türü için de koleksiyonlar oluşturabilirsiniz.You can also create collections for each subject type. Alternatif olarak, farklı yazarların kendi blog gönderilerini denetledikleri ve yönettikleri bir sistem gibi çok kiracılı bir uygulamada, blogları yazara göre bölümleyebilir ve her yazar için ayrı koleksiyonlar oluşturabilirsiniz.Alternatively, in a multitenant application, such as a system where different authors control and manage their own blog posts, you can partition blogs by author and create separate collections for each author. Koleksiyonlara ayrılan depolama alanı esnektir ve gerektiğinde küçültülebilir veya büyütülebilir.The storage space that's allocated to collections is elastic and can shrink or grow as needed.

Cosmos DB, uygulamada tanımlanan bölüm anahtarı temelinde verilerin otomatik olarak bölümlenmesini destekler.Cosmos DB supports automatic partitioning of data based on an application-defined partition key. Mantıksal bölüm, tek bir bölüm anahtarı değerinin tüm verilerinin depolandığı bölümdür.A logical partition is a partition that stores all the data for a single partition key value. Bölüm anahtarı olarak aynı değeri paylaşan tüm belgeler aynı mantıksal birim içine yerleştirilir.All documents that share the same value for the partition key are placed within the same logical partition. Cosmos DB değerleri bölüm anahtarının karmasına göre dağıtır.Cosmos DB distributes values according to hash of the partition key. Mantıksal bölümün boyut üst sınırı 10 GB'dir.A logical partition has a maximum size of 10 GB. Dolayısıyla, tasarım zamanında bölüm anahtarı seçimi önemli bir karardır.Therefore, the choice of the partition key is an important decision at design time. Geniş bir değer aralığı ve hatta erişim desenleri olan bir özellik seçin.Choose a property with a wide range of values and even access patterns. Daha fazla bilgi için bkz. Azure Cosmos DB'de bölüm ve ölçek.For more information, see Partition and scale in Azure Cosmos DB.

Not

Her Cosmos DB veritabanının, aldığı kaynakların miktarını belirleyen bir performans düzeyi vardır.Each Cosmos DB database has a performance level that determines the amount of resources it gets. Performans düzeyi bir istek birimi (RU) hız sınırıyla ilişkilendirilmiştir.A performance level is associated with a request unit (RU) rate limit. RU hız sınırı ayrılan ve bu koleksiyonun özel kullanımına sunulan kaynakların miktarını belirtir.The RU rate limit specifies the volume of resources that's reserved and available for exclusive use by that collection. Koleksiyonun maliyeti o koleksiyon için seçilen performans düzeyine bağlıdır.The cost of a collection depends on the performance level that's selected for that collection. Performans düzeyi (ve RU hız sınırı) ne kadar yüksekse ücreti de o kadar yüksek olur.The higher the performance level (and RU rate limit) the higher the charge. Azure Portal'ı kullanarak koleksiyonun performans düzeyini ayarlayabilirsiniz.You can adjust the performance level of a collection by using the Azure portal. Daha fazla bilgi için bkz. Azure Cosmos DB'de İstek Birimleri.For more information, see Request Units in Azure Cosmos DB.

Cosmos DB'nin sağladığı bölümleme mekanizması yeterli değilse, uygulama düzeyinde verileri parçaya gerekebilir.If the partitioning mechanism that Cosmos DB provides is not sufficient, you may need to shard the data at the application level. Belge koleksiyonları, tek bir veritabanı içinde verileri bölümlemek için doğal bir mekanizma sağlar.Document collections provide a natural mechanism for partitioning data within a single database. Parçalama yöntemini uygulamanın en basit yolu, her parça için bir koleksiyon oluşturmaktır.The simplest way to implement sharding is to create a collection for each shard. Kapsayıcılar mantıksal kaynaklardır ve bir veya birden çok sunucuya yayılabilir.Containers are logical resources and can span one or more servers. Sabit boyutlu kapsayıcıların üst sınırı 10 GB ve 10.000 RU/sn aktarım hızıdır.Fixed-size containers have a maximum limit of 10 GB and 10,000 RU/s throughput. Sınırsız kapsayıcılar en fazla depolama boyutunu yoktur, ancak bir bölüm anahtarı belirtmeniz gerekir.Unlimited containers do not have a maximum storage size, but must specify a partition key. Uygulama parçalama yöntemiyle, istemci uygulamasının genellikle verilerin parça anahtarını tanımlayan bazı özniteliklerini temel alıp kendi eşleme mekanizmasını uygulayarak, istekleri uygun parçaya yönlendirmesi gerekir.With application sharding, the client application must direct requests to the appropriate shard, usually by implementing its own mapping mechanism based on some attributes of the data that define the shard key.

Tüm veritabanları bir Cosmos DB veritabanı hesabı bağlamında oluşturulur.All databases are created in the context of a Cosmos DB database account. Tek bir hesap çeşitli veritabanları içerebilir ve veritabanlarının hangi bölgelerde oluşturulduğunu belirtir.A single account can contain several databases, and it specifies in which regions the databases are created. Her hesap ayrıca kendi erişim denetimini de zorlar.Each account also enforces its own access control. Cosmos DB hesaplarını kullanarak parçaları (veritabanlarının içindeki koleksiyonlar) bunlara erişmesi gereken kullanıcıların coğrafi olarak yakınına yerleştirebilir ve yalnızca söz konusu kullanıcıların bunlara bağlanabilmesini sağlayacak kısıtlamaları zorlayabilirsiniz.You can use Cosmos DB accounts to geo-locate shards (collections within databases) close to the users who need to access them, and enforce restrictions so that only those users can connect to them.

Verileri CosmosDB SQL API'si ile nasıl bölümleyeceğinize karar verirken aşağıdaki noktaları göz önünde bulundurun:Consider the following points when deciding how to partition data with the Cosmos DB SQL API:

  • Cosmos DB'ye sağlanan kaynaklar hesabın kota sınırlamalarına tabidir.The resources available to a Cosmos DB database are subject to the quota limitations of the account. Her veritabanı bir dizi koleksiyon barındırabilir ve her koleksiyon, o koleksiyonun RU hız sınırını (ayrılmış aktarım hızı) belirleyen bir performans düzeyiyle ilişkilendirilmiştir.Each database can hold a number of collections, and each collection is associated with a performance level that governs the RU rate limit (reserved throughput) for that collection. Daha fazla bilgi için bkz. Azure aboneliği ve hizmet sınırları, kotaları ve kısıtlamaları.For more information, see Azure subscription and service limits, quotas, and constraints.

  • Her belgenin içinde bulunduğu koleksiyonda onu benzersiz olarak tanımlamak için kullanılabilecek bir özniteliği olmalıdır.Each document must have an attribute that can be used to uniquely identify that document within the collection in which it is held. Bu öznitelik, belgenin hangi koleksiyonda tutulduğunu tanımlayan parça anahtarından farklıdır.This attribute is different from the shard key, which defines which collection holds the document. Koleksiyon çok fazla sayıda belge içerebilir.A collection can contain a large number of documents. Teorik olarak, bunu sınırlayan tek öğe belge kimliğinin uzunluk üst sınırıdır.In theory, it's limited only by the maximum length of the document ID. Belge kimliği en çok 255 karakter olabilir.The document ID can be up to 255 characters.

  • Belge üzerindeki tüm işlemler, bir işlemin bağlamı içinde gerçekleştirilir. İşlemlerin kapsamı belgeyi içeren koleksiyon olarak belirlenir.All operations against a document are performed within the context of a transaction. Transactions are scoped to the collection in which the document is contained. İşlem başarısız olursa, gerçekleştirdiği çalışma geri alınır.If an operation fails, the work that it has performed is rolled back. Belge üzerinde bir işlem yapılırken, tüm değişiklikler anlık görüntü düzeyi yalıtıma tabidir.While a document is subject to an operation, any changes that are made are subject to snapshot-level isolation. Bu mekanizma, örneğin bir yeni belge oluşturma isteği başarısız olursa aynı anda veritabanını sorgulayan başka bir kullanıcı daha sonra kaldırılacak olan kısmi belgeyi görmez.This mechanism guarantees that if, for example, a request to create a new document fails, another user who's querying the database simultaneously will not see a partial document that is then removed.

  • Veritabanı sorgularının kapsamı da koleksiyon düzeyinde belirlenir.Database queries are also scoped to the collection level. Tek bir sorgu tek bir koleksiyondan veri alabilir.A single query can retrieve data from only one collection. Birden çok koleksiyondan veri almanız gerekiyorsa, her koleksiyonu tek tek sorgulamalı ve sonuçları uygulama kodunuzda birleştirmelisiniz.If you need to retrieve data from multiple collections, you must query each collection individually and merge the results in your application code.

  • Cosmos DB, tümü belgelerle birlikte bir koleksiyonda depolanabilen programlanabilir öğeleri destekler.Cosmos DB supports programmable items that can all be stored in a collection alongside documents. Bunlar saklı yordamlar, kullanıcı tanımlı işlevler ve tetikleyicilerdir (JavaScript'te yazılmış).These include stored procedures, user-defined functions, and triggers (written in JavaScript). Bu öğeler aynı koleksiyon içindeki tüm belgelere erişebilir.These items can access any document within the same collection. Üstelik, bu öğeler çevreleyen işlemin kapsamı içinde (belge üzerinde gerçekleştirilen bir oluşturma, silme veya değiştirme işleminin sonucu olarak çalıştırılan bir tetikleyici söz konusu olduğunda) veya yeni bir işlem başlatılarak çalıştırılır (açık bir istemci isteğinin sonucu olarak çalıştırılan bir saklı yordam söz konusu olduğunda).Furthermore, these items run either inside the scope of the ambient transaction (in the case of a trigger that fires as the result of a create, delete, or replace operation performed against a document), or by starting a new transaction (in the case of a stored procedure that is run as the result of an explicit client request). Programlanabilir öğenin kodu bir özel durum oluşturursa, işlem geri alınır.If the code in a programmable item throws an exception, the transaction is rolled back. Belgeler arasındaki bütünlüğü ve tutarlılığı korumak için saklı yordamları ve tetikleyicileri kullanabilirsiniz, ama söz konusu belgelerin aynı koleksiyonun parçası olması gerekir.You can use stored procedures and triggers to maintain integrity and consistency between documents, but these documents must all be part of the same collection.

  • Veritabanlarında tutmak istediğiniz koleksiyonlar, koleksiyonların performans düzeyi tarafından tanımlanan aktarım hızı sınırlarını aşmayacak gibi olmalıdır.The collections that you intend to hold in the databases should be unlikely to exceed the throughput limits defined by the performance levels of the collections. Daha fazla bilgi için bkz. Azure Cosmos DB'de İstek Birimleri.For more information, see Request Units in Azure Cosmos DB. Bu sınırlara ulaşılacağını düşünüyorsanız, koleksiyon başına düşen yükü azaltmak için koleksiyonları farklı hesaplardaki veritabanları arasında bölmeyi göz önünde bulundurun.If you anticipate reaching these limits, consider splitting collections across databases in different accounts to reduce the load per collection.

Veriler için arama yapabilme özelliği çoğunlukla birçok web uygulamasının sağladığı birincil gezinme ve keşif yöntemidir.The ability to search for data is often the primary method of navigation and exploration that's provided by many web applications. Kullanıcıların arama ölçütü bileşimleri temelinde kaynakları (örneğin, e-ticaret uygulamasında ürünleri) hızla bulabilmesine yardımcı olur.It helps users find resources quickly (for example, products in an e-commerce application) based on combinations of search criteria. Azure Search hizmeti web içeriği üzerinde tam metin araması özellikleri sağlar ve yazarken tamamlama, yakın eşleşmeler temelinde önerilen sorgular ve çok yönlü gezinme gibi özellikler içerir.The Azure Search service provides full-text search capabilities over web content, and includes features such as type-ahead, suggested queries based on near matches, and faceted navigation. Daha fazla bilgi için Azure Search nedir?.For more information, see What is Azure Search?.

Azure Search aranabilir içeriği bir veritabanında JSON belgeleri olarak depolar.Azure Search stores searchable content as JSON documents in a database. Bu belgelerdeki aranabilir alanları belirten dizinleri siz tanımlar ve bu tanımları Azure Search'e sağlarsınız.You define indexes that specify the searchable fields in these documents and provide these definitions to Azure Search. Kullanıcı arama isteği gönderdiğinde, Azure Search eşleşen öğeleri bulmak için uygun dizinleri kullanır.When a user submits a search request, Azure Search uses the appropriate indexes to find matching items.

Çekişmeyi azaltmak için, Azure Search tarafından kullanılan depolama 1, 2, 3, 4, 6 veya 12 bölüme ayrılabilir ve her bölüm en çok 6 kez çoğaltılabilir.To reduce contention, the storage that's used by Azure Search can be divided into 1, 2, 3, 4, 6, or 12 partitions, and each partition can be replicated up to 6 times. Bölüm sayısının çoğaltma sayısıyla çarpımından elde edilen sayı arama birimi (SU) olarak adlandırılır.The product of the number of partitions multiplied by the number of replicas is called the search unit (SU). Tek bir Azure Search örneği en çok 36 SU içerebilir (12 bölümün bulunduğu bir veritabanı yalnızca en çok 3 çoğaltmayı destekler).A single instance of Azure Search can contain a maximum of 36 SUs (a database with 12 partitions only supports a maximum of 3 replicas).

Hizmetinize ayrılmış her SU için faturalandırılırsınız.You are billed for each SU that is allocated to your service. Aranabilir içeriğin miktarı veya arama isteklerinin hızı arttıkça, fazla yükü işlemek için Azure Search'ün mevcut örneğine SU ekleyebilirsiniz.As the volume of searchable content increases or the rate of search requests grows, you can add SUs to an existing instance of Azure Search to handle the extra load. Azure Search belgeleri bölümler arasında kendisi eşit olarak dağıtır.Azure Search itself distributes the documents evenly across the partitions. Şu anda el ile bölümleme stratejileri desteklenmemektedir.No manual partitioning strategies are currently supported.

Her bölüm en çok 15 milyon belge içerebilir veya 300 GB depolama alanı kaplayabilir (hangisi daha küçükse).Each partition can contain a maximum of 15 million documents or occupy 300 GB of storage space (whichever is smaller). En çok 50 dizin oluşturabilirsiniz.You can create up to 50 indexes. Hizmetin performansı değişiklik gösterir ve belgelerin karmaşıklığına, kullanılabilir dizinlere ve ağ gecikmesinin etkilerine bağlıdır.The performance of the service varies and depends on the complexity of the documents, the available indexes, and the effects of network latency. Ortalama olarak, tek bir çoğaltmanın (1 SU) saniyede 15 sorguyu (QPS) işleyebilmesi gerekir; ancak daha kesin bir aktarım hızı ölçümü elde etmek için kendi verilerinizle karşılaştırmalı testler yapmanızı öneririz.On average, a single replica (1 SU) should be able to handle 15 queries per second (QPS), although we recommend performing benchmarking with your own data to obtain a more precise measure of throughput. Daha fazla bilgi için Azure Search'te hizmet sınırları.For more information, see Service limits in Azure Search.

Not

Aranabilir belgelerde dizeler, Boole, sayısal veriler, tarih saat verileri ve bazı coğrafi veriler gibi sınırlı bir veri türü kümesini depolayabilirsiniz.You can store a limited set of data types in searchable documents, including strings, Booleans, numeric data, datetime data, and some geographical data. Diğer ayrıntılar için Microsoft web sitesinin Desteklenen veri türleri (Azure Search) sayfasına bakın.For more details, see the page Supported data types (Azure Search) on the Microsoft website.

Azure Search'ün hizmetin her örneği için verileri bölümleme şekli üzerinde sınırlı bir denetiminiz vardır.You have limited control over how Azure Search partitions data for each instance of the service. Bununla birlikte, genel bir ortamda aşağıdaki stratejilerden birini kullanıp hizmetin kendisini bölümleyerek performansı daha fazla geliştirebilir, gecikmeyi ve çekişmeyi daha da azaltabilirsiniz:However, in a global environment you might be able to improve performance and reduce latency and contention further by partitioning the service itself using either of the following strategies:

  • Her coğrafi bölgede Azure Search'ün bir örneğini oluşturun ve istemci uygulamalarının kullanılabilir en yakın örneğe yönlendirildiğinden emin olun.Create an instance of Azure Search in each geographic region, and ensure that client applications are directed towards the nearest available instance. Bu strateji aranabilir içerikte yapılan tüm güncelleştirmelerin zaman geçirmeden hizmetin tüm örneklerine çoğaltılmasını gerektirir.This strategy requires that any updates to searchable content are replicated in a timely manner across all instances of the service.

  • Azure Search'ün iki katmanını oluşturun:Create two tiers of Azure Search:

    • Bölgedeki kullanıcılar tarafından en sık erişilen verilerin bulunduğu her bölgede yerel bir hizmet.A local service in each region that contains the data that's most frequently accessed by users in that region. Kullanıcılar hızlı ancak sınırlı sonuçlar almak için istekleri buraya yönlendirebilir.Users can direct requests here for fast but limited results.
    • Tüm verileri kapsayan genel bir hizmet.A global service that encompasses all the data. Kullanıcılar daha yavaş ancak daha eksiksiz sonuçlar almak için istekleri buraya yönlendirebilir.Users can direct requests here for slower but more complete results.

Bu yaklaşım, aranan verilerde önemli bölgesel değişikliklerin olduğu durumlara çok uygundur.This approach is most suitable when there is a significant regional variation in the data that's being searched.

Azure Redis önbelleğini bölümlemePartitioning Azure Redis Cache

Azure Redis Cache bulutta Redis anahtar-değer veri deposu temelinde bir paylaşılan önbellek hizmeti sağlar.Azure Redis Cache provides a shared caching service in the cloud that's based on the Redis key-value data store. Adından da anlaşılacağı gibi, Azure Redis Cache bir önbellek çözümü olarak tasarlanmıştır.As its name implies, Azure Redis Cache is intended as a caching solution. Bunu kalıcı bir veri deposu olarak değil yalnızca geçici verileri tutmak için kullanın.Use it only for holding transient data and not as a permanent data store. Azure Redis Cache kullanan uygulamalar, önbellek kullanılamaz duruma gelirse çalışmaya devam edebilmelidir.Applications that utilize Azure Redis Cache should be able to continue functioning if the cache is unavailable. Azure Redis Cache yüksek kullanılabilirlik sağlamak için birincil/ikincil çoğaltmayı destekler ama şu anda önbellek boyutu üst sınırı 53 GB'dir.Azure Redis Cache supports primary/secondary replication to provide high availability, but currently limits the maximum cache size to 53 GB. Bundan daha fazla alana ihtiyacınız varsa, ek önbellekler oluşturmalısınız.If you need more space than this, you must create additional caches. Daha fazla bilgi için Azure Redis Önbelleği.For more information, see Azure Redis Cache.

Redis veri deposunu bölümleme işlemi verileri Redis hizmetinin örnekleri arasında bölmeyi içerir.Partitioning a Redis data store involves splitting the data across instances of the Redis service. Her örnek tek bir bölüm oluşturur.Each instance constitutes a single partition. Azure Redis Cache, Redis hizmetlerini bir dış görünüş ardında tutar ve doğrudan ortaya koymaz.Azure Redis Cache abstracts the Redis services behind a façade and does not expose them directly. Bölümleme gerçekleştirmenin en basit yolu birden çok Azure Redis Cache örneği oluşturmak ve verileri bunların arasında yaymaktır.The simplest way to implement partitioning is to create multiple Azure Redis Cache instances and spread the data across them.

Her veri öğesini, bu veri öğesinin depolandığı önbelleği belirten bir tanımlayıcıyla (bölüm anahtarı) ilişkilendirebilirsiniz.You can associate each data item with an identifier (a partition key) that specifies which cache stores the data item. İstemci uygulama mantığı da bu tanımlayıcıyı kullanarak istekleri uygun bölüme yönlendirebilir.The client application logic can then use this identifier to route requests to the appropriate partition. Bu çok basit bir düzendir ama bölümleme düzeni değişirse (örneğin, ek Azure Redis Cache örnekleri oluşturulursa), istemci uygulamalarının yeniden yapılandırılması gerekebilir.This scheme is very simple, but if the partitioning scheme changes (for example, if additional Azure Redis Cache instances are created), client applications might need to be reconfigured.

Yerel Redis (Azure Redis Cache değil), Redis kümeleme özelliği temelinde sunucu tarafı bölümlemeyi destekler.Native Redis (not Azure Redis Cache) supports server-side partitioning based on Redis clustering. Bu yaklaşımda, karma mekanizmasını kullanarak verileri sunucular arasında eşit bölebilirsiniz.In this approach, you can divide the data evenly across servers by using a hashing mechanism. Her Redis sunucusu bölümde tutulan karma anahtar aralığını açıklayan meta verileri depolar ve aynı zamanda diğer sunuculardaki bölümlerde hangi karma anahtarların bulunduğu hakkında da bilgi içerir.Each Redis server stores metadata that describes the range of hash keys that the partition holds, and also contains information about which hash keys are located in the partitions on other servers.

İstemci uygulamaları istekleri doğrudan herhangi bir katılımcı Redis sunucusuna (büyük olasılıkla en yakındakine) gönderir.Client applications simply send requests to any of the participating Redis servers (probably the closest one). Redis sunucusu, istemci isteğini inceler.The Redis server examines the client request. Yerel olarak çözülebiliyorsa, istenen işlemi gerçekleştirir.If it can be resolved locally, it performs the requested operation. Aksi takdirde isteği uygun sunucuya iletir.Otherwise it forwards the request on to the appropriate server.

Bu model Redis kümeleme özelliği kullanılarak gerçekleştirilir ve Redis web sitesinin Redis küme öğreticisi sayfasında daha ayrıntılı olarak açıklanır.This model is implemented by using Redis clustering, and is described in more detail on the Redis cluster tutorial page on the Redis website. Redis kümeleme özelliği istemci uygulamaları için saydamdır.Redis clustering is transparent to client applications. İstemcileri yeniden yapılandırmanız gerekmeden kümeye başka Redis sunucuları eklenebilir (ve veriler yeniden bölümlenebilir).Additional Redis servers can be added to the cluster (and the data can be re-partitioned) without requiring that you reconfigure the clients.

Önemli

Azure Redis Cache şu anda Redis kümeleme özelliğini desteklememektedir.Azure Redis Cache does not currently support Redis clustering. Bu yaklaşımı Azure'la gerçekleştirmek isterseniz, Redis'i bir dizi Azure sanal makinesine yükleyerek ve el ile yapılandırarak kendi Redis sunucularınızı gerçekleştirmeniz gerekir.If you want to implement this approach with Azure, then you must implement your own Redis servers by installing Redis on a set of Azure virtual machines and configuring them manually. Sayfa azure'da CentOS Linux sanal makinesinde Redis'i çalıştırma oluşturun ve bir Azure sanal makinesi çalıştırılan Redis düğümünün yapılandırma gösteren bir örnek gösterilmektedir.The page Running Redis on a CentOS Linux VM in Azure walks through an example that shows you how to build and configure a Redis node running as an Azure VM.

Redis web sitesinin Bölümleme: verileri birden çok Redis örneği arasında bölme sayfasında, Redis ile bölümlemeyi gerçekleştirme hakkında daha fazla bilgi sağlanır.The page Partitioning: how to split data among multiple Redis instances on the Redis website provides more information about implementing partitioning with Redis. Bu bölümün kalanında, istemci tarafı veya ara sunucu destekli bölümleme gerçekleştirdiğiniz varsayılmıştır.The remainder of this section assumes that you are implementing client-side or proxy-assisted partitioning.

Verileri Azure Redis Cache ile nasıl bölümleyeceğinize karar verirken aşağıdaki noktaları göz önünde bulundurun:Consider the following points when deciding how to partition data with Azure Redis Cache:

  • Azure Redis Cache'in kalıcı bir veri deposu olması hedeflenmemiştir, dolayısıyla hangi bölümleme düzenini gerçekleştirirseniz gerçekleştirin uygulama kodunuzun verileri önbellek olmayan bir konumdan alabilmesi gerekir.Azure Redis Cache is not intended to act as a permanent data store, so whatever partitioning scheme you implement, your application code must be able to retrieve data from a location that's not the cache.

  • Sık sık birlikte erişilen veriler aynı bölümde tutulmalıdır.Data that is frequently accessed together should be kept in the same partition. Redis verileri yapılandırmak için son derece iyileştirilmiş çeşitli mekanizmalar sağlayan güçlü bir anahtar-değer deposudur.Redis is a powerful key-value store that provides several highly optimized mechanisms for structuring data. Bu mekanizmalar aşağıdakilerden biri olabilir:These mechanisms can be one of the following:

    • Basit dizeler (uzunluğu en çok 512 MB olan basit dizeler)Simple strings (binary data up to 512 MB in length)
    • Listeler gibi toplam değerler (kuyruk veya yığın işlevi görebilir)Aggregate types such as lists (which can act as queues and stacks)
    • Kümeler (sıralanmış veya sıralanmamış)Sets (ordered and unordered)
    • Karmalar (bir nesnedeki alanları temsil eden öğeler gibi, ilgili alanları birlikte gruplandırabilir)Hashes (which can group related fields together, such as the items that represent the fields in an object)
  • Toplam değer türleri birçok ilgili değeri aynı anahtarla ilişkilendirmenize olanak tanır.The aggregate types enable you to associate many related values with the same key. Redis anahtarı bir listeyi, kümeyi veya karmayı tanımlar; içerdiği veri öğelerini tanımlamaz.A Redis key identifies a list, set, or hash rather than the data items that it contains. Bu türlerin hepsi Azure Redis Cache ile kullanılabilir ve Redis web sitesinin Veri türleri sayfasında açıklanmaktadır.These types are all available with Azure Redis Cache and are described by the Data types page on the Redis website. Örneğin, bir e-ticaret sisteminin müşterilerin verdiği siparişleri izleyen bölümünde her müşterinin ayrıntıları müşteri kimliği kullanılarak anahtarlanan bir Redis karmasında depolanabilir.For example, in part of an e-commerce system that tracks the orders that are placed by customers, the details of each customer can be stored in a Redis hash that is keyed by using the customer ID. Her karma müşteri için bir sipariş kimlikleri koleksiyonu barındırabilir.Each hash can hold a collection of order IDs for the customer. Siparişler, yine karma olarak yapılandırılmış ve sipariş kimliği kullanılarak anahtarlanmış ayrı bir Redis kümesinde tutulabilir.A separate Redis set can hold the orders, again structured as hashes, and keyed by using the order ID. Şekil 8'de bu yapı gösterilmiştir.Figure 8 shows this structure. Redis'in herhangi bir biçimde başvurusal bütünlük gerçekleştirmediğine, dolayısıyla müşterilerle siparişler arasındaki ilişkileri korumanın geliştiricinin sorumluluğunda olduğuna dikkat edin.Note that Redis does not implement any form of referential integrity, so it is the developer's responsibility to maintain the relationships between customers and orders.

Redis depolamasında müşteri siparişlerini ve bunların ayrıntılarını kaydetmek için önerilen yapı

Şekil 8. Redis depolamasında müşteri siparişlerini ve bunların ayrıntılarını kaydetmek için önerilen yapı.Figure 8. Suggested structure in Redis storage for recording customer orders and their details.

Not

Redis'de, tüm anahtarlar ikili veri değerleridir (Redis dizeleri gibi) ve en çok 512 MB veri içerebilir.In Redis, all keys are binary data values (like Redis strings) and can contain up to 512 MB of data. Teorik olarak, bir anahtar hemen her bilgiyi içerebilir.In theory, a key can contain almost any information. Bununla birlikte, anahtarlar için verilerin türünü açıklayan ve varlığı tanımlayan (ama aşırı uzun olmayan), tutarlı bir adlandırma kuralı benimsenmesini öneririz.However, we recommend adopting a consistent naming convention for keys that is descriptive of the type of data and that identifies the entity, but is not excessively long. Yaygın bir yaklaşım "varlık_türü:kimlik" biçiminde anahtarlar kullanmaktır.A common approach is to use keys of the form "entity_type:ID". Örneğin, kimliği 99 olan bir müşterinin anahtarını belirtmek için "müşteri:99" kullanabilirsiniz.For example, you can use "customer:99" to indicate the key for a customer with the ID 99.

  • İlgili bilgileri aynı veritabanının farklı toplamalarında depolayarak dikey bölümleme gerçekleştirebilirsiniz.You can implement vertical partitioning by storing related information in different aggregations in the same database. Örneğin bir e-ticaret uygulamasında, ürünler hakkında sık erişilen bilgileri bir Redis karmasında ve daha seyrek erişilen ayrıntılı bilgileri bir diğerinde depolayabilirsiniz.For example, in an e-commerce application, you can store commonly accessed information about products in one Redis hash and less frequently used detailed information in another. Her iki karma da anahtarın bir parçası olarak aynı ürün kimliğini kullanabilir.Both hashes can use the same product ID as part of the key. Örneğin, kullanabilirsiniz "Ürün: nn" (burada nn ürün kimliğidir) ürün bilgileri için ve "ürün_ayrıntıları: nn" ayrıntılı veriler için.For example, you can use "product: nn" (where nn is the product ID) for the product information and "product_details: nn" for the detailed data. Bu strateji çoğu sorgunun alma olasılığı yüksek olan verilerin hacmini azaltmanıza yardımcı olabilir.This strategy can help reduce the volume of data that most queries are likely to retrieve.

  • Redis veri deposunu yeniden bölümleyebilirsiniz, ama bunun karmaşık ve zaman alan bir görev olduğunu unutmayın.You can repartition a Redis data store, but keep in mind that it's a complex and time-consuming task. Redis kümeleme verileri otomatik olarak yeniden bölümleyebilir ama bu özellik Azure Redis Cache'te sağlanmaz.Redis clustering can repartition data automatically, but this capability is not available with Azure Redis Cache. Dolayısıyla, bölümleme düzeninizi tasarlarken zamanla beklenen veri artışına yer sağlamak için her bölümde yeterli boş alan bırakmayı deneyin.Therefore, when you design your partitioning scheme, try to leave sufficient free space in each partition to allow for expected data growth over time. Öte yandan, Azure Redis Cache'in verileri geçici olarak önbelleğe almaya yönelik olduğunu ve önbellekte tutulan verilerin yaşam süresi (TTL) değeri olarak belirtilen sınırlı bir yaşam süresi olabileceğini unutmayın.However, remember that Azure Redis Cache is intended to cache data temporarily, and that data held in the cache can have a limited lifetime specified as a time-to-live (TTL) value. Daha geçici olan verilerde TTL kısa olabilir ama statik veriler için TTL çok uzun olabilir.For relatively volatile data, the TTL can be short, but for static data the TTL can be a lot longer. Yaşam süresi uzun olan verilerin önbelleği doldurma olasılığı varsa, önbellekte böyle verilerden çok büyük miktarda depolamayın.Avoid storing large amounts of long-lived data in the cache if the volume of this data is likely to fill the cache. Azure Redis Cache'in alan konusu önem kazandığında verileri kaldırmasına neden olacak bir çıkarma kuralı belirtebilirsiniz.You can specify an eviction policy that causes Azure Redis Cache to remove data if space is at a premium.

    Not

    Azure Redis Cache kullanırken, uygun fiyat katmanını seçerek önbellek boyutu üst sınırı (250 MB ile 53 GB arasında) belirtirsiniz.When you use Azure Redis cache, you specify the maximum size of the cache (from 250 MB to 53 GB) by selecting the appropriate pricing tier. Öte yandan, Azure Redis Cache oluşturulduktan sonra boyutunu artıramaz veya azaltamazsınız.However, after an Azure Redis Cache has been created, you cannot increase (or decrease) its size.

  • Redis toplu işleri ve işlemleri birden çok bağlantıya yayılamaz, dolayısıyla bir toplu işin veya işlemin etkilediği tüm verilerin aynı veritabanında (parçada) tutulması gerekir.Redis batches and transactions cannot span multiple connections, so all data that is affected by a batch or transaction should be held in the same database (shard).

    Not

    Redis işlemi kapsamındaki bir işlem dizisinin atomik olması gerekmez.A sequence of operations in a Redis transaction is not necessarily atomic. İşlemi oluşturan komutlar çalıştırılmadan önce doğrulanır ve kuyruğa alınır.The commands that compose a transaction are verified and queued before they run. Bu aşamada bir hata oluşursa, kuyruğun tamamı atılır.If an error occurs during this phase, the entire queue is discarded. Bununla birlikte, işlem başarıyla gönderildikten sonra kuyruğa alınmış komutlar sırayla çalıştırılır.However, after the transaction has been successfully submitted, the queued commands run in sequence. Komutlardan herhangi biri başarısız olursa, yalnızca o komutun çalıştırılması durdurulur.If any command fails, only that command stops running. Kuyrukta ondan önceki ve sonraki tüm komutlar gerçekleştirilir.All previous and subsequent commands in the queue are performed. Daha fazla bilgi için Redis web sitesinin İşlemler sayfasına gidin.For more information, go to the Transactions page on the Redis website.

  • Redis sınırlı sayıda atomik işlemi destekler.Redis supports a limited number of atomic operations. Bu tür işlemler arasında birden çok anahtar ve değeri desteleyen yalnızca MGET ve MSET işlemleridir.The only operations of this type that support multiple keys and values are MGET and MSET operations. MGET işlemleri belirtilen bir anahtar listesi için değer koleksiyonunu döndürür ve MSET işlemleri de belirtilen anahtar listesi için değer koleksiyonunu depolar.MGET operations return a collection of values for a specified list of keys, and MSET operations store a collection of values for a specified list of keys. Bu işlemleri kullanmanız gerekirse, MSET ve MGET komutlarının başvurduğu anahtar-değer çiftlerinin aynı veritabanının içinde depolanmış olması gerekir.If you need to use these operations, the key-value pairs that are referenced by the MSET and MGET commands must be stored within the same database.

Azure Service Fabric bölümlemePartitioning Azure Service Fabric

Azure Service Fabric bulutta dağıtılmış uygulamalar için çalışma zamanı sağlayan bir mikro hizmet platformudur.Azure Service Fabric is a microservices platform that provides a runtime for distributed applications in the cloud. Service Fabric .Net konuk yürütülebilir dosyalarını, durum bilgisi olan ve olmayan hizmetleri ve kapsayıcıları destekler.Service Fabric supports .Net guest executables, stateful and stateless services, and containers. Durum bilgisi olan hizmetler, verileri Service Fabric kümesi içindeki bir anahtar-değer koleksiyonunda kalıcı olarak depolamak için güvenilir bir koleksiyon sağlar.Stateful services provide a reliable collection to persistently store data in a key-value collection within the Service Fabric cluster. Güvenilir bir koleksiyondaki bölümleme anahtarları stratejileri hakkında daha fazla bilgi için bkz. Azure Service fabric'te güvenilir koleksiyonlar için yönergeler ve öneriler.For more information about strategies for partitioning keys in a reliable collection, see guidelines and recommendations for reliable collections in Azure Service Fabric.

Daha fazla bilgiMore information

Azure olay hub'larının bölümlemePartitioning Azure Event Hubs

Azure Event Hubs çok büyük ölçeklerde veri akışı için tasarlanmıştır ve yatay ölçeklendirmeye olanak tanımak için bölümleme özelliği hizmette yerleşik olarak bulunur.Azure Event Hubs is designed for data streaming at massive scale, and partitioning is built into the service to enable horizontal scaling. Her tüketici ileti akışının yalnızca belirli bir bölümünü okur.Each consumer only reads a specific partition of the message stream.

Olay yayımcısı yalnızca bölüm anahtarını bilir, olayların yayımlandığı bölümü bilmez.The event publisher is only aware of its partition key, not the partition to which the events are published. Anahtar ile bölümün bu şekilde ayrılması göndereni aşağı akış işleme hakkında çok fazla bilgi sahibi olma gereksiniminden kurtarır.This decoupling of key and partition insulates the sender from needing to know too much about the downstream processing. (Olayları doğrudan belirli bir bölüme göndermek de mümkündür ama genel olarak önerilmez.)(It's also possible send events directly to a given partition, but generally that's not recommended.)

Bölüm sayısını seçerken uzun vadeli ölçeği göz önünde bulundurun.Consider long-term scale when you select the partition count. Olay hub'ı oluşturulduktan sonra, bölümlerin sayısını değiştiremezsiniz.After an event hub is created, you can't change the number of partitions.

Event Hubs'da bölümleri kullanma hakkında daha fazla bilgi için bkz. Event Hubs nedir?.For more information about using partitions in Event Hubs, see What is Event Hubs?.

Kullanılabilirlik ile tutarlılık arasındaki denge hakkında dikkate alınacak noktalar için bkz. Event Hubs’da kullanılabilirlik ve tutarlılık.For considerations about trade-offs between availability and consistency, see Availability and consistency in Event Hubs.