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

Birçok büyük ölçekli çözümde, veriler yönetilebilecek ve ayrı olarak erişilebilen bölümlere ayrılır.In many large-scale solutions, data is divided into partitions that can be managed and accessed separately. Bölümlendirme ölçeklenebilirliği iyileştirebilir, çekişmeyi azaltabilir ve performansı en iyi hale getirebilir.Partitioning can improve scalability, reduce contention, and optimize performance. Ayrıca, verileri kullanım düzenine göre bölmek için bir mekanizma sağlar.It can also provide a mechanism for dividing data by usage pattern. Örneğin, daha eski verileri ucuz veri depolamadaki arşivleyebilir.For example, you can archive older data in cheaper data storage.

Ancak, olumsuz etkileri en aza indirerek avantajları en üst düzeye çıkarmak için bölümleme stratejisi 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 biri ayrı bir sunucuda barındırılan birden çok bölümdeki verileri bölerseniz, sistemi 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 şekilde yapılan bölümlendirme, sisteminizi daha verimli hale getirir.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 hassas olmayan verileri farklı bölümlere ayırabilir ve hassas verilere farklı güvenlik denetimleri uygulayabilirsiniz.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ümlendirme, ince ayar işlemleri, yönetim verimliliğini en üst düzeye çıkarmak ve maliyeti en aza indirmek 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, büyük ikili veriler BLOB depolama alanında depolanabilir, ancak daha fazla yapılandırılmış veriler bir belge veritabanında tutulabilir.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 söz konusu 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 yerleşik yedeklilik ile tasarlandığından, yönetilen PaaS veri depoları için bu dikkat daha az uygundur.For managed PaaS data stores, this consideration is less relevant, because these services are designed with built-in redundancy.

Bölümleri tasarlamaDesigning partitions

Verileri bölümlemek için üç tipik strateji vardı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 deposudur, ancak tüm bölümlerin aynı şemaya sahip olması gerekir.In this strategy, each partition is a separate data store, but all partitions have the same schema. Her bölüm parça olarak bilinir ve verilerin belirli bir müşteri kümesinin tüm siparişleri gibi belirli bir alt kümesini barındırır.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 verilerinde farklı bir şekilde saklayabilir.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 bunların tümünü göz önünde bulundurmanızı ö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 ' de yatay bölümleme veya parçalama gösterilmektedir.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, daha fazla bilgisayarın yükünü yayar ve bu da çekişmeyi azaltır ve performansı geliştirir.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-verileri bölüm anahtarına göre yatay olarak bölümleme (parçalama).Figure 1 - Horizontally partitioning (sharding) data based on a partition key.

En önemli etken, parçalı anahtar seçimdir.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, verilerin iş yükünü parçalar arasında olabildiğince eşit bir şekilde yaymak üzere bölümlendiğinden emin olmalıdır.The key must ensure that data is partitioned to spread the workload as evenly as possible across the shards.

Parçaların aynı boyutta olması gerekmez.The shards don't have to be the same size. İstek sayısını dengelemek daha önemlidir.It's more important to balance the number of requests. Bazı parçalar çok büyük olabilir, ancak her öğe az sayıda erişim işlemine sahiptir.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ı (kapasite ve işlem kaynakları açısından) aşmadığından emin olmak da ö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. Örneğin, bir müşterinin adının ilk harfinin kullanılması, bazı harfler daha yaygın olduğundan, dengesiz bir dağıtıma 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, bölümler arasında verileri daha eşit bir şekilde dağıtmak için müşteri tanımlayıcısının karmasını kullanın.Instead, use a hash of a customer identifier to distribute data more evenly across partitions.

Büyük parçaları bölmek, küçük parçaları daha büyük bölümlere birleştirmek veya şemayı değiştirmek için gelecekteki tüm gereksinimleri en aza indiren bir parça 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. Bununla birlikte, sistem yeniden yapılandırma sırasında gerçekleştirilebilecek işlemleri sınırlandırmalıdır.However, the system might need to limit the operations that can be performed during the reconfiguration. Örneğin, Çoğaltmalardaki veriler veri inconsistences engellemek için salt okunabilir olarak işaretlenebilir.For example, the data in the replicas might be marked as read-only to prevent data inconsistences.

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

Dikey bölümlemeVertical partitioning

Dikey bölümlendirme için en yaygın kullanım, sık erişilen öğeleri getirmeye ilişkin g/ç ve performans maliyetlerini azaltmaktır.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 dahil olmak üzere daha sık erişilen verileri tutar.One partition holds data that is accessed more frequently, including product name, description, and price. Başka bir bölüm stok verilerini barındırır: stok sayısı 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-verileri kullanım düzenine göre dikey olarak bölümleniyor.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. Stok sayısı ve son sipariş tarihi ayrı bir bölümde tutulur çünkü bu iki öğe yaygın olarak birlikte kullanılır.Stock count and last- ordered date are held in a separate partition because these two items are commonly used together.

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

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

  • Gizli veriler, ek güvenlik denetimleriyle ayrı bir bölümde depolanabilir.Sensitive data can be stored in a separate partition with additional security controls.

  • Dikey bölümleme, gereken eşzamanlı erişim miktarını azaltabilir.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

Bir uygulamadaki her farklı iş alanı için sınırlanmış bir bağlam tanımlamak mümkün olduğunda, işlev bölümleme yalıtımı ve veri erişimi performansını artırmanın bir yoludur.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ümlendirme için bir diğer yaygın kullanım, salt okuma verilerinden okuma-yazma verilerini 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-sınırlı bağlam veya alt etki alanına göre Işlevsel verileri bölümleme.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ümlendirme için, dağıtımın çift olduğundan emin olmak için sağ parça anahtarını seçmek önemlidir.For horizontal partitioning, choosing the right shard key is important to make sure distribution is even. Daha fazla bilgi için bkz. [parçalama stili].For more information, see the [Sharding pattern].
  3. Her bölümde, veri boyutu ve aktarım hızı bakımından ölçeklenebilirlik gereksinimlerini işlemek için yeterli kaynak bulunduğundan emin olun.Make sure each partition has enough resources to handle the scalability requirements, in terms of data size and throughput. Veri deposuna bağlı olarak, bölüm başına depolama alanı, işlem gücü veya ağ bant genişliği miktarı için bir 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. Gereksinimlerin bu sınırları aşmaları olasılıklardır, bölümleme stratejinizi daraltmanız ya da verileri daha fazla ayırmak ya da iki veya daha fazla strateji birleştirmek isteyebilirsiniz.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ü işleyebildiğini 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. Gerçek kullanım, her zaman analizin tahmin edilecek şekilde eşleşmez.Actual usage does not always match what an analysis predicts. Bu durumda, bölümleri yeniden dengelemek veya gerekli bakiyeyi kazanmak için sistemin bazı parçalarını 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ı, kaynakları altyapı sınırları bakımından ayırır.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 kullanırsanız, belirli bir süre içinde tek bir bölüm tarafından işlenebilen isteklerin hacminde bir sınır vardır.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.) Yoğun bir parça, tek bir bölümün 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, yük yaymak için parçanın yeniden bölümlenmesi gerekebilir.If so, the shard might need to be repartitioned to spread the load. Bu tabloların toplam boyutu veya üretilen iş miktarı bir depolama hesabının kapasitesini aşarsa, ek depolama hesapları oluşturmanız ve tabloları bu hesaplara yaymeniz 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, gerekli dizinlerin yerinde olduğundan 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ızlı bir şekilde gerçekleştirmesi gereken kritik sorguları öğrenmek 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ı bulun.Find which queries are performed most frequently. Tek bir sorgunun maliyeti düşük olsa bile, toplu 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çmesini sağlayacak şekilde 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 her iki stratejiyi de birleştirmek daha etkilidir.In most cases, a single partitioning strategy will suffice, but in some cases it is more efficient to combine both strategies.

  4. Performansı artırmak için sorguları 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 etkileyen 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. Hangi verilerin işlem gibi kritik iş bilgileri olduğunu ve günlük dosyaları gibi ne kadar kritik işletimsel verileri olduğunu belirler.Identify which data is critical business information, such as transactions, and which data is less critical operational data, such as log files.

  • Kritik verileri, uygun bir yedekleme planıyla yüksek oranda kullanılabilir bölümlerde depolamayı göz önünde bulundurun.Consider storing critical data in highly available partitions with an appropriate backup plan.

  • Farklı veri kümeleri için ayrı yönetim ve izleme yordamları 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ümlerin günlüğe kaydetme veya izleme bilgilerini tutan bölümlerden 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, diğer bölümlerdeki verilere erişen uygulamalar olmadan bağımsız olarak 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. Bu süre boyunca planlanmış bakımın tamamlanmasını engellemek için bölümlerin ç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ı iyileştirebilir, ancak aynı zamanda tutarlılık sorunlarıyla karşılaşabilirler.This strategy can improve availability and performance, but can also introduce consistency issues. Değişikliklerin her çoğaltmayla eşitlenmesi 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ümlendirme, sisteminizin tasarımına ve geliştirilmesine 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ümlemeyi bir daha düşündük olarak ele alırsanız, sürdürmek istediğiniz canlı bir sisteme zaten sahip olduğunuzdan 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ığının değiştirilmesi gerekir.Data access logic will need to be modified.
  • Büyük miktarlarda mevcut verilerin, bölümler arasında dağıtılması 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 sistemi kullanmaya devam edebilmelidir.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 doğru olabilir, ancak kullanıcıların sayısı arttıkça birçok ticari sistemin genişlemeleri gerekir.This might be true for some workloads, but many commercial systems need to expand as the number of users increases.

Üstelik, bölümlemeden faydalanabilir yalnızca büyük veri depoları 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şimi Işlemlerini en aza indirin.Minimize cross-partition data access operations. Mümkün olduğunda, bölümler arası veri erişim işlemlerini en aza indirmek için en sık kullanılan veritabanı işlemlerine yönelik verileri her bölümde birlikte tutun.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 sorgulanmasından daha fazla zaman alabilir, ancak tek bir sorgu kümesi için bölümleri iyileştirmek 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 yapmanız gerekiyorsa, 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. (Bir sorgudan elde edilen sonuç bir sonraki sorguda kullanıldığında olduğu gibi bazı durumlarda bu yaklaşım 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 verilerini ç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ıyorsa, farklı bölümlerdeki ayrı arama işlemlerini azaltmak için bu verileri tüm bölümlerde ç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 ayrıca, tüm sistem genelindeki yoğun trafiğe sahip olan başvuru verilerinin "etkin" bir veri kümesi olma 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 verilerinde yapılan değişiklikleri eşitlemeye ilişkin ek bir maliyet vardır.However, there is an additional cost associated with synchronizing any changes to the reference data.

Bölümler arası birleştirmeleri en aza indirin.Minimize cross-partition joins. Mümkün olduğunda, dikey ve işlevsel bölümlerde başvuru bütünlüğü için gereksinimleri en aza indirir.Where possible, minimize requirements for referential integrity across vertical and functional partitions. Bu düzenlerde, uygulama bölüm genelinde bilgi tutarlılığını sürdürmekten sorumludur.In these schemes, the application is responsible for maintaining referential integrity across partitions. Birden çok bölüm genelinde veri birleştiren sorgular verimsiz olduğundan, uygulamanın tipik olarak bir anahtara ve ardından yabancı anahtara göre ardışık sorgular gerçekleştirmesi gerekir.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şimler gerekliyse, bölümler üzerinde paralel sorgular çalıştırın ve uygulamadaki verileri birleştirin.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ış sistemlerdeki yaygın bir yaklaşım, nihai tutarlılığı uygulamaktır.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. Dikey ve işlevsel bölümlendirme ile, sorgular bölümü doğal olarak belirtebilir.With vertical and functional partitioning, queries can naturally specify the partition. Diğer yandan yatay bölümlendirme, her parça aynı şemaya sahip olduğu için bir öğeyi daha zor hale getirir.Horizontal partitioning, on the other hand, can make locating an item difficult, because every shard has the same schema. Belirli öğeler için parça konumunu aramak üzere kullanılan bir Haritayı sürdürmek için tipik bir çözümdü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.

Parçaların düzenli olarak yeniden dengelenmesini göz önünde bulundurun.Consider periodically rebalancing shards. Yatay bölümleme ile parçaları yeniden dengelemek, etkin noktaları en aza indirmek, sorgu performansını en üst düzeye çıkarmak ve fiziksel depolama sınırlamalarıyla çalışmak için verileri boyuta ve iş yüküne göre eşit bir şekilde dağıtmanıza 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ın.Replicate partitions. Her bölümü çoğaltdıysanı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 kopyaya 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 engellemek için verileri düzenli olarak (aylık gibi) arşivlemeniz ve silmeniz 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. Bir bölümdeki veriler gibi herhangi bir veri bütünlüğü sorununu bulmak için düzenli 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 bu sorunları otomatik olarak düzeltmeye veya el ile inceleme için bir rapor oluşturmaya çalışabilir.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 söz konusu olduğunda bölümleme şemasını 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 elde edebilir ve aşırı çekişme için sık erişimli 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 veri hacminin yeterince tahmin edilmiş olması, bazı bölümlerin kapasite sınırlarına yaklaşımına neden 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 dengeedebilir.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 stratejisi belirleme.Determine a new partitioning strategy.

    • Hangi bölümlerin bölünmesi (veya belki de büyük olasılıkla birleştirilmesi gerekir)?Which partitions need to be split (or possibly combined)?
    • Yeni bölüm anahtarı nedir?What is the new partition key?
  2. Eski bölümleme düzeninden verileri yeni bölüm kümesine geçirin.Migrate data from the old partitioning scheme to the new set of partitions.

Veri deposuna bağlı olarak, kullandıkları sırada verileri bölümler arasında geçirebilirsiniz.Depending on the data store, you might be able to migrate data between partitions while they are in use. Buna çevrimiçi geçişadı verilir.This is called online migration. Bu mümkün değilse, verilerin yeniden konumlandırılması sırasında bölümleri kullanılamaz hale getirmeniz 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

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

  1. Bölümü çevrimdışına işaretleyin.Mark the partition offline.
  2. Ayır-birleştirin ve verileri yeni bölümlere taşıyın.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ü kaldırın.Remove the old partition.

İsteğe bağlı olarak, bir bölümü adım 1 ' de salt okunurdur, böylece uygulamalar taşınırken verileri okuyabilirler.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ş yapmak için daha karmaşıktır ancak daha az kesintiye uğramıştır.Online migration is more complex to perform but less disruptive. Özgün bölüm çevrimdışı olarak işaretlenmediği sürece işlem çevrimdışı geçişe benzerdir.The process is similar to offline migration, except the original partition is not marked offline. Geçiş işleminin ayrıntı düzeyine (örneğin, öğeye göre öğe ve parça tarafından parça) bağlı olarak, istemci uygulamalarındaki veri erişim kodunun, iki konumda tutulan verileri okuma ve yazma işlemlerini işlemesi gerekebilir, özgün bölüm ve yeni bölümünüzün.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 senaryolarınızla ilgili olabilir:The following design patterns might be relevant to your scenario:

  • Parçalama deseninin verileri parçalara ayırma için bazı yaygın stratejiler açıklanmaktadır.The sharding pattern describes some common strategies for sharding data.

  • Dizin tablosu modelinde , veriler üzerinde ikincil dizinlerin nasıl oluşturulacağı gösterilmektedir.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 düzeninde hızlı sorgu işlemlerini desteklemek için verileri özetleyen önceden doldurulmuş görünümlerin nasıl oluşturulacağı açıklanır.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