Veri Depolama Seçenekleri (Azure ile Real-World Cloud Apps Oluşturma)

Tarafından Rick Anderson, Tom Dykstra

Fix It Project'i indirin veya E-kitap indirin

Azure ile Gerçek Dünya Bulut Uygulamaları Oluşturma e-kitabı, Scott Guthrie tarafından geliştirilen bir sunuyu temel alır. Bulut için web uygulamalarını başarıyla geliştirmenize yardımcı olabilecek 13 desen ve uygulama açıklanmaktadır. E-kitap hakkında bilgi için ilk bölüme bakın.

Çoğu kişi ilişkisel veritabanlarına alışkındır ve bulut uygulaması tasarlarken diğer veri depolama seçeneklerini gözden kaçırma eğilimindedir. NoSQL (ilişkisel olmayan) veritabanları bazı görevleri ilişkisel veritabanlarından daha verimli bir şekilde işleyebildiğinden sonuç yetersiz performans, yüksek giderler veya daha kötüsü olabilir. Müşteriler kritik bir veri depolama sorununu çözmek için bizden yardım istediklerinde, bunun nedeni genellikle NoSQL seçeneklerinden birinin daha iyi çalışabileceği ilişkisel bir veritabanına sahip olmalarıdır. Bu gibi durumlarda müşteri, uygulamayı üretime dağıtmadan önce NoSQL çözümünü uygulamış olsaydı daha iyi olurdu.

Öte yandan, bir NoSQL veritabanının her şeyi iyi veya yeterince iyi yapabileceğini varsaymak da bir hata olabilir. Tüm veri depolama görevleri için tek bir en iyi veri yönetimi seçeneği yoktur; farklı veri yönetimi çözümleri farklı görevler için iyileştirilmiştir. Çoğu gerçek dünya bulut uygulaması çeşitli veri depolama gereksinimlerine sahiptir ve genellikle birden çok veri depolama çözümünün birleşimiyle en iyi şekilde sunulur.

Bu bölümün amacı, size bir bulut uygulamasında kullanılabilen veri depolama seçenekleri hakkında daha geniş bir fikir vermek ve senaryonuza uygun olanları seçmeye yönelik bazı temel yönergeler sunmaktır. En iyisi, bir uygulama geliştirmeden önce kullanabileceğiniz seçeneklerin farkında olmak ve güçlü ve zayıf yönlerini düşünmektir. Bir üretim uygulamasında veri depolama seçeneklerini değiştirmek, uçak uçuş sırasında bir jet motorunu değiştirmek zorunda kalmak gibi son derece zor olabilir.

Azure'da veri depolama seçenekleri

Bulut, çeşitli ilişkisel ve NoSQL veri depolarını kullanmayı nispeten kolaylaştırır. Azure'da kullanabileceğiniz veri depolama platformlarından bazıları aşağıdadır.

Azure'ın NoSQL veri depolarında veri depolama seçeneklerini gösteren tablo grafiğini gösteren ekran görüntüsü

Tabloda dört tür NoSQL veritabanı gösterilmektedir:

  • Anahtar/değer veritabanları, her anahtar değeri için tek bir serileştirilmiş nesne depolar. Bunlar, belirli bir anahtar değeri için bir öğe almak istediğiniz ve öğenin diğer özelliklerine göre sorgulamanız gerekmeyen büyük hacimli verileri depolamak için uygundur.

    Azure Blob depolama , klasör ve dosya adlarına karşılık gelen anahtar değerleriyle bulutta dosya depolama gibi işlev gösteren bir anahtar/değer veritabanıdır. Dosyayı, dosya içeriğindeki değerleri arayarak değil, klasörüne ve dosya adına göre alırsınız.

    Azure Tablo depolama aynı zamanda bir anahtar/değer veritabanıdır. Her değer varlık olarak adlandırılır (bölüm anahtarı ve satır anahtarıyla tanımlanan satıra benzer) ve birden çok özellik içerir (sütunlara benzer, ancak tablodaki tüm varlıkların aynı sütunları paylaşması gerekmez). Anahtar dışındaki sütunlarda sorgulama son derece verimsizdir ve bundan kaçınılmalıdır. Örneğin, tek bir kullanıcıyla ilgili bilgileri depoladığınız bir bölümle kullanıcı profili verilerini depolayabilirsiniz. Kullanıcı adı, parola karması, doğum tarihi gibi verileri bir varlığın ayrı özelliklerinde veya aynı bölümdeki ayrı varlıklarda depolayabilirsiniz. Ancak belirli bir doğum tarihi aralığına sahip tüm kullanıcıları sorgulamak istemezsiniz ve profil tablonuzla başka bir tablo arasında birleştirme sorgusu yürütemezsiniz. Tablo depolama, ilişkisel veritabanından daha ölçeklenebilir ve daha ucuzdur, ancak karmaşık sorguları veya birleştirmeleri etkinleştirmez.

  • Documentdatabases , değerlerin belge olduğu anahtar/değer veritabanlarıdır. Buradaki "Belge", bir Word veya Excel belgesi anlamında kullanılmaz, ancak herhangi biri alt belge olabilecek adlandırılmış alanlar ve değerler koleksiyonu anlamına gelir. Örneğin, sipariş geçmişi tablosunda bir sipariş belgesinde sipariş numarası, sipariş tarihi ve müşteri alanları olabilir; ve müşteri alanında ad ve adres alanları olabilir. Veritabanı alan verilerini XML, YAML, JSON veya BSON gibi bir biçimde kodlar; veya düz metin kullanabilir. Belge veritabanlarını anahtar/değer veritabanlarından ayrı olarak ayarlayan bir özellik, anahtar olmayan alanlarda sorgulama ve sorgulamayı daha verimli hale getirmek için ikincil dizinler tanımlama özelliğidir. Bu özellik, belge veritabanını ölçütlere göre veri alması gereken uygulamalar için belge anahtarının değerinden daha karmaşık hale getirir. Örneğin, satış siparişi geçmişi belge veritabanında ürün kimliği, müşteri kimliği, müşteri adı gibi çeşitli alanları sorgulayabilirsiniz. MongoDB popüler bir belge veritabanıdır.

  • Sütun ailesi veritabanları , veri depolama alanını sütun aileleri adı verilen ilgili sütun koleksiyonları halinde yapılandırmanızı sağlayan anahtar/değer veri depolarıdır. Örneğin, sayım veritabanında bir kişinin adı için bir sütun grubu (ilk, orta, son), kişinin adresi için bir grup ve kişinin profil bilgileri için bir grup (DOB, cinsiyet vb.) bulunabilir. Veritabanı daha sonra her sütun ailesini ayrı bir bölümde depolayabilir ve aynı anahtarla ilgili bir kişinin tüm verilerini tutabilir. Ardından, tüm ad ve adres bilgilerini okumak zorunda kalmadan tüm profil bilgilerini okuyabilirsiniz. Cassandra popüler bir sütun ailesi veritabanıdır.

  • Graph veritabanları bilgileri bir nesne ve ilişki koleksiyonu olarak depolar. Graf veritabanının amacı, bir uygulamanın nesnelerin ağından ve aralarındaki ilişkilerden geçen sorguları verimli bir şekilde gerçekleştirmesini sağlamaktır. Örneğin, nesneler bir insan kaynakları veritabanında çalışanlar olabilir ve "Scott için doğrudan veya dolaylı olarak çalışan tüm çalışanları bulma" gibi sorguları kolaylaştırmak isteyebilirsiniz. Neo4j popüler bir graf veritabanıdır.

İlişkisel veritabanlarıyla karşılaştırıldığında, NoSQL seçenekleri yapılandırılmamış verilerin depolanması ve analizi için çok daha fazla ölçeklenebilirlik ve uygun maliyetlilik sunar. Bunun dezavantajı, ilişkisel veritabanlarının zengin sorgulanabilirlik ve güçlü veri bütünlüğü özelliklerini sağlamamalarıdır. NoSQL, birleştirme sorgularına gerek olmadan yüksek hacim içeren IIS günlük verileri için iyi çalışır. NoSQL, mutlak veri bütünlüğü gerektiren ve hesapla ilgili diğer verilerle birçok ilişki içeren bankacılık işlemleri için bu kadar iyi çalışmaz.

NoSQL veritabanının ölçeklenebilirliğini ilişkisel veritabanının sorgulanabilirliği ve işlem bütünlüğüyle birleştiren NewSQL adlı daha yeni bir veritabanı platformu kategorisi de vardır. NewSQL veritabanları, genellikle "OldSQL" veritabanlarında uygulanması zor olan dağıtılmış depolama ve sorgu işleme için tasarlanmıştır. NuoDB , Azure'da kullanılabilecek bir NewSQL veritabanı örneğidir.

Hadoop ve MapReduce

NoSQL veritabanlarında depolayabileceğiniz yüksek hacimli verilerin zamanında verimli bir şekilde analiz edilmesi zor olabilir. Bunu yapmak için MapReduce işlevselliğini uygulayan Hadoop gibi bir çerçeve kullanabilirsiniz. Temelde MapReduce işleminin yaptığı şey şunlardır:

  • Veri deposundan yalnızca analiz etmeniz gereken verileri seçerek işlenmesi gereken verilerin boyutunu sınırlayın. Örneğin, doğum yılına göre kullanıcı tabanınızın makyajını bilmek istiyorsunuz, bu nedenle kullanıcı profili veri deponuzdan yalnızca doğum yıllarını seçersiniz.
  • Verileri parçalara ayırıp işlenmek üzere farklı bilgisayarlara gönderin. Bilgisayar A, 1950-1959 tarihleri olan kişi sayısını hesaplar, B bilgisayarı 1960-1969 vb. yapar. Bu bilgisayar grubu Hadoop kümesi olarak adlandırılır.
  • Parçalar üzerinde işlem tamamlandıktan sonra her parçanın sonuçlarını yeniden bir araya getirin. Artık her doğum yılı için kaç kişi olduğunu ve bu genel listedeki yüzdeleri hesaplama görevinin yönetilebilir olduğunu görece kısa bir listeniz var.

Azure'da HDInsight , Hadoop'un gücünü kullanarak büyük verileri işlemenize, analiz etmenize ve yeni içgörüler elde etmenize olanak tanır. Örneğin, web sunucusu günlüklerini analiz etmek için bunu kullanabilirsiniz:

  • Depolama hesabınızda web sunucusu günlüğünü etkinleştirin. Bu, Azure'ı uygulamanıza yapılan her HTTP isteği için Blob Hizmeti'ne günlük yazacak şekilde ayarlar. Blob Hizmeti temel olarak bulut dosya depolama alanıdır ve HDInsight ile güzel bir şekilde tümleşir.

    Blob Depolamaya Günlükler

  • Uygulama trafik aldığında web sunucusu IIS günlükleri Blob depolamaya yazılır.

    Web sunucusu günlükleri

  • Portalda Yeni - Veri Hizmetleri - HDInsight - Hızlı Oluşturma'ya tıklayın ve HDInsight kümesi adı, küme boyutu (HDInsight kümesi veri düğümlerinin sayısı) ve HDInsight kümesi için bir kullanıcı adı ve parola belirtin.

    HDInsight

Artık günlüklerinizi analiz etmek ve aşağıdaki gibi soruların yanıtlarını almak için MapReduce işleri ayarlayabilirsiniz:

  • Uygulamam en çok veya en az trafiği günün hangi zamanları alır?
  • Trafiğim hangi ülkelerden geliyor?
  • Trafiğimin geldiği alanların ortalama mahalle geliri nedir? (Size IP adresine göre mahalle geliri sağlayan genel bir veri kümesi vardır ve bunu web sunucusu günlüklerindeki IP adresiyle eşleştirebilirsiniz.)
  • Mahalle gelirleri sitedeki belirli sayfa veya ürünlerle nasıl bağıntılı?

Daha sonra, bir müşterinin belirli bir ürünle ilgilenmesi veya satın alma olasılığına bağlı olarak reklamları hedeflemek için bu gibi soruların yanıtlarını kullanabilirsiniz.

Her Şeyi Otomatikleştirme bölümünde açıklandığı gibi, portalda gerçekleştirebileceğiniz işlevlerin çoğu otomatikleştirilebilir ve BU, HDInsight analiz işlerini ayarlamayı ve yürütmeyi içerir. Tipik bir HDInsight betiği aşağıdaki adımları içerebilir:

  • HdInsight kümesi sağlayın ve Blob depolama girişi için bunu depolama hesabınıza bağlayın.
  • MapReduce işi yürütülebilir dosyalarını (.jar veya .exe dosyaları) HDInsight kümesine yükleyin.
  • Çıktı verilerini Blob depolamaya depolayan bir MapReduce gönderin.
  • İşin tamamlanmasını bekleyin.
  • HDInsight kümesini silin.
  • Blob depolamadan çıkışa erişin.

Tüm bunları yapan bir betik çalıştırarak HDInsight kümesinin sağlandığı süreyi en aza indirir ve maliyetlerinizi en aza indirirsiniz.

Hizmet Olarak Platform (PaaS) ile Hizmet Olarak Altyapı (IaaS) karşılaştırması

Daha önce listelenen veri depolama seçenekleri hem Hizmet Olarak Platform (PaaS) hem de Hizmet Olarak Altyapı (IaaS) çözümlerini içerir. PaaS, donanım ve yazılım altyapısını yönettiğimiz ve yalnızca hizmeti kullandığınız anlamına gelir. SQL Veritabanı, Azure'ın paaS özelliğidir. Veritabanlarını istiyorsunuz ve arka planda Azure VM'leri ayarlayıp yapılandırıyor ve veritabanlarını bu veritabanlarını ayarlııyor. VM'lere doğrudan erişiminiz yoktur ve bunları yönetmeniz gerekmez. IaaS, veri merkezi altyapımızda çalışan VM'leri ayarladığınız, yapılandırdığınız ve yönettiğiniz ve bunlara istediğiniz her şeyi yerleştirdiğiniz anlamına gelir. Yaygın VM yapılandırmaları için önceden yapılandırılmış VM görüntülerinin bir galerisini sunuyoruz. Örneğin, Windows Server 2008, Windows Server 2012, BizTalk Server, Oracle WebLogic Server, Oracle Database vb. için önceden yapılandırılmış VM görüntülerini yükleyebilirsiniz.

Azure'ın sunduğu PaaS veri çözümleri şunlardır:

  • Azure SQL Veritabanı (eski adıyla SQL Azure). SQL Server tabanlı bir bulut ilişkisel veritabanı.
  • Azure Tablo depolama. Anahtar/değer NoSQL veritabanı.
  • Azure Blob depolama. Bulutta dosya depolama.

IaaS için vm'ye yükleyebileceğiniz her şeyi çalıştırabilirsiniz, örneğin:

  • SQL Server, Oracle, MySQL, SQL Compact, SQLite veya Postgres gibi ilişkisel veritabanları.
  • Memcached, Redis, Cassandra ve Riak gibi anahtar/değer veri depoları.
  • HBase gibi sütun veri depoları.
  • MongoDB, RavenDB ve CouchDB gibi belge veritabanları.
  • Neo4j gibi graf veritabanları.

Azure'da veri depolama seçenekleri

IaaS seçeneği size neredeyse sınırsız veri depolama seçeneği sunar ve önceden yapılandırılmış görüntüleri kullanarak VM'ler oluşturabildiğiniz için bunların birçoğunun kullanımı özellikle kolaydır. Örneğin, yönetim portalında Sanal Makineler gidin, Resimler sekmesine tıklayın ve VM Deposuna Gözat'a tıklayın.

VM Deposuna Gözat

Ardından önceden yapılandırılmış yüzlerce VM görüntüsünün listesini görürsünüz ve MongoDB, Neo4J, Redis, Cassandra veya CouchDB gibi önceden yüklenmiş bir veritabanı yönetim sisteminin bulunduğu bir görüntüden VM oluşturabilirsiniz:

VM Deposunda MongoDB

Azure, IaaS veri depolama seçeneklerinin olabildiğince kolay kullanılmasını sağlar, ancak PaaS tekliflerinin birçok senaryo için daha uygun maliyetli ve pratik olmasını sağlayan birçok avantajı vardır:

  • VM'ler oluşturmanız gerekmez, veri deposu ayarlamak için portalı veya betiği kullanmanız gerekir. 200 terabaytlık bir veri deposu istiyorsanız, bir düğmeye tıklamanız veya bir komut çalıştırmanız yeterlidir ve saniyeler içinde kullanmaya hazır olursunuz.
  • Hizmet tarafından kullanılan VM'leri yönetmeniz veya düzeltme eki uygulamanız gerekmez; Microsoft bunu sizin için otomatik olarak yapar.- Ölçeklendirme veya yüksek kullanılabilirlik için altyapıyı ayarlama konusunda endişelenmenize gerek yoktur; Microsoft tüm bunları sizin için halleder.
  • Lisans satın almanız gerekmez; lisans ücretleri hizmet ücretlerine dahildir.
  • Sadece kullandığınız kadar ödersiniz.

Azure'daki PaaS veri depolama seçenekleri, üçüncü taraf sağlayıcıların tekliflerini içerir.

Veri depolama seçeneğini belirleme

Hiçbir yaklaşım tüm senaryolar için doğru değildir. Herhangi biri bu teknolojinin yanıt olduğunu söylerse, sorulacak ilk şey "Soru nedir?", çünkü farklı çözümler farklı şeyler için iyileştirilmiştir. İlişkisel modelin kesin avantajları vardır; Bu yüzden uzun zamandır buralarda. Ancak SQL'in bir NoSQL çözümüyle ele alınabilecek alt tarafları da vardır.

Genellikle en iyi gördüğümüz şey, SQL ve NoSQL'i tek bir çözümde kullandığınız bileşimsel bir yaklaşımdır. İnsanlar NoSQL'i benimsediklerini söylediklerinde bile, ne yaptıklarının detayına giderseniz sık sık birkaç farklı NoSQL çerçevesi kullandıklarını fark edebilirsiniz: CouchDB, Redis ve Riak'i farklı şeyler için kullanıyorlar. NoSQL'i yoğun bir şekilde kullanan Facebook bile hizmetin farklı bölümleri için farklı NoSQL çerçeveleri kullanır. Birden çok veri çözümünü kullanmak ve bunları tek bir uygulamada tümleştirmek kolay olduğundan, veri depolama yaklaşımlarını karıştırma ve eşleştirme esnekliği, bulutla ilgili en iyi şeylerden biridir.

Bir yaklaşımı seçerken düşünmeniz gereken bazı sorular şunlardır:

Veri semantiği - Temel veri depolama ve veri erişimi semantiği nedir (ilişkisel veya yapılandırılmamış verileri depoluyor musunuz)? Medya dosyaları gibi yapılandırılmamış veriler blob depolamaya en uygun olanıdır; ürünler, envanterler, tedarikçiler, müşteri siparişleri vb. gibi ilgili verilerin bir koleksiyonu ilişkisel bir veritabanına en uygun olanıdır.
Sorgu desteği - Verileri sorgulamak ne kadar kolay? - Ne tür sorular verimli bir şekilde sorulabilir? Anahtar/değer veri depoları, anahtar değeri verilen tek bir satırı almada çok iyidir, ancak karmaşık sorgular için bu kadar iyi değildir. Belirli bir kullanıcının verilerini her zaman almakta olduğunuz bir kullanıcı profili veri deposu için anahtar/değer veri deposu iyi çalışabilir; çeşitli ürün özniteliklerine göre farklı gruplandırmalar almak istediğiniz bir ürün kataloğu için ilişkisel veritabanı daha iyi çalışabilir. NoSQL veritabanları büyük hacimli verileri verimli bir şekilde depolayabilir, ancak veritabanını uygulamanın verileri sorgulama şekline göre yapılandırmanız gerekir ve bu da geçici sorguların daha zor olmasını sağlar. İlişkisel bir veritabanıyla neredeyse her tür sorgu oluşturabilirsiniz.
İşlevsel projeksiyon - Sorular, toplamalar vb. sunucu tarafında yürütülebilir mi? SELECT COUNT(*) öğesini SQL'deki bir tablodan çalıştırırsam, sunucudaki tüm işleri çok verimli bir şekilde yapar ve aradığım sayıyı döndürür. Toplamayı desteklemeyen bir NoSQL veri deposundan aynı hesaplamayı yapmak istersem, bu verimsiz bir "ilişkisiz sorgudur" ve büyük olasılıkla zaman aşımına uğradı. Sorgu başarılı olsa bile sunucudan istemciye tüm verileri alıp istemcideki satırları saymalıyım. - Hangi diller veya ifade türleri kullanılabilir? İlişkisel bir veritabanıyla SQL'i kullanabilirim. Azure Tablo depolama gibi bazı NoSQL veritabanlarında OData'yı kullanacağım ve tek yapabileceğim birincil anahtara göre filtrelemek ve projeksiyonlar almak (kullanılabilir alanların bir alt kümesini seçin).
Ölçeklenebilirlik kolaylığı - Verilerin ne sıklıkta ve ne kadar ölçeklendirilmesi gerekir? - Platform yerel olarak ölçek genişletme uyguluyor mu? - Kapasite eklemek/kaldırmak (boyut ve aktarım hızı) ne kadar kolay? İlişkisel veritabanları ve tablolar, ölçeklenebilir hale getirmek için otomatik olarak bölümlenmez, bu nedenle belirli sınırlamaların ötesinde ölçeklendirmek zordur. Azure Tablo depolama gibi NoSQL veri depoları doğal olarak her şeyi bölümler ve bölüm eklemenin neredeyse hiçbir sınırı yoktur. Tablo Depolama'yı 200 terabayta kadar kolayca ölçeklendikleyebilirsiniz, ancak Azure SQL Veritabanı için maksimum veritabanı boyutu 500 gigabayttır. İlişkisel verileri birden çok veritabanına bölümleyerek ölçeklendirin, ancak bir uygulamayı bu modeli destekleyecek şekilde ayarlamak çok fazla programlama işi içerir.
İzleme ve Yönetilebilirlik - Platformun izlemesi, izlemesi ve yönetmesi ne kadar kolay? Veri deponuzun durumu ve performansı hakkında bilgi sahibi olmanız gerekir. Bu nedenle bir platformun size ücretsiz olarak hangi ölçümleri sağladığını ve kendinizi geliştirmeniz gerekenleri önceden bilmeniz gerekir.
Operations - Platform Azure'da ne kadar kolay dağıtılır ve çalıştırılır? Paas? IaaS mi? Linux? Tablo Depolama ve SQL Veritabanı Azure'da kolayca ayarlanabilir. Yerleşik Azure PaaS çözümleri olmayan platformlar daha fazla çaba gerektirir.
API Desteği - Platformla çalışmayı kolaylaştıran bir API kullanılabilir mi? Azure Tablo Hizmeti için .NET 4.5 zaman uyumsuz programlama modelini destekleyen .NET API'sine sahip bir SDK vardır. Bir .NET uygulaması yazıyorsanız Azure Tablo Hizmeti için kod yazmak ve test etmek, API içermeyen veya daha az kapsamlı olan başka bir anahtar/değer sütunu veri deposu platformuna kıyasla çok daha kolay olacaktır.
İşlem bütünlüğü ve veri tutarlılığı - Platformun veri tutarlılığını garanti etmek için işlemleri desteklemesi kritik mi? Gönderilen toplu e-postaları izlemek için performans ve düşük veri depolama maliyeti, veri platformundaki işlemler veya bilgi tutarlılığı için otomatik destekten daha önemli olabilir ve Bu da Azure Tablo Hizmeti'ni iyi bir seçim haline getirir. Banka hesap bakiyelerini veya satın alma siparişlerini izlemek için güçlü işlem garantileri sağlayan ilişkisel bir veritabanı platformu daha iyi bir seçim olabilir.
İş sürekliliği - Yedekleme, geri yükleme ve olağanüstü durum kurtarma ne kadar kolaydır? Er ya da geç üretim verileri bozulacak ve geri alma işlevine ihtiyacınız olacak. İlişkisel veritabanları genellikle belirli bir noktaya geri yükleme gibi daha ayrıntılı geri yükleme özelliklerine sahiptir. Düşündüğünüz her platformda hangi geri yükleme özelliklerinin kullanılabilir olduğunu anlamak, dikkate alınması gereken önemli bir faktördür.
Maliyet - Birden fazla platform veri iş yükünüzü destekleyebilirse maliyetle karşılaştırması nasıl yapılır? Örneğin, ASP.NET Identity kullanıyorsanız, kullanıcı profili verilerini Azure Tablo Hizmeti'nde veya Azure SQL Veritabanı'nda depolayabilirsiniz. SQL Veritabanı zengin sorgulama olanaklarına ihtiyacınız yoksa, belirli bir depolama alanı için maliyeti çok daha düşük olduğundan Azure Tablolarını kısmen seçebilirsiniz.

Genel olarak önerdiğimiz şey, veri depolama çözümlerinizi seçmeden önce bu kategorilerin her birinde yer alan soruların yanıtını bilmektir.

Buna ek olarak, iş yükünüz bazı platformların diğerlerinden daha iyi destekleyebilecek belirli gereksinimlere sahip olabilir. Örneğin:

  • Uygulamanız için denetim özellikleri gerekiyor mu?
  • Veri uzun kullanım gereksinimleriniz nelerdir? Otomatik arşivleme veya temizleme özelliklerine ihtiyacınız var mı?
  • Özel güvenlik gereksinimleriniz var mı? Örneğin, veriler PII'yi (kişisel olarak tanımlanabilir bilgiler) içerir, ancak PII'nin sorgu sonuçlarından hariç tutulduğundan emin olmanız gerekir.
  • Mevzuat veya teknolojik nedenlerle bulutta depolanemeyen bazı verileriniz varsa, şirket içi depolama alanınızla tümleştirmeyi kolaylaştıran bir bulut veri depolama platformuna ihtiyacınız olabilir.

Tanıtım – Azure'da SQL Veritabanı kullanma

Düzelt uygulaması, görevleri depolamak için ilişkisel bir veritabanı kullanır. Her Şeyi Otomatikleştir bölümünde gösterilen ortam oluşturma Windows PowerShell betiği iki SQL Veritabanı örneği oluşturur. Bunları portalda SQL Veritabanları sekmesine tıklayarak görebilirsiniz.

Portalda SQL Veritabanları

Portalı kullanarak veritabanı oluşturmak da kolaydır.

Yeni -- Veri Hizmetleri -- SQL Veritabanı -- Kimlik Oluştur'a tıklayın, bir veritabanı adı girin, hesabınızda zaten var olan bir sunucuyu seçin veya yeni bir sunucu oluşturun ve SQL Veritabanı Oluştur'a tıklayın.

Yeni SQL Veritabanı

Birkaç saniye bekleyin ve Azure'da kullanmaya hazır bir veritabanınız var.

Yeni SQL Veritabanı oluşturuldu

Bu nedenle Azure, şirket içi ortamda gerçekleştirmeniz bir gün veya bir hafta ya da daha uzun sürebilecek işlemleri birkaç saniye içinde yapar. Ayrıca, bir betikte veya yönetim API'sini kullanarak aynı şekilde kolayca veritabanı oluşturabildiğiniz için, uygulamanız bunun için programlanmış olduğu sürece verilerinizi birden çok veritabanına dağıtarak ölçeği dinamik olarak genişletebilirsiniz.

Bu, Hizmet Olarak Platform modelimizin bir örneğidir. Sunucuları yönetmek zorunda değilsiniz, biz yaparız. Yedeklemeler konusunda endişelenmenize gerek yok, bunu yapıyoruz. Yüksek kullanılabilirlik içinde çalışıyor; veritabanındaki veriler otomatik olarak üç sunucu arasında çoğaltılır. Bir makine ölürse otomatik olarak yük devrederiz ve veri kaybetmezsiniz. Sunucuya düzenli olarak yama yapılır, bu konuda endişelenmenize gerek yoktur.

Bir düğmeye tıkladığınızda tam olarak ihtiyacınız olan bağlantı dizesini alırsınız ve yeni veritabanını kullanmaya hemen başlayabilirsiniz.

Bağlantı dizeleri

Panoda bağlantı geçmişi ve kullanılan depolama alanı miktarı gösterilir.

SQL Veritabanı Panosu

Veritabanlarını portalda veya SQL Server Management Studio (SSMS) ve Visual Studio araçları SQL Server Nesne Gezgini (SSOX) ve Sunucu Gezgini gibi zaten bildiğiniz SQL Server araçları kullanarak yönetebilirsiniz.

SSOX

Bir diğer güzel şey de fiyatlandırma modelidir. 20 MB'lık ücretsiz bir veritabanıyla geliştirmeye başlayabilirsiniz ve üretim veritabanı ayda yaklaşık 5 ABD doları ile başlar. Maksimum kapasite için değil yalnızca veritabanında depoladığınız veri miktarı için ödeme yapın. Lisans satın almanız gerekmez.

SQL Veritabanı kolayca ölçeklendirilebilir. Düzelt uygulaması için otomasyon betiğimizde oluşturduğumuz veritabanı 1 gig ile sınırlanır. Ölçeği 150 gig'a kadar genişletmek istiyorsanız portala gidip bu ayarı değiştirebilir veya rest API komutu yürütebilirsiniz. Saniyeler içinde verileri dağıtabileceğiniz 150 gig veritabanınız olur.

SQL Veritabanı sürümleri ve boyutları

Bu, bulutun altyapıyı hızlı ve kolay bir şekilde ayağa kaldırıp hemen kullanmaya başlamasının gücü.

Düzelt uygulaması biri üyelik (kimlik doğrulaması ve yetkilendirme) ve diğeri veriler için olmak üzere iki SQL veritabanı kullanır ve bunu sağlamak ve ölçeklendirmek için yapmanız gereken tek şey budur. Veritabanlarını Windows PowerShell betikler aracılığıyla sağlamayı daha önce gördünüz ve şimdi portalda ne kadar kolay olduğunu gördünüz.

ADO.NET kullanarak Entity Framework ile doğrudan veritabanı erişimi karşılaştırması

Düzelt uygulaması, Microsoft'un .NET uygulamaları için önerdiği ORM (nesne ilişkisel eşleyici) Entity Framework'i kullanarak bu veritabanlarına erişir. ORM, geliştirici üretkenliğini kolaylaştıran harika bir araçtır, ancak üretkenlik bazı senaryolarda performansın düşmesine neden olur. Gerçek dünyadaki bir bulut uygulamasında EF kullanmakla doğrudan ADO.NET kullanmak arasında seçim yapmayacaksınız; her ikisini de kullanacaksınız. Çoğu zaman veritabanıyla çalışan bir kod yazarken en yüksek performansı elde etme kritik değildir ve Entity Framework ile elde ettiğiniz basitleştirilmiş kodlama ve testlerden yararlanabilirsiniz. EF yükünün kabul edilemez performansa neden olacağı durumlarda, saklı yordamları çağırarak ideal olarak ADO.NET kullanarak kendi sorgularınızı yazabilir ve yürütebilirsiniz.

Veritabanına erişmek için hangi yöntemi kullanırsanız kullanın, "sohbeti" mümkün olduğunca en aza indirmek istiyorsunuz. Başka bir deyişle, ihtiyacınız olan tüm verileri onlarca veya yüzlerce küçük sorgu sonuç kümesi yerine daha büyük bir sorgu sonuç kümesinde alabilirseniz, bu genellikle tercih edilir. Örneğin, öğrencileri ve kayıtlı oldukları dersleri listelemeniz gerekiyorsa, öğrencileri tek sorguya almak ve her öğrencinin dersleri için ayrı sorgular yürütmek yerine tüm verileri tek bir birleştirme sorgusunda almak genellikle daha iyidir.

Düzelt uygulamasındaKI SQL veritabanları ve Entity Framework

Düzelt uygulamasında FixItContext Entity Framework DbContext sınıfından türetilen sınıfı veritabanını tanımlar ve veritabanındaki tabloları belirtir. Bağlam, görevler için bir varlık kümesi (tablo) belirtir ve kod bağlama bağlantı dizesi adını geçirir. Bu ad, Web.config dosyasında tanımlanan bir bağlantı dizesine başvurur.

public class MyFixItContext : DbContext
{
    public MyFixItContext()
        : base("name=appdb")
    {
    }

    public DbSet<MyFixIt.Persistence.FixItTask> FixItTasks { get; set; }
}

Web.config dosyasındaki bağlantı dizesi appdb olarak adlandırılır (burada yerel geliştirme veritabanına işaret edilir):

<connectionStrings>
    <add name="DefaultConnection" connectionString="Data Source=(LocalDb)\v11.0;Initial Catalog=aspnet-MyFixIt-20130604091232_4;Integrated Security=True" providerName="System.Data.SqlClient" />
    <add name="appdb" connectionString="Data Source=(localdb)\v11.0; Initial Catalog=MyFixItContext-20130604091609_11;Integrated Security=True; MultipleActiveResultSets=True" providerName="System.Data.SqlClient" />
  </connectionStrings>

Entity Framework, varlık sınıfına dahil edilen FixItTask özellikleri temel alan bir FixItTasks tablosu oluşturur. Bu basit bir POCO (Düz Eski CLR Nesnesi) sınıfıdır. Bu, Entity Framework'ten devralınmadığı veya Entity Framework'te herhangi bir bağımlılığı olmadığı anlamına gelir. Ancak Entity Framework, bunu temel alan bir tablo oluşturmayı ve onunla CRUD (create-read-update-delete) işlemlerini yürütmeyi bilir.

public class FixItTask
{
    public int FixItTaskId  { get; set; }
    public string CreatedBy { get; set; }
    [Required]
    public string Owner     { get; set; }
    [Required]
    public string Title     { get; set; }
    public string Notes     { get; set; }
    public string PhotoUrl  { get; set; }
    public bool IsDone      { get; set; } 
}

FixItTasks tablosu

Düzelt uygulaması, veri deposuyla çalışan CRUD işlemleri için kullandığı bir depo arabirimi içerir.

public interface IFixItTaskRepository
{
    Task<List<FixItTask>> FindOpenTasksByOwnerAsync(string userName);
    Task<List<FixItTask>> FindTasksByCreatorAsync(string userName); 

    Task<MyFixIt.Persistence.FixItTask> FindTaskByIdAsync(int id);

    Task CreateAsync(FixItTask taskToAdd);
    Task UpdateAsync(FixItTask taskToSave);
    Task DeleteAsync(int id);
}

Depo yöntemlerinin tümünün zaman uyumsuz olduğuna dikkat edin, bu nedenle tüm veri erişimi tamamen zaman uyumsuz bir şekilde yapılabilir.

Depo uygulaması, LINQ sorgularının yanı sıra ekleme, güncelleştirme ve silme işlemleri de dahil olmak üzere verilerle çalışmak için Entity Framework zaman uyumsuz yöntemlerini çağırır. Burada, Düzelt görevine yönelik bir kod örneği verilmiştir.

public async Task<FixItTask> FindTaskByIdAsync(int id)
{
    FixItTask fixItTask = null;
    Stopwatch timespan = Stopwatch.StartNew();

    try
    {
        fixItTask = await db.FixItTasks.FindAsync(id);
        
        timespan.Stop();
        log.TraceApi("SQL Database", "FixItTaskRepository.FindTaskByIdAsync", timespan.Elapsed, "id={0}", id);
    }
    catch(Exception e)
    {
        log.Error(e, "Error in FixItTaskRepository.FindTaskByIdAsynx(id={0})", id);
    }

    return fixItTask;
}

Burada bazı zamanlama ve hata günlüğü kodu da olduğunu fark edeceksiniz. Bunu daha sonra İzleme ve Telemetri bölümünde inceleyeceğiz.

Azure'da vm'de (IaaS) SQL Server yerine SQL Veritabanı (PaaS) seçme

SQL Server ve Azure SQL Veritabanı ile ilgili güzel bir şey, her ikisi için de temel programlama modelinin aynı olmasıdır. Aynı becerilerin çoğunu her iki ortamda da kullanabilirsiniz. Geliştirme aşamasında bir SQL Server veritabanı ve bulutta bir SQL Veritabanı örneği de kullanabilirsiniz. Bu, Düzelt uygulamasının nasıl ayarlandığıdır.

Alternatif olarak, şirket içinde çalıştırdığınız SQL Server IaaS VM'lerine yükleyerek bulutta da çalıştırabilirsiniz. Bazı eski uygulamalar için vm'de SQL Server çalıştırmak daha iyi bir çözüm olabilir. SQL Server veritabanı ayrılmış bir VM üzerinde çalıştığından, paylaşılan sunucuda çalışan bir SQL Veritabanı veritabanından daha fazla kaynağa sahiptir. Bu, SQL Server veritabanının daha büyük olabileceği ve hala iyi performans gösterebileceği anlamına gelir. Genel olarak, veritabanı boyutu ve tablo boyutu ne kadar küçük olursa, kullanım örneği SQL Veritabanı (PaaS) için o kadar iyi çalışır.

İki model arasında nasıl seçim yapabileceğinize ilişkin bazı yönergeler aşağıdadır.

Azure SQL Veritabanı (PaaS) Sanal Makinede (IaaS) SQL Server
Artılar - VM'leri oluşturmanız veya yönetmeniz, işletim sistemi veya SQL'i güncelleştirmeniz veya düzeltme eki uygulamanız gerekmez; Azure bunu sizin için yapar. - Veritabanı düzeyinde SLA ile yerleşik Yüksek Kullanılabilirlik. - Yalnızca kullandığınız kadar (lisans gerekmez) için ödeme yaptığınız için düşük toplam sahip olma maliyeti (TCO). - Çok sayıda daha küçük veritabanını işlemek için uygundur (<=her biri 500 GB). - Ölçeği genişletmeyi etkinleştirmek için dinamik olarak yeni veritabanları oluşturmak kolaydır. Artılar - Şirket içi SQL Server ile özellik uyumlu. - VM düzeyinde SLA ile 2+VM'lerde AlwaysOn aracılığıyla SQL Server Yüksek Kullanılabilirlik uygulayabilir. - SQL'in nasıl yönetileceğini tam olarak denetleyebilirsiniz. - Zaten sahip olduğunuz SQL lisanslarını yeniden kullanabilir veya bir saatlik ödeme yapabilir. - Daha az ama daha büyük (1 TB+) veritabanını işlemek için uygundur.
Dezavantajları - Şirket içi SQL Server karşılaştırıldığında bazı özellik boşlukları (CLR tümleştirmesi, TDE, sıkıştırma desteği, SQL Server Reporting Services vb.) - 500 GB veritabanı boyutu sınırı. Dezavantajları - Güncelleştirmeler/yamalar (işletim sistemi ve SQL) sizin sorumluluğunuzdadır - DB'lerin oluşturulması ve yönetilmesi sizin sorumluluğunuzdadır - Disk IOPS (saniye başına giriş/çıkış işlemleri) yaklaşık 8000 (16 veri sürücüsü aracılığıyla) ile sınırlıdır.

vm'de SQL Server kullanmak istiyorsanız, kendi SQL Server lisansınızı kullanabilir veya saatlik bir ödeme yapabilirsiniz. Örneğin portalda veya REST API aracılığıyla SQL Server bir görüntü kullanarak yeni bir VM oluşturabilirsiniz.

SQL Server ile VM oluşturma

SQL Server VM görüntülerinin listesi

SQL Server görüntü içeren bir VM oluşturduğunuzda, SQL Server lisans maliyetini VM kullanımınıza göre saatlik olarak değerlendiririz. Yalnızca birkaç ay çalıştırılacak bir projeniz varsa, saatlik ödeme yapmak daha ucuz olur. Projenizin yıllarca süreceğini düşünüyorsanız, lisansı normalde yaptığınız gibi satın almak daha ucuzdur.

Özet

Bulut bilişim, uygulamanızın gereksinimlerine en uygun şekilde veri depolama yaklaşımlarını karıştırmayı ve eşleştirmeyi pratik hale getirir. Yeni bir uygulama oluşturuyorsanız, uygulamanız büyüdükçe düzgün çalışmaya devam edecek yaklaşımları seçmek için burada listelenen sorular hakkında dikkatli düşünün. Sonraki bölümde, birden çok veri depolama yaklaşımını birleştirmek için kullanabileceğiniz bazı bölümleme stratejileri açıklanacaktır.

Kaynaklar

Daha fazla bilgi için aşağıdaki kaynaklara bakın.

Veritabanı platformu seçme:

SQL Server ile SQL Veritabanı arasında seçim:

ASP.NET Web uygulamasında Entity Framework ve SQL Veritabanı kullanma

Azure'da MongoDB kullanma:

HDInsight (Azure'da Hadoop):