Veri bölümleme stratejileri (Azure ile gerçek hayatta bulut uygulamaları oluşturma)Data Partitioning Strategies (Building Real-World Cloud Apps with Azure)

, Mike te son, Rick Anderson, Tom Dykstra tarafındanby Mike Wasson, Rick Anderson, Tom Dykstra

Onarma projesini indirin veya E-kitabı indirinDownload Fix It Project or Download E-book

Azure e-book Ile gerçek dünyada bulut uygulamaları oluşturma , Scott Guthrie tarafından geliştirilen bir sunuyu temel alır.The Building Real World Cloud Apps with Azure e-book is based on a presentation developed by Scott Guthrie. Bulut için Web Apps 'i başarılı bir şekilde geliştirmeye yardımcı olabilecek 13 desen ve uygulamaları açıklar.It explains 13 patterns and practices that can help you be successful developing web apps for the cloud. Seriler hakkında daha fazla bilgi için ilk bölümebakın.For information about the series, see the first chapter.

Daha önce, Web sunucuları ekleyerek ve kaldırarak bir bulut uygulamasının Web katmanını ölçeklendirmenin ne kadar kolay olduğunu gördük.Earlier we saw how easy it is to scale the web tier of a cloud application, by adding and removing web servers. Ancak bunların hepsi aynı veri deposuna geçerse, uygulamanızın performans sorunu ön uca arka uca, veri katmanı da ölçeklenir.But if they're all hitting the same data store, your application's bottleneck moves from the front-end to the back-end, and the data tier is the hardest to scale. Bu bölümde, verileri birden çok ilişkisel veritabanına bölümleyerek veya ilişkisel veritabanı depolamayı diğer veri depolama seçenekleriyle birleştirerek veri katmanınızı ölçeklenebilir hale getirme konusuna bakacağız.In this chapter we look at how you can make your data tier scalable by partitioning data into multiple relational databases, or by combining relational database storage with other data storage options.

Bölümleme şemasının ayarlanması, daha önce bahsedilen aynı nedene göre en iyi şekilde yapılır: bir uygulama üretim aşamasında olduktan sonra veri depolama stratejinizi değiştirmek çok zordur.Setting up a partitioning scheme is best done up front for the same reason mentioned earlier: it's very difficult to change your data storage strategy after an app is in production. Farklı yaklaşımlar hakkında daha fazla bilgi sahibi olmanız durumunda uygulamanızın verileri ve veri erişim kodunu yeniden görüntülerken uygulamanız kilitlenirse veya uzun süre geçtiğinde bir "Twitter" geçirmenize gerek kalmaktan kaçınabilirsiniz.If you think hard up front about different approaches, you can avoid having a "Twitter moment" when your app crashes or goes down for a long time while you reorganize your app's data and data access code.

Üç veri depolama alanıThe three Vs of data storage

Bölümleme stratejisi gerekip gerekmediğini ve ne olması gerektiğini belirlemek için verileriniz hakkında üç soruyu göz önünde bulundurun:In order to determine whether you need a partitioning strategy and what it should be, consider three questions about your data:

  • Hacim: sonunda ne kadar veri depolayacaksınız?Volume – How much data will you ultimately store? Birkaç gigabayt mı?A couple gigabytes? Birkaç yüz gigabayt mı?A couple hundred gigabytes? Terabayt?Terabytes? Petabaytlarca?Petabytes?
  • Hız: verilerinizin ne kadar büyüeceği hız nedir?Velocity – What is the rate at which your data will grow? Çok fazla veri oluşturmamayan bir iç uygulama mı?Is it an internal app that isn't generating a lot of data? Müşterilerin resimleri ve videoları karşıya yüklemesini sağlayacak bir dış uygulama mı?An external app that customers will be uploading images and videos into?
  • Çeşitli: hangi veri türlerini depolayacaksınız?Variety – What type of data will you store? İlişkisel, görüntüler, anahtar-değer çiftleri, sosyal grafikler?Relational, images, key-value pairs, social graphs?

Çok miktarda hacim, hız veya çeşitli özellikler olacağını düşünüyorsanız, uygulamanızın büyüdükçe ne tür bölümleme şemasının etkili ve etkili bir şekilde ölçeklenebileceğini dikkatlice düşünmeniz ve herhangi bir performans sorunu yaşanmamasını sağlamak zorunda kalmazsınız.If you think you're going to have a lot of volume, velocity, or variety, you have to carefully consider what kind of partitioning scheme will best enable your app to scale efficiently and effectively as it grows, and to ensure you don't run into any bottlenecks.

Bölümlemeye yönelik temel olarak üç yaklaşım vardır:There are basically three approaches to partitioning:

  • Dikey bölümlemeVertical partitioning
  • Yatay bölümlemeHorizontal partitioning
  • Karma bölümlendirmeHybrid partitioning

Dikey bölümlemeVertical partitioning

Dikey bağlantı noktası, tabloyu sütunlara göre bölmek gibidir: bir sütun kümesi bir veri deposuna gider ve başka bir sütun kümesi farklı bir veri deposuna gider.Vertical portioning is like splitting up a table by columns: one set of columns goes into one data store, and another set of columns goes into a different data store.

Örneğin, uygulamamın görüntüler dahil olmak üzere insanlarla veri depoladığını varsayalım:For example, suppose my app stores data about people, including images:

Veri tablosu

Bu verileri bir tablo olarak temsil ettiğinizde ve verilerin farklı varicilerine baktığımızda, sol taraftaki üç sütunun ilişkisel bir veritabanı tarafından etkili bir şekilde depolanabilecek dize verilerine sahip olduğunu, sağdaki iki sütunun ise c 'nin temel aldığı bayt dizileri olduğunu görebilirsiniz. görüntü dosyalarından ası.When you represent this data as a table and look at the different varieties of data, you can see that the three columns on the left have string data that can be efficiently stored by a relational database, while the two columns on the right are essentially byte arrays that come from image files. Görüntü dosyası verilerinin ilişkisel bir veritabanında depolanması mümkündür ve bu, verileri dosya sistemine kaydetmek istemediklerinden çok sayıda kişi tarafından yapılır.It's possible to store image file data in a relational database, and a lot of people do that because they don't want to save the data to the file system. Gerekli veri birimlerini depolayan bir dosya sistemine sahip olmayabilir veya ayrı bir yedekleme ve geri yükleme sistemini yönetmek istemeiyor olabilir.They might not have a file system capable of storing the required volumes of data or they might not want to manage a separate back-up and restore system. Bu yaklaşım, şirket içi veritabanları ve bulut veritabanlarındaki küçük miktarlarda veri için iyi sonuç verir.This approach works well for on-premises databases and for small amounts of data in cloud databases. Şirket içi ortamda, yalnızca DBA 'nın her şeyi ele geçirmesine olanak daha kolay olabilir.In the on-premises environment, it might be easier to just let the DBA take care of everything.

Ancak, bir bulut veritabanında, depolama görece pahalıdır ve yüksek miktarda görüntü, veritabanının boyutunu verimli bir şekilde çalışabilecek limitlerin ötesinde büyütebilirler.But in a cloud database, storage is relatively expensive, and a high volume of images could make the size of the database grow beyond the limits at which it can operate efficiently. Verileri dikey olarak bölümleyerek bu sorunları ele alabilir. Bu, veri tablonuzdaki her bir sütun için en uygun veri deposunu seçtiğiniz anlamına gelir.You can address these problems by partitioning the data vertically, which means you choose the most appropriate data store for each column in your table of data. Bu örnek için en iyi şekilde çalışmayabilir dize verilerini bir ilişkisel veritabanına ve BLOB depolamadaki görüntülere yerleştirmeye yöneliktir.What might work best for this example is to put the string data in a relational database and the images in Blob storage.

Dikey olarak bölümlenmiş veri tablosu

Dosya sunucularını ayarlama veya ilişkisel veritabanının dışında depolanan verilerin yedeklenmesini ve geri yüklenmesini yönetme konusunda endişelenmeniz olmadığından, görüntüleri bir veritabanı yerine blob depolamada depolamak, bulutta daha pratik bir şirket içi ortamdır. Bu, sizin için blob Storage hizmeti tarafından otomatik olarak gerçekleştirilir.Storing images in Blob storage instead of a database is more practical in the cloud than in an on-premises environment because you don't have to worry about setting up file servers or managing back-up and restore of data stored outside of the relational database: all that is handled for you automatically by the Blob storage service.

Bu, çözümü gidermeye uygulanan bölümlendirme yaklaşımına sahiptir ve BLOB depolamabölümünde buna ilişkin koda bakacağız.This is the partitioning approach we implemented in the Fix It app, and we'll look at the code for that in the Blob storage chapter. Bu bölümleme şeması olmadan ve ortalama bir görüntü boyutu olan 3 megabayt varsayıldığında, BT uygulamasının yalnızca en fazla 150 gigabayt veritabanı boyutunu vurmadan 40.000 görev depolayabilmesini sağlayabilecektir.Without this partitioning scheme, and assuming an average image size of 3 megabytes, the Fix It app would only be able to store about 40,000 tasks before hitting the maximum database size of 150 gigabytes. Görüntüler kaldırıldıktan sonra, veritabanı birçok görev için 10 kez veri saklayabilir; bir yatay bölümleme şeması uygulamayı düşünmek zorunda bırakmadan önce çok daha uzun bir süre izleyebilirsiniz.After removing the images, the database can store 10 times as many tasks; you can go much longer before you have to think about implementing a horizontal partitioning scheme. Uygulama ölçeklenirken, depolama gereksinimlerinizin toplu olarak çok pahalı BLOB depolama alanına gittiğinden, harcamalar daha yavaş büyütüyor.And as the app scales, your expenses grow more slowly because the bulk of your storage needs are going into very inexpensive Blob storage.

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

Yatay bağlantı noktası, tabloyu satırlara göre bölmek gibidir: bir dizi satır bir veri deposuna gider ve başka bir satır kümesi farklı bir veri deposuna gider.Horizontal portioning is like splitting up a table by rows: one set of rows goes into one data store, and another set of rows goes into a different data store.

Aynı veri kümesi verildiğinde, farklı veritabanlarındaki farklı müşteri adı aralıklarını depolamak başka bir seçenektir.Given the same set of data, another option would be to store different ranges of customer names in different databases.

Veri tablosu yatay olarak bölümlenmiş

Etkin noktaları önlemek için verilerin eşit bir şekilde dağıtıldığından emin olmak için, parçalara ayırma düzeniniz hakkında çok dikkatli olmak istiyorsunuz.You want to be very careful about your sharding scheme to make sure that data is evenly distributed in order to avoid hot spots. Son adın ilk harfini kullanan bu basit örnek, çok sayıda kişinin belirli ortak harflerle başlayan son adlara sahip olması nedeniyle bu gereksinimi karşılamaz.This simple example using the first letter of the last name doesn't meet that requirement, because a lot of people have last names that start with certain common letters. Tablo boyutu sınırlamalarından daha önceki bir deyişle, bazı veritabanlarının çok büyük olduğu, ancak küçük bir süre içinde kalacağından, bu işlem bekleyebilir.You'd hit table size limitations earlier than you might expect because some databases would get very large while most would remain small.

Yatay bölümlemenin aşağı bir kısmı verilerin tamamında sorgu yapmak zor olabilir.A down side of horizontal partitioning is that it might be hard to do queries across all of the data. Bu örnekte, uygulama tarafından depolanan tüm verileri almak için bir sorgunun en fazla 26 farklı veritabanından çizimi olması gerekir.In this example, a query would have to draw from up to 26 different databases to get all of the data stored by the app.

Karma bölümlendirmeHybrid partitioning

Dikey ve yatay bölümleme birleştirebilirsiniz.You can combine vertical and horizontal partitioning. Örneğin, örnek verilerde görüntüleri BLOB depolama alanında saklayabilir ve dize verilerini yatay olarak bölümleyebilirsiniz.For example, in the example data you could store the images in Blob storage and horizontally partition the string data.

Veri tablosu karma bölümlenmiş

Üretim uygulamasını bölümlendirmePartitioning a production application

Kavramsal olarak, bölümleme şemasının nasıl çalıştığını görmek kolaydır, ancak herhangi bir bölümleme şeması kod karmaşıklığını artırır ve ilgilenmeniz gereken birçok yeni karmaşıklıkları tanıtır.Conceptually it's easy to see how a partitioning scheme would work, but any partitioning scheme does increase code complexity and introduces many new complications that you have to deal with. Görüntüleri blob depolamaya taşıyorsanız, depolama hizmeti çalışmıyor ne olur?If you're moving images to blob storage, what do you do when the storage service is down? Blob güvenliğini nasıl işleyirsiniz?How do you handle blob security? Veritabanı ve BLOB depolama eşitlenmemiş olduğunda ne olur?What happens if the database and blob storage get out of sync? Parçalayorsanız, tüm veritabanlarına ilişkin sorgulamayı nasıl işleyeceğinizi istersiniz?If you're sharding, how will you handle querying across all of the databases?

Bu karmaşıklıklar, üretime geçmeden önce bunları planlarken planlama yaptığınız sürece yönetilebilir.The complications are manageable so long as you're planning for them before you go to production. Bunu yapması istemeyen birçok kişi daha sonra sahip olurlar.Many people who didn't do that wish they had later. Müşteri danışmanımız ekibi (CAT) ekibimiz, uygulamaları gerçekten büyük bir şekilde çalıştıkları müşterilerin bir ayda bir kez geçen ve bu planlamayı yapamadığımızdan, bu telefon görüşmelerini alır.On average our Customer Advisory Team (CAT) team gets panicked phone calls about once a month from customers whose apps are taking off in a really big way, and they didn't do this planning. Ve şöyle bir şey söyler: "yardım!And they say something like: "Help! Her şeyi tek bir veri deposuna yerleştirdim ve 45 gün içinde, boş alan kalmadı! "I put everything in a single data store, and in 45 days I'm going to run out of space on it!" Veri deponuza nasıl erişileceğiyle ilgili çok sayıda iş mantığı varsa ve uygulamanızı kullanan müşteriler varsa, geçiş sırasında bir gün için uygun bir zaman kalmaz.And if you have a lot of business logic built into how you access your data store and you have customers who are using your app, there's no good time to go down for a day while you migrate. Müşterinin verilerini bir süre boyunca bir süre boyunca bölümlendirmeye yardımcı olmak için hercuyalın çabalarıyla devam ediyoruz.We end up going through herculean efforts to help the customer partition their data on the fly with no down time. Bu çok heyecan verici ve çok Kordur, ancak bunu önlemek istediğiniz bir şey değildir!It's very exciting and very scary, and not something you want to be involved in if you can avoid it! Uygulamanın daha sonra büyümesi durumunda, bu ön ödemeli ve uygulamanızla tümleştirilmesi, yaşamınızı çok daha kolay hale getirir.Thinking about this up front and integrating it into your app will make your life a lot easier if the app grows later.

ÖzetSummary

Etkili bölümleme şeması, bulut uygulamanızın performans sorunlarını gidermek zorunda kalmadan buluttaki verilerin petabaytlarca ölçeklendirilmesini sağlayabilir.An effective partitioning scheme can enable your cloud app to scale to petabytes of data in the cloud without bottlenecks. Uygulamayı şirket içi bir veri merkezinde çalıştırıyorsanız, büyük ölçekli makinelere veya kapsamlı altyapıya yönelik ön ödeme yapmak zorunda kalmazsınız.And you don't have to pay up front for massive machines or extensive infrastructure as you might if you were running the app in an on-premises data center. Bulutta, ihtiyacınız olan kapasiteyi artımlı olarak ekleyebilir ve yalnızca kullandığınızda kullandığınız kadar ödeyerek ödeme yaparsınız.In the cloud you can incrementally add capacity as you need it, and you're only paying for as much as you're using when you use it.

Sonraki bölümde , BT uygulamasının, blob depolamada resimleri depolayarak dikey bölümleme uygulayıp uygulamadığını öğreneceğiz.In the next chapter we'll see how the Fix It app implements vertical partitioning by storing images in Blob storage.

KaynaklarResources

Bölümleme stratejileri hakkında daha fazla bilgi için aşağıdaki kaynaklara bakın.For more information about partitioning strategies, see the following resources.

BelgelerleDocumentation:

Videolar:Videos:

  • Failsafe: ölçeklenebilir, dayanıklı Cloud Services oluşturma.FailSafe: Building Scalable, Resilient Cloud Services. Ulrich Homann, Marc Mercuri ve Mark Simms ile dokuz bölümden oluşan seriler.Nine-part series by Ulrich Homann, Marc Mercuri, and Mark Simms. , Microsoft Müşteri danışmanlık ekibi (CAT) deneyiminden gerçek müşterilerle çekilen hikayelerle, yüksek düzeyde kavramlar ve mimari ilkeleri çok erişilebilir ve ilginç bir şekilde sunar.Presents high-level concepts and architectural principles in a very accessible and interesting way, with stories drawn from Microsoft Customer Advisory Team (CAT) experience with actual customers. Bölüm 7 ' de bölümlendirme tartışmasına bakın.See the partitioning discussion in episode 7.
  • Oluşturma büyük: Windows Azure müşterileri-bölüm ı 'den öğrenilen dersler. Simms 'yi işaretlemek, bölüm düzenlerini, parçalama stratejilerini, parçalara ayırma ve SQL veritabanı federasyonlarını 19:49 adresinden başlayarak anlatmaktadır.Building Big: Lessons learned from Windows Azure customers - Part I. Mark Simms discusses partitioning schemes, sharding strategies, how to implement sharding, and SQL Database Federations, starting at 19:49. Failsafe serisine benzer ancak daha fazla nasıl yapılır ayrıntılarına gider.Similar to the Failsafe series but goes into more how-to details.

Örnek kod:Sample code: