Yatay, dikey ve işlevsel veri bölümlemeHorizontal, vertical, and functional data partitioning

Veri bölünmüştür birçok büyük ölçekli çözümde bölümleri , yönetilebilir ve ayrı olarak erişilebilir.In many large-scale solutions, data is divided into partitions that can be managed and accessed separately. Bölümleme ölçeklenebilirliği artırabilir çekişmeyi azaltmak ve performansı en iyi duruma getirme.Partitioning can improve scalability, reduce contention, and optimize performance. Kullanım desenine göre bölme veriler için bir mekanizma da sağlayabilir.It can also provide a mechanism for dividing data by usage pattern. Örneğin, eski verileri daha ucuz veri depolamasında arşivleyebilirsiniz.For example, you can archive older data in cheaper data storage.

Ancak, bölümleme stratejisi olumsuz etkileri en aza yararlarını en üst düzeye çıkarmak için dikkatle seçilmelidir.However, the partitioning strategy must be chosen carefully to maximize the benefits while minimizing adverse effects.

Not

Bu makalede bölümleme terimi, verileri fiziksel olarak ayrı veri depolarına bölme işlemi anlamına gelir.In this article, the term partitioning means the process of physically dividing data into separate data stores. Bu, SQL Server tablo bölümleme terimiyle aynı değildir.It is not the same as SQL Server table partitioning.

Veriler neden bölümlenmeli?Why partition data?

  • Ölçeklenebilirliği geliştirme.Improve scalability. Tek bir veritabanı sisteminin ölçeğini büyüttüğünüzde, bu sistem sonunda fiziksel donanımın sınırına ulaşacaktır.When you scale up a single database system, it will eventually reach a physical hardware limit. Her bir ayrı sunucuda barındırılan birden çok bölümler arasında veri ayırdığınızda, sistemin ölçeğini neredeyse süresiz olarak ölçeklendirebilirsiniz.If you divide data across multiple partitions, each hosted on a separate server, you can scale out the system almost indefinitely.

  • Performansı geliştirme.Improve performance. Her bölümde veri erişim işlemleri daha küçük bir veri hacmi üzerinde gerçekleşir.Data access operations on each partition take place over a smaller volume of data. Doğru uygulanması, bölümleme sisteminizin daha verimli olmasını sağlayabilir.Correctly done, partitioning can make your system more efficient. Birden çok bölümü etkileyen işlemler paralel çalıştırılabilir.Operations that affect more than one partition can run in parallel.

  • Güvenliği geliştirme.Improve security. Bazı durumlarda, hassas ve nonsensitive verileri farklı bölümlere ayırmak ve hassas verileri farklı güvenlik denetimleri uygulayın.In some cases, you can separate sensitive and nonsensitive data into different partitions and apply different security controls to the sensitive data.

  • İşletimsel esneklik sağlama.Provide operational flexibility. Bölümleme operations ince ayar yapmak, yönetim verimliliğini en üst düzeye ve maliyetlerini en aza indirme için birçok fırsat sunar.Partitioning offers many opportunities for fine-tuning operations, maximizing administrative efficiency, and minimizing cost. Örneğin, her bölümdeki verilerin önemine bağlı olarak yönetim, izleme, yedekleme, geri yükleme ve diğer idari görevler için farklı stratejiler tanımlayabilirsiniz.For example, you can define different strategies for management, monitoring, backup and restore, and other administrative tasks based on the importance of the data in each partition.

  • Veri deposunu kullanım düzeniyle eşleştirme.Match the data store to the pattern of use. Bölümleme sayesinde, veri deposunun maliyetine ve sunduğu yerleşik özelliklere bağlı olarak her bölüm farklı bir veri deposuna dağıtılabilir.Partitioning allows each partition to be deployed on a different type of data store, based on cost and the built-in features that data store offers. Örneğin, daha yapılandırılmış veriler belge veritabanında tutulabilir ancak büyük ikili verileri blob depolama alanında depolanabilir.For example, large binary data can be stored in blob storage, while more structured data can be held in a document database. Bkz: doğru veri deposunu seçme.See Choose the right data store.

  • Kullanılabilirliği geliştirme.Improve availability. Verilerin birden çok sunucuya ayrılması tek hata noktası sorununu önler.Separating data across multiple servers avoids a single point of failure. Bir örnek başarısız olursa, yalnızca o bölümdeki veriler kullanılamaz.If one instance fails, only the data in that partition is unavailable. Diğer bölümlerdeki işlemler devam edebilir.Operations on other partitions can continue. Bu hizmetler ile yerleşik yedeklilik için tasarlandığından yönetilen PaaS veri depoları için bu daha az ilgili noktadır.For managed PaaS data stores, this consideration is less relevant, because these services are designed with built-in redundancy.

Bölümleri tasarlamaDesigning partitions

Veri bölümleme için üç tipik strateji şunlardır:There are three typical strategies for partitioning data:

  • Yatay bölümleme (çoğunlukla parçalama olarak adlandırılır).Horizontal partitioning (often called sharding). Bu stratejide her bölüm ayrı bir veri deposuna olduğu halde tüm bölümler aynı şemaya sahip.In this strategy, each partition is a separate data store, but all partitions have the same schema. Her bir bölümü olarak da bilinen bir parça ve belirli bir alt kümesini belirli bir müşteri kümesinin tüm siparişleri gibi verileri tutar.Each partition is known as a shard and holds a specific subset of the data, such as all the orders for a specific set of customers.

  • Dikey bölümleme.Vertical partitioning. Bu stratejide, her bölüm veri deposundaki öğelere ilişkin alanların bir alt kümesini barındırır.In this strategy, each partition holds a subset of the fields for items in the data store. Alanlar kendi kullanım düzenlerine göre bölünmüştür.The fields are divided according to their pattern of use. Örneğin, sık erişilen alanlar bir dikey bölüme yerleştirilirken daha az erişilen alanlar başka bir dikey bölüme yerleştirilebilir.For example, frequently accessed fields might be placed in one vertical partition and less frequently accessed fields in another.

  • İşlevsel bölümleme.Functional partitioning. Bu stratejide veriler, sistemdeki sınırlanmış her bağlam tarafından nasıl kullanıldıklarına göre bir araya toplanır.In this strategy, data is aggregated according to how it is used by each bounded context in the system. Örneğin, bir e-ticaret sistemi fatura verilerini bir bölümde ve ürün envanteri verilerini başka bir depolayabilir.For example, an e-commerce system might store invoice data in one partition and product inventory data in another.

Bu stratejiler birleştirilebilir ve bir bölümleme düzeni tasarlarken hepsini düşünmenizi öneririz.These strategies can be combined, and we recommend that you consider them all when you design a partitioning scheme. Örneğin, verileri parçalara bölebilir ve ardından her parçadaki verileri alt bölümlere ayırmak için dikey bölümleme kullanabilirsiniz.For example, you might divide data into shards and then use vertical partitioning to further subdivide the data in each shard.

Yatay bölümleme (parçalama)Horizontal partitioning (sharding)

Şekil 1, dikey bölümleme veya parçalama gösterir.Figure 1 shows horizontal partitioning or sharding. Bu örnekte, ürün envanter verileri ürün anahtarına göre parçalara bölünmüştür.In this example, product inventory data is divided into shards based on the product key. Her parça, alfabetik olarak düzenlenmiş birbirini takip eden bir parça anahtarı aralığındaki (A-G ve H-Z) verileri içerir.Each shard holds the data for a contiguous range of shard keys (A-G and H-Z), organized alphabetically. Parçalama, yükü çekişmesini azaltır ve performansı geliştirir daha fazla bilgisayar yayar.Sharding spreads the load over more computers, which reduces contention and improves performance.

Verileri bölüm anahtarına göre yatay olarak bölümleme (parçalama)

Şekil 1. Bir bölüm anahtarına göre yatay olarak bölümleme (parçalama) veriler.Figure 1. Horizontally partitioning (sharding) data based on a partition key.

En önemli faktör parçalama anahtarı bir seçenektir.The most important factor is the choice of a sharding key. Sistem çalışmaya başladıktan sonra anahtarı değiştirmek zor olabilir.It can be difficult to change the key after the system is in operation. Anahtar verileri, iş yükünün parçalar arasında mümkün olduğunca eşit olarak yayılır. bölümlenen emin olmanız gerekir.The key must ensure that data is partitioned to spread the workload as evenly as possible across the shards.

Parçalar, aynı boyutta olması gerekmez.The shards don't have to be the same size. İstek sayısını dengelemektir daha önemlidir.It's more important to balance the number of requests. Bazı parçalar çok büyük olabilir, ancak her öğenin erişim işlemlerinin düşük bir sayı vardır.Some shards might be very large, but each item has a low number of access operations. Öte yandan diğer parçalar daha küçüktür ama her öğeye çok daha sık erişiliyordur.Other shards might be smaller, but each item is accessed much more frequently. Tek bir parçanın veri deposunun ölçek sınırlarını (açısından, kapasite ve işlem kaynaklarını) aşmadığından emin olmak önemlidir.It's also important to ensure that a single shard does not exceed the scale limits (in terms of capacity and processing resources) of the data store.

Performansı ve kullanılabilirliği etkileyebilecek "etkin" bölümler oluşturmaktan kaçının.Avoid creating "hot" partitions that can affect performance and availability. Bazı baş harflere daha yaygındır Örneğin, bir müşteri adının ilk harfi kullanarak dengesiz bir dağıtım neden olur.For example, using the first letter of a customer’s name causes an unbalanced distribution, because some letters are more common. Bunun yerine, Müşteri Kimliği Karması verileri bölümler arasında daha eşit bir şekilde dağıtmak için kullanın.Instead, use a hash of a customer identifier to distribute data more evenly across partitions.

Büyük parçaya bölmek, küçük parçaları daha büyük bölümlerle birleştirme veya şemayı değiştirmek için gelecekteki gereksinimlere en aza indiren bir parçalama anahtarı seçin.Choose a sharding key that minimizes any future requirements to split large shards, coalesce small shards into larger partitions, or change the schema. Bu işlemler fazlasıyla zaman alabilir ve bunları gerçekleştirmek için bir veya birden çok parçayı çevrimdışı bırakmak gerekebilir.These operations can be very time consuming, and might require taking one or more shards offline while they are performed.

Parçalar çoğaltılırsa, çoğaltmalardan bazıları ayrılır, birleştirilir veya yeniden yapılandırılırken diğerlerini çevrimiçi tutmak mümkün olabilir.If shards are replicated, it might be possible to keep some of the replicas online while others are split, merged, or reconfigured. Ancak, sistem yapılandırması sırasında gerçekleştirilen işlemleri sınırlandırması gerekebilir.However, the system might need to limit the operations that can be performed during the reconfiguration. Örneğin, veriler salt okunur olarak veri tutarsızlıkların önlemek için işaretlenmiş.For example, the data in the replicas might be marked as read-only to prevent data inconsistences.

Yatay bölümleme, bkz: [parçalama düzeni] hakkında daha fazla bilgi için.For more information about horizontal partitioning, see [Sharding pattern].

Dikey bölümlemeVertical partitioning

Dikey bölümleme için en yaygın g/ç için kullanılır ve sık erişilen öğeleri getirmenin performans maliyetlerini.The most common use for vertical partitioning is to reduce the I/O and performance costs associated with fetching items that are frequently accessed. Şekil 2'de bir dikey bölümleme örneği gösterilir.Figure 2 shows an example of vertical partitioning. Bu örnekte, bir öğenin farklı özellikleri farklı bölümlerde depolanır.In this example, different properties of an item are stored in different partitions. Bir bölüm, ürün adı, açıklama ve fiyat gibi daha sık erişilen verileri tutar.One partition holds data that is accessed more frequently, including product name, description, and price. Envanter verileri başka bir bölüm içerir: stok sayısını ve son sipariş tarihi.Another partition holds inventory data: the stock count and last-ordered date.

Kullanım desenine göre dikey bölümleme verileri

Şekil 2. Kullanım desenine göre dikey bölümleme verileri.Figure 2. Vertically partitioning data by its pattern of use.

Bu örnekte, uygulama müşterilere ürün ayrıntılarını görüntülerken düzenli olarak ürün adını, açıklamasını ve fiyatını sorgular.In this example, the application regularly queries the product name, description, and price when displaying the product details to customers. Bu iki öğe genellikle birlikte kullanılır çünkü stok sayımı ve son sipariş tarihi ayrı bir bölümde tutulur.Stock count and last- ordered date are held in a separate partition because these two items are commonly used together.

Dikey bölümleme diğer avantajları:Other advantages of vertical partitioning:

  • Görece yavaş değişen veriler (ürün adı, açıklaması ve fiyatı) daha dinamik olan verilerden (stok düzeyi ve son sipariş tarihi) ayrılabilir.Relatively slow-moving data (product name, description, and price) can be separated from the more dynamic data (stock level and last ordered date). Yavaş veri taşımayı bellekte önbelleğe bir uygulama için iyi bir adaydır.Slow moving data is a good candidate for an application to cache in memory.

  • Hassas verileri ayrı bir bölüme ek güvenlik denetimleri ile depolanabilir.Sensitive data can be stored in a separate partition with additional security controls.

  • Dikey bölümleme gerekli olan eş zamanlı erişim miktarını azaltabilirsiniz.Vertical partitioning can reduce the amount of concurrent access that's needed.

Dikey bölümleme veri deposunda varlık düzeyinde çalışır; varlığı kısmen normalleştirerek bunu geniş bir öğeden bir dizi dar öğeye böler.Vertical partitioning operates at the entity level within a data store, partially normalizing an entity to break it down from a wide item to a set of narrow items. İdeal olarak HBase ve Cassandra gibi sütun odaklı veri depolarına uygundur.It is ideally suited for column-oriented data stores such as HBase and Cassandra. Bir sütun koleksiyonundaki verilerin değişme olasılığı düşükse, SQL Server'daki sütun depolarını kullanmayı da göz önüne alabilirsiniz.If the data in a collection of columns is unlikely to change, you can also consider using column stores in SQL Server.

İşlevsel bölümlemeFunctional partitioning

Her bir uygulama farklı iş alanı için sınırlanmış bir bağlam belirlemenin mümkün olduğunda, işlevsel bölümleme yalıtımı ve veri erişim performansını artırmak için bir yoldur.When it's possible to identify a bounded context for each distinct business area in an application, functional partitioning is a way to improve isolation and data access performance. İşlevsel bölümleme için bir diğer yaygın kullanımı, okunur-yazılır verilerle salt okunur verileri ayırmaktır.Another common use for functional partitioning is to separate read-write data from read-only data. Şekil 3'te envanter verilerinin müşteri verilerinden ayrıldığı işlevsel bölümleme genel çizgileriyle gösterilir.Figure 3 shows an overview of functional partitioning where inventory data is separated from customer data.

Sınırlanmış bağlam veya alt etki alanına göre işlevsel bölümleme verileri

Şekil 3. İşlevsel bölümleme verileri sınırlanmış bağlam veya alt etki alanı.Figure 3. Functionally partitioning data by bounded context or subdomain.

Bu bölümleme stratejisi sistemin farklı parçaları arasında veri erişim çekişmesini azaltmaya yardımcı olur.This partitioning strategy can help reduce data access contention across different parts of a system.

Bölümleri ölçeklenebilirlik için tasarlamaDesigning partitions for scalability

Her bölümün boyutunu ve iş yükünü göz önüne almak ve verilerin maksimum ölçeklenebilirlik sağlanacak şekilde dağıtılması için bunları dengelemek yaşamsal önem taşır.It's vital to consider size and workload for each partition and balance them so that data is distributed to achieve maximum scalability. Öte yandan, verileri bölümlerken tek bir bölüm deposunun ölçeklendirme sınırlarını aşmamaya da dikkat etmelisiniz.However, you must also partition the data so that it does not exceed the scaling limits of a single partition store.

Bölümleri ölçeklenebilirlik için tasarlarken şu adımları izleyin:Follow these steps when designing partitions for scalability:

  1. Veri erişim desenlerini, örneğin her sorgunun döndürdüğü yanıt kümesinin boyutunu, erişim sıklığını, doğal gecikme süresini ve sunucu tarafı işlem işleme gereksinimlerini anlamak için uygulamayı analiz edin.Analyze the application to understand the data access patterns, such as the size of the result set returned by each query, the frequency of access, the inherent latency, and the server-side compute processing requirements. Birçok durumda, birkaç ana varlık işlem kaynaklarının büyük bölümünü talep edecektir.In many cases, a few major entities will demand most of the processing resources.
  2. Bu analizi kullanarak güncel ve geleceğe dair ölçeklendirme hedeflerini (veri boyutu ve iş yükü gibi) saptayın.Use this analysis to determine the current and future scalability targets, such as data size and workload. Ardından, ölçeklendirme hedefine uygun şekilde verileri bölümler arasında dağıtın.Then distribute the data across the partitions to meet the scalability target. Yatay bölümleme için doğru parça anahtarı dağıtım emin olmak önemlidir seçme olsa bile.For horizontal partitioning, choosing the right shard key is important to make sure distribution is even. [Parçalama düzeni] daha fazla bilgi için bkz.For more information, see the [Sharding pattern].
  3. Her bölüm, veri boyutu ve aktarım hızı açılarından ölçeklenebilirlik gereksinimlerini işlemek için yeterli kaynakları içerdiğinden emin olun.Make sure each partition has enough resources to handle the scalability requirements, in terms of data size and throughput. Veri deposu bağlı olarak bir güç veya ağ bant genişliği bölüm başına işleme, depolama alanı miktarı sınırı olabilir.Depending on the data store, there might be a limit on the amount of storage space, processing power, or network bandwidth per partition. Gereksinimleri bu sınırları aşma olasılığı varsa, size, bölümleme stratejisinde ayarlama yapmanız veya verileri daha fazla bölme muhtemelen iki veya daha fazla stratejileri birleştirme gerekebilir.If the requirements are likely to exceed these limits, you may need to refine your partitioning strategy or split data out further, possibly combining two or more strategies.
  4. Verilerin beklendiği gibi dağıtıldığını ve bölümlerin yükünü işleyebilir doğrulamak için sistemi izleyin.Monitor the system to verify that data is distributed as expected and that the partitions can handle the load. Her zaman gerçek kullanım analizini tahmin ne eşleşmiyor.Actual usage does not always match what an analysis predicts. Bu durumda, bölümleri yeniden dengelemek, aksi takdirde, gerekli dengeyi elde etmek için sistemin bazı bölümlerini yeniden tasarlamanız mümkün olabilir.If so, it might be possible to rebalance the partitions, or else redesign some parts of the system to gain the required balance.

Bazı bulut ortamlarının kaynakları altyapı sınırlarına göre ayırdığını ayırın.Some cloud environments allocate resources in terms of infrastructure boundaries. Seçtiğiniz sınırların, veri depolama alanı, işlem gücü ve bant genişliği açısından veri hacmindeki beklenen artışla başa çıkabilecek kadar yer sağladığından emin olun.Ensure that the limits of your selected boundary provide enough room for any anticipated growth in the volume of data, in terms of data storage, processing power, and bandwidth.

Örneğin, Azure tablo depolama hizmetini kullanıyorsanız, belirli bir süre içinde tek bölüm tarafından işlenebilecek isteklerin hacminin bir sınırı yoktur.For example, if you use Azure table storage, there is a limit to the volume of requests that can be handled by a single partition in a particular period of time. (Bkz Azure depolama ölçeklenebilirlik ve performans hedefleri.) Meşgul bir parça, tek bir bölüm işleyebileceğinden daha fazla kaynak gerektirebilir.(See Azure storage scalability and performance targets.) A busy shard might require more resources than a single partition can handle. Bu durumda, parça yükü dağıtmak için yeniden bölümlenmesi gerekebilir.If so, the shard might need to be repartitioned to spread the load. Toplam boyutu veya aktarım hızı bu tabloların bir depolama hesabı kapasitesini aşıyorsa, ek depolama hesapları oluşturmanız ve tabloları bu hesaplara yaymak gerekebilir.If the total size or throughput of these tables exceeds the capacity of a storage account, you might need to create additional storage accounts and spread the tables across these accounts.

Bölümleri sorgu performansı için tasarlamaDesigning partitions for query performance

Çoğunlukla daha küçük veri kümeleri kullanılarak ve paralel sorgular çalıştırılarak sorgu performansı artırılabilir.Query performance can often be boosted by using smaller data sets and by running parallel queries. Her bölüm, veri kümesinin tamamının küçük bir kısmını içermelidir.Each partition should contain a small proportion of the entire data set. Hacmin böyle azaltılması sorguların performansını geliştirebilir.This reduction in volume can improve the performance of queries. Bununla birlikte bölümleme, veritabanını düzgün bir şekilde tasarlama ve yapılandırmanın alternatifi değildir.However, partitioning is not an alternative for designing and configuring a database appropriately. Örneğin, yerinde gerekli dizinlere sahip olduğunuzdan emin olun.For example, make sure that you have the necessary indexes in place.

Bölümleri sorgu performansı için tasarlarken şu adımları izleyin:Follow these steps when designing partitions for query performance:

  1. Uygulama gereksinimlerini ve performansını inceleyin:Examine the application requirements and performance:

    • Her zaman hızla gerçekleştirilmesi gereken kritik sorguları saptayın için iş gereksinimlerini kullanın.Use business requirements to determine the critical queries that must always perform quickly.
    • Yavaş çalışan sorguları belirlemek için sistemi izleyin.Monitor the system to identify any queries that perform slowly.
    • En sık gerçekleştirilen sorguların hangileri olduğunu öğrenin.Find which queries are performed most frequently. Tek bir sorgu çok düşük maliyetli olsa bile, toplam kaynak tüketimi önemli olabilir.Even if a single query has a minimal cost, the cumulative resource consumption could be significant.
  2. Düşük performansa neden olan verileri bölümleyin:Partition the data that is causing slow performance:

    • Sorgu yanıt süresinin hedefin dışına çıkmaması için her bölümün boyutunu sınırlandırın.Limit the size of each partition so that the query response time is within target.
    • Yatay bölümleme kullanırsanız, parça anahtarını uygulamanın doğru bölüm kolayca seçebilmeniz için tasarlayın.If you use horizontal partitioning, design the shard key so that the application can easily select the right partition. Bu, sorgunun her bölümü taramak zorunda kalmasını önler.This prevents the query from having to scan through every partition.
    • Bölümün konumu üzerinde düşünün.Consider the location of a partition. Mümkünse, verileri coğrafi olarak bunlara erişen uygulamaların ve kullanıcıların yakınındaki bölümlerde tutun.If possible, try to keep data in partitions that are geographically close to the applications and users that access it.
  3. Bir varlığın aktarım hızı ve sorgu performansı gereksinimleri varsa, o varlığı temel alarak işlevsel bölümleme kullanın.If an entity has throughput and query performance requirements, use functional partitioning based on that entity. Bu yaklaşım da gereksinimleri karşılamaya yetmezse, aynı zamanda yatay bölümleme de uygulayın.If this still doesn't satisfy the requirements, apply horizontal partitioning as well. Çoğu durumda, tek bir bölümleme stratejisi yeterli olacaktır, ancak bazı durumlarda iki stratejileri birleştirerek daha verimli olur.In most cases, a single partitioning strategy will suffice, but in some cases it is more efficient to combine both strategies.

  4. Sorgu performansını geliştirmek için bölümler arasında paralel olarak çalıştırmayı göz önünde bulundurun.Consider running queries in parallel across partitions to improve performance.

Bölümleri kullanılabilirlik için tasarlamaDesigning partitions for availability

Verileri bölümlemek, veri kümesinin tamamının tek bir hata noktası oluşturmamasını ve veri kümesindeki tek tek alt kümelerin bağımsız olarak yönetilebilmesini sağladığından uygulamaların kullanılabilirliğini geliştirebilir.Partitioning data can improve the availability of applications by ensuring that the entire dataset does not constitute a single point of failure and that individual subsets of the dataset can be managed independently.

Kullanılabilirliği etkileyecek aşağıdaki faktörleri göz önünde bulundurun:Consider the following factors that affect availability:

Veriler işle ilgili işlemler açısından ne derece kritik.How critical the data is to business operations. Veri işlemleri gibi işle ilgili kritik bilgiler ve hangi veri günlük dosyaları gibi daha az kritik işlem verileri belirleyin.Identify which data is critical business information, such as transactions, and which data is less critical operational data, such as log files.

  • Yüksek oranda kullanılabilir bölümlerde uygun bir yedekleme planıyla kritik verileri depolamayı düşünün.Consider storing critical data in highly available partitions with an appropriate backup plan.

  • Ayrı yönetim ve izleme yordamları için farklı veri kümeleri oluşturun.Establish separate management and monitoring procedures for the different datasets.

  • Kritiklik düzeyi aynı olan verileri aynı bölüme yerleştirerek, birlikte uygun bir sıklıkta yedeklenebilmelerini sağlayın.Place data that has the same level of criticality in the same partition so that it can be backed up together at an appropriate frequency. Örneğin, işlem verilerini tutan bölümler, günlüğe kaydetme ve izleme bilgilerinin tutulduğu bölümlere göre daha sık yedeklenmesi gerekebilir.For example, partitions that hold transaction data might need to be backed up more frequently than partitions that hold logging or trace information.

Tek tek bölümler nasıl yönetilebilir.How individual partitions can be managed. Bağımsız yönetim ve bakımı destekleyen bölümler tasarlamanın çeşitli avantajları vardır.Designing partitions to support independent management and maintenance provides several advantages. Örneğin:For example:

  • Bir bölüm başarısız olursa, bağımsız olarak diğer bölümlerdeki verilere erişen uygulamalar olmadan kurtarılabilir.If a partition fails, it can be recovered independently without applications that access data in other partitions.

  • Verilerin coğrafi alana göre bölümlenmesi, zamanlanmış bakım görevlerinin her konumda yoğun olmayan saatlerde gerçekleştirilmesine olanak tanır.Partitioning data by geographical area allows scheduled maintenance tasks to occur at off-peak hours for each location. Bölümler planlanmış bir bakımın belirlenen süre içinde tamamlanmasını önlemek için çok büyük olmadığından emin olun.Ensure that partitions are not too large to prevent any planned maintenance from being completed during this period.

Kritik verilerin bölümler arasında çoğaltılıp çoğaltılmayacağı.Whether to replicate critical data across partitions. Bu strateji kullanılabilirliği ve performansı artırabilir, ancak aynı zamanda tutarlılık sorunlarına ortaya çıkarabilir.This strategy can improve availability and performance, but can also introduce consistency issues. Değişiklikleri her çoğaltma ile eşitlemek için zaman alır.It takes time to synchronize changes with every replica. Bu süre boyunca, farklı bölümler farklı veri değerleri içeriyor olacaktır.During this period, different partitions will contain different data values.

Uygulama tasarımında dikkat edilmesi gerekenlerApplication design considerations

Bölümleme sisteminizin geliştirme ve tasarım karmaşıklık ekler.Partitioning adds complexity to the design and development of your system. Sistem başlangıçta tek bir bölüm içeriyor olsa bile bölümlemeyi sistem tasarımının temel parçalarından biri olarak düşünün.Consider partitioning as a fundamental part of system design even if the system initially only contains a single partition. Bölümleme akla ele alırsanız, zaten sahip olduğunuz korumak için Canlı bir sistem için daha zor olacaktır:If you address partitioning as an afterthought, it will be more challenging because you already have a live system to maintain:

  • Veri erişim mantığı değiştirilmesi gerekir.Data access logic will need to be modified.
  • Büyük miktarda mevcut verilerin bölümler arasında dağıtmak için geçirilmesi gerekebilir.Large quantities of existing data may need to be migrated, to distribute it across partitions.
  • Kullanıcılar geçiş sırasında sistem kullanmaya devam etmek erişebilmeyi beklerler.Users expect to be able to continue using the system during the migration.

Bazı durumlarda bölümlemenin önemli olduğu düşünülmez çünkü başlangıçtaki veri kümesi küçüktür ve tek sunucu tarafından kolayca işlenebilir.In some cases, partitioning is not considered important because the initial dataset is small and can be easily handled by a single server. Bu, bazı iş yükleri için true olabilir, ancak birçok ticari sistemde kullanıcı sayısı arttıkça sistemin genişletilmesi gerekir.This might be true for some workloads, but many commercial systems need to expand as the number of users increases.

Üstelik, yalnızca bölümlemeden büyük veri depolarına değildir.Moreover, it's not only large data stores that benefit from partitioning. Örneğin, küçük bir veri deposuna yüzlerce eş zamanlı istemci yoğun olarak erişiyor olabilir.For example, a small data store might be heavily accessed by hundreds of concurrent clients. Bu durumda verilerin bölümlenmesi çekişmeyi azaltıp aktarım hızını geliştirmeye yardımcı olabilir.Partitioning the data in this situation can help to reduce contention and improve throughput.

Veri bölümleme düzeni tasarlarken aşağıdaki noktaları göz önünde bulundurun:Consider the following points when you design a data partitioning scheme:

Bölümler arası veri erişim işlemlerini en aza.Minimize cross-partition data access operations. Mümkünse, en yaygın veritabanı işlemlerinin verilerini bölümler arası veri erişim işlemlerini en aza indirmek için her bölümdeki birlikte bulundurun.Where possible, keep data for the most common database operations together in each partition to minimize cross-partition data access operations. Bölümler arasında sorgulama tek bir bölüm içinde sorgulamaktan çok daha fazla zaman alabilir, ancak bölümleri sorguları bir dizi için en iyi duruma getirme diğer sorgu kümelerini olumsuz etkileyebilir.Querying across partitions can be more time-consuming than querying within a single partition, but optimizing partitions for one set of queries might adversely affect other sets of queries. Bölümler arasında sorgu gerekir, paralel sorgular çalıştırarak ve sonuçları uygulama içinde toplayarak sorgu süresini en aza indirin.If you must query across partitions, minimize query time by running parallel queries and aggregating the results within the application. (Bu yaklaşım bir sorgu sonucuna sonraki sorguda kullanıldığında gibi bazı durumlarda mümkün olmayabilir.)(This approach might not be possible in some cases, such as when the result from one query is used in the next query.)

Statik başvuru verileri çoğaltmayı göz önünde bulundurun.Consider replicating static reference data. Sorgular posta kodu tabloları veya ürün listeleri gibi görece statik başvuru verileri kullanıyorsanız bu verileri farklı bölümlerde ayrı arama işlemleri azaltmak için bölümlerin tümünde çoğaltmayı göz önünde bulundurun.If queries use relatively static reference data, such as postal code tables or product lists, consider replicating this data in all of the partitions to reduce separate lookup operations in different partitions. Bu yaklaşım, tüm sistem genelinde gelen yoğun trafikle ile "etkin" bir veri kümesi haline başvuru verilerini olasılığını da azaltabilir.This approach can also reduce the likelihood of the reference data becoming a "hot" dataset, with heavy traffic from across the entire system. Ancak, başvuru verileriyle değişiklikleri eşitlemek ek maliyete yoktur.However, there is an additional cost associated with synchronizing any changes to the reference data.

Bölümler arası birleştirmeler en aza indirin.Minimize cross-partition joins. Mümkünse, dikey ve işlevsel bölümler arasında başvurusal bütünlük gereksinimlerini en aza indirin.Where possible, minimize requirements for referential integrity across vertical and functional partitions. Bu düzenlerde, bölümler arasında başvurusal bütünlüğü korumak uygulamanın görevidir.In these schemes, the application is responsible for maintaining referential integrity across partitions. Uygulamanın genellikle bir anahtar ve ardından bir yabancı anahtar üzerinde dayanan ardışık sorgular gerçekleştirmesi gereken çünkü birden çok bölümde verileri birleştiren sorgular verimli değildir.Queries that join data across multiple partitions are inefficient because the application typically needs to perform consecutive queries based on a key and then a foreign key. Bunun yerine, ilgili verileri çoğaltmayı veya normalleştirmelerini kaldırmayı göz önünde bulundurun.Instead, consider replicating or de-normalizing the relevant data. Bölümler arası birleştirmeler gerekliyse, bölümler üzerinde paralel sorgular çalıştırmak ve verileri uygulamanın içinde katılın.If cross-partition joins are necessary, run parallel queries over the partitions and join the data within the application.

Nihai tutarlılık yaklaşımını benimseyin.Embrace eventual consistency. Aslında güçlü bir tutarlılığın gerekip gerekmediğini değerlendirin.Evaluate whether strong consistency is actually a requirement. Dağıtılmış sistemler ortak bir yaklaşım nihai tutarlılığı gerçekleştirmektir.A common approach in distributed systems is to implement eventual consistency. Her bölümdeki veriler ayrı güncelleştirilir ve uygulama mantığı tüm güncelleştirmelerin başarıyla tamamlanmasını güvence altına alır.The data in each partition is updated separately, and the application logic ensures that the updates are all completed successfully. Ayrıca, son tutarlılık işlemi çalıştırılırken sorgu verilerinde ortaya çıkabilecek tutarsızlıkları da giderir.It also handles the inconsistencies that can arise from querying data while an eventually consistent operation is running.

Sorguların doğru bölümü nasıl bulduğunu göz önünde bulundurun.Consider how queries locate the correct partition. Sorgunun gerekli verileri bulmak için tüm bölümleri taraması gerekirse, birden çok paralel sorgu çalıştırılıyor olsa bile performansı önemli ölçüde etkiler.If a query must scan all partitions to locate the required data, there is a significant impact on performance, even when multiple parallel queries are running. Sorgular, dikey ve işlevsel bölümleme ile doğal olarak bölüm belirtebilirsiniz.With vertical and functional partitioning, queries can naturally specify the partition. Yatay bölümleme, diğer yandan, her parça aynı şemaya sahip olduğundan, bir öğenin bulunmasını zorlaştırabilir, bulma hale getirebilirsiniz.Horizontal partitioning, on the other hand, can make locating an item difficult, because every shard has the same schema. Tipik bir çözüm parça konumunda belirli öğeleri aramak için kullanılan bir harita bulundurmaktır.A typical solution to maintain a map that is used to look up the shard location for specific items. Bu harita uygulamanın parçalama mantığında oluşturulabilir veya saydam parçalamayı destekliyorsa veri deposu tarafından tutulabilir.This map can be implemented in the sharding logic of the application, or maintained by the data store if it supports transparent sharding.

Düzenli aralıklarla parçaların yeniden dengelenmesi göz önünde bulundurun.Consider periodically rebalancing shards. Yatay bölümleme parçaların yeniden dengelenmesi verilerin boyutu ve etkin noktaları en aza indirmek, sorgu performansını en üst düzeye çıkarmak ve fiziksel depolama sınırlamalarından çalışma iş yüküne göre eşit olarak dağıtılmasına yardımcı olabilir.With horizontal partitioning, rebalancing shards can help distribute the data evenly by size and by workload to minimize hotspots, maximize query performance, and work around physical storage limitations. Bununla birlikte, bu özel bir araç veya işlemin kullanılmasını gerektiren karmaşık bir görevdir.However, this is a complex task that often requires the use of a custom tool or process.

Bölümleri çoğaltılır.Replicate partitions. Her bölümü çoğaltırsanız, hataya karşı ek koruma sağlar.If you replicate each partition, it provides additional protection against failure. Tek bir çoğaltma başarısız olursa, sorgular çalışan bir kopya doğru yönlendirilebilir.If a single replica fails, queries can be directed toward a working copy.

Bölümleme stratejisinin fiziksel sınırlarına ulaşırsanız, ölçeklenebilirliği farklı bir düzeye genişletmeniz gerekebilir.If you reach the physical limits of a partitioning strategy, you might need to extend the scalability to a different level. Örneğin bölümleme veritabanı düzeyinde yapılıyorsa, bölümleri birden çok veritabanına yerleştirmeniz veya çoğaltmanız gerekebilir.For example, if partitioning is at the database level, you might need to locate or replicate partitions in multiple databases. Bölümleme zaten veritabanı düzeyindeyse ve fiziksel sınırlamalar sorun yaratıyorsa, bu durum bölümleri birden çok barındırma hesabına yerleştirmeniz veya çoğaltmanız gerektiği anlamına gelebilir.If partitioning is already at the database level, and physical limitations are an issue, it might mean that you need to locate or replicate partitions in multiple hosting accounts.

Birden çok bölümdeki verilere erişen işlemlerden kaçının.Avoid transactions that access data in multiple partitions. Bazı veri depoları verilerde değişiklik yapan işlemler için işlem tutarlılığı ve bütünlüğünü gerçekleştirir ama bunun için verilerin tek bir bölümde yer alıyor olması gerekir.Some data stores implement transactional consistency and integrity for operations that modify data, but only when the data is located in a single partition. Birden çok bölümde işlem desteğine ihtiyacınız varsa, büyük olasılıkla bunu uygulama mantığınızın bir parçası olarak gerçekleştirmeniz gerekir çünkü bölümleme sistemlerinin çoğu yerel destek sağlamaz.If you need transactional support across multiple partitions, you will probably need to implement this as part of your application logic because most partitioning systems do not provide native support.

Tüm veri depoları bazı işletimsel yönetim ve izleme etkinlikleri gerektirir.All data stores require some operational management and monitoring activity. Görevler arasında verileri yükleme, veri yedekleme ve geri yükleme, verileri yeniden düzenleme ve sistemin doğru ve verimli çalıştığından emin olma sayılabilir.The tasks can range from loading data, backing up and restoring data, reorganizing data, and ensuring that the system is performing correctly and efficiently.

İşletimsel yönetimi etkileyen aşağıdaki faktörleri göz önünde bulundurun:Consider the following factors that affect operational management:

  • Veriler bölümlendiğinde uygun yönetim ve işletim görevleri nasıl gerçekleştirilir.How to implement appropriate management and operational tasks when the data is partitioned. Bu görevler yedekleme ve geri yüklemeyi, verileri arşivlemeyi, sistemi izlemeyi ve diğer yönetim görevlerini içerebilir.These tasks might include backup and restore, archiving data, monitoring the system, and other administrative tasks. Örneğin, yedekleme ve geri yükleme işlemleri sırasında mantıksal tutarlılığı korumak zor olabilir.For example, maintaining logical consistency during backup and restore operations can be a challenge.

  • Birden çok bölümdeki veriler nasıl yüklenir ve başka kaynaklardan gelen yeni veriler nasıl eklenir.How to load the data into multiple partitions and add new data that's arriving from other sources. Bazı araçlar ve yardımcı programlar verileri doğru bölüme yükleme gibi parçalanmış veri işlemlerini desteklemiyor olabilir.Some tools and utilities might not support sharded data operations such as loading data into the correct partition.

  • Veriler nasıl düzenli aralıklarla arşivlenir ve silinir.How to archive and delete the data on a regular basis. Bölümlerin aşırı büyümesini önlemek için arşiv ve verileri (örneğin, aylık) düzenli olarak silmek gerekir.To prevent the excessive growth of partitions, you need to archive and delete data on a regular basis (such as monthly). Farklı bir arşiv şemasıyla eşleşmesi için verileri dönüştürmeniz gerekebilir.It might be necessary to transform the data to match a different archive schema.

  • Veri bütünlüğü sorunları nasıl bulunur.How to locate data integrity issues. Başka bir eksik bilgilerine başvuran bir bölümündeki verileri gibi tüm veri bütünlüğü sorunlarını bulmak için düzenli aralıklarla bir işlem çalıştırmayı göz önünde bulundurun.Consider running a periodic process to locate any data integrity issues, such as data in one partition that references missing information in another. İşlem otomatik olarak bu sorunları çözmek veya el ile İnceleme için rapor oluşturma denemesi ya da kullanabilirsiniz.The process can either attempt to fix these issues automatically or generate a report for manual review.

Bölümleri yeniden dengelemeRebalancing partitions

Bir sistem geliştikçe bölümleme düzenini yeniden ayarlamanız gerekebilir.As a system matures, you might have to adjust the partitioning scheme. Örneğin, tek tek bölümler orantısız bir trafik başlanması ve bu aşırı çekişmeye etkin hale gelebilir.For example, individual partitions might start getting a disproportionate volume of traffic and become hot, leading to excessive contention. Veya, bazı bölümlerdeki verilerin hacmini kapasite sınırları yaklaşım bazı bölümleri hafife almış olabilirsiniz.Or you might have underestimated the volume of data in some partitions, causing some partitions to approach capacity limits.

Cosmos DB gibi bazı veri depoları, bölümleri otomatik olarak yeniden dengeleyebilir.Some data stores, such as Cosmos DB, can automatically rebalance partitions. Diğer durumlarda, yeniden Dengeleme iki aşamadan oluşan bir yönetim görevidir:In other cases, rebalancing is an administrative task that consists of two stages:

  1. Yeni bir bölümleme stratejisini belirleyin.Determine a new partitioning strategy.

    • Hangi bölümlerin ayrılması (veya bir olasılıkla birleştirilmesi) gerekiyor?Which partitions need to be split (or possibly combined)?
    • Yeni bir bölüm anahtarı nedir?What is the new partition key?
  2. Verileri eski bölümleme düzeninden yeni bölüm kümesine geçirme.Migrate data from the old partitioning scheme to the new set of partitions.

Veri deposu bağlı olarak, bunlar kullanımdayken bölümler arasında veri geçirme mümkün olabilir.Depending on the data store, you might be able to migrate data between partitions while they are in use. Bu adlandırılır çevrimiçi geçiş.This is called online migration. Bu mümkün değilse, verileri yeniden konumlandırılır sırasında bölümleri aktarımının kullanılamaz olmasına neden gerekebilir (çevrimdışı geçiş).If that's not possible, you might need to make partitions unavailable while the data is relocated (offline migration).

Çevrimdışı geçişOffline migration

Çekişme oluşma olasılığını azaltır çünkü çevrimdışı geçiş genellikle daha basittir.Offline migration is typically simpler because it reduces the chances of contention occurring. Kavramsal olarak, çevrimdışı geçiş gibi çalışır:Conceptually, offline migration works as follows:

  1. Bölüm çevrimdışı işaretleyin.Mark the partition offline.
  2. Ayırma-birleştirme ve yeni bölümler için veri taşıma.Split-merge and move the data to the new partitions.
  3. Verileri doğrulayın.Verify the data.
  4. Yeni bölümleri çevrimiçi duruma getirin.Bring the new partitions online.
  5. Eski bölümünü kaldırın.Remove the old partition.

İsteğe bağlı olarak, böylece bu taşınırken uygulamalar verileri hala okuyabilir bölümü 1. adımda salt okunur olarak işaretleyebilirsiniz.Optionally, you can mark a partition as read-only in step 1, so that applications can still read the data while it is being moved.

Çevrimiçi geçişOnline migration

Çevrimiçi geçişi ancak daha az aksatıcı gerçekleştirmek daha karmaşıktır.Online migration is more complex to perform but less disruptive. Özgün bölüm çevrimdışı olarak işaretlenmemiş dışında çevrimdışı geçiş için benzer bir işlemdir.The process is similar to offline migration, except the original partition is not marked offline. İki konum, özgün bölüm ve yeni tutulan verileri okurken ve yazarken işlemeye bağlı olarak bir ayrıntı (örneğin, parça parça tarafından karşı öğe tarafından) geçiş işleminin istemci uygulamalarında veri erişim kodu olabilir bölüm.Depending on the granularity of the migration process (for example, item by item versus shard by shard), the data access code in the client applications might have to handle reading and writing data that's held in two locations, the original partition and the new partition.

Aşağıdaki tasarım desenleri, senaryonuz için uygun olabilir:The following design patterns might be relevant to your scenario:

  • Parçalama düzeni verileri Parçalamaya yönelik bazı yaygın stratejileri açıklanır.The sharding pattern describes some common strategies for sharding data.

  • Dizin tablosu düzeni veriler üzerinde ikincil dizinler oluşturma işlemini göstermektedir.The index table pattern shows how to create secondary indexes over data. Uygulama bu yaklaşımla, koleksiyonun birincil anahtarına başvurmayan sorgular kullanarak verileri hızla alabilir.An application can quickly retrieve data with this approach, by using queries that do not reference the primary key of a collection.

  • Gerçekleştirilmiş görünüm modeli hızlı sorgu işlemlerini desteklemek üzere verileri özetleyen önceden doldurulmuş görünümlerin nasıl açıklar.The materialized view pattern describes how to generate prepopulated views that summarize data to support fast query operations. Özetlenen verileri içeren bölümler birden çok siteye dağıtılmışsa bu yaklaşım bölümlenmiş bir veri deposunda kullanışlı olabilir.This approach can be useful in a partitioned data store if the partitions that contain the data being summarized are distributed across multiple sites.

Sonraki adımlarNext steps