Gerçekleştirilmiş Görünüm düzeni

Veriler gerekli sorgu işlemleri için ideal olarak biçimlendirilmemişse, bir veya daha fazla veri deposundaki veriler üzerinde önceden doldurulmuş görünümler oluşturun. Bu yaklaşım verimli sorgulamayı ve veri ayıklamayı destekleyebilir ve uygulama performansını geliştirebilir.

Bağlam ve sorun

Veri depolarken geliştiriciler ve veri yöneticileri genellikle verilerin nasıl okunduğu yerine nasıl depolandığını önceliklendirir. Seçilen depolama biçimi genellikle verilerin biçimini, veri boyutunu ve veri bütünlüğünü yönetme gereksinimlerini ve kullanımdaki depo türünü yansıtır. Örneğin, bir NoSQL belge deposu kullandığınızda, genellikle verileri her biri söz konusu varlığa ilişkin tüm bilgileri içeren bir dizi toplama olarak temsil edersiniz.

Ancak bu yaklaşımın sorgular üzerinde olumsuz bir etkisi olabilir. Sorguda yalnızca bazı varlıklara ait verilerin bir alt kümesine ihtiyaç duyulduğunda (tüm sipariş ayrıntılarının yer almadığı birkaç müşteri siparişinin özeti gibi) gerekli bilgilerin edinilmesi için tüm verilerin ayıklanması gerekir.

Okuma zamanında dizin eklemek veya sorguları yeniden şekillendirmek bu verimsizliği her zaman çözmez. Birçok veri deposu, yazma performansını etkilemeden keyfi okuma düzenleri için yeniden dizinlenemez. Varlıklar arası toplama, sorgu sırasında halen maliyetli olmaya devam eder. Bazı depolar tasarım gereği sınırlı sorgu özelliklerine sahiptir. Bu kısıtlamalar nedeniyle, yalnızca kaynak depodaki okuma yolunu iyileştirmek genellikle yetersizdir.

Çözüm

Verimli sorgulamayı desteklemek için yaygın bir çözüm, önceden verileri gerekli sonuç kümesine uygun bir biçimde gerçekleştiren bir görünüm oluşturmaktır. Gerçekleştirilmiş Görünüm düzeni, kaynak verilerin sorgulama için uygun biçimde olmadığı, uygun bir sorgunun oluşturulmasının zor olduğu veya verilerin ya da veri deposunun yapısı nedeniyle sorgu performansının yetersiz olduğu ortamlarda verilerin önceden doldurulmuş görünümlerinin oluşturulmasını açıklar.

Bu düzende gerçekleştirilmiş görünüm , bir veya daha fazla kaynak depodan türetilen verileri kalıcı hale getiren bir okuma modeli veya projeksiyondur. Ayrılmış bir uygulama bileşeni veya veri işlem hattı, farklı mağaza sınırları da dahil olmak üzere projeksiyonu koruyabilir. Sorgu tüketicileri projeksiyonu salt okunur olarak ele alır. Bu mimari kavram, veritabanı motorunun kendi özellik kısıtlarına göre tanımladığı, depoladığı ve yenilediği veritabanına özgü somutlaştırılmış görünüm nesnesinden daha geniştir.

Yalnızca bir sorgunun gerektirdiği verileri içeren bu gerçekleştirilmiş görünümler, uygulamaların ihtiyaç duydukları bilgileri hızla elde etmelerini sağlar. Gerçekleştirilmiş görünümler, tabloları veya veri varlıklarını birleştirmenin yanı sıra hesaplanan sütunların ya da veri öğelerinin geçerli değerlerini, veri öğeleri üzerinde gerçekleştirilen değer birleştirme veya dönüşüm yürütme işlemlerinin sonuçlarını ve sorgunun bir parçası olarak belirtilen değerleri içerebilir. Gerçekleştirilmiş görünüm tek bir sorgu için bile iyileştirilebilir.

Önemli bir nokta, gerçekleştirilmiş bir görünümün ve içerdiği verilerin tamamen atılabilir olmasıdır çünkü bunlar kaynak veri depolarından tamamen yeniden oluşturulabilir. Sorgu tüketicileri görünümü doğrudan güncelleştirmez. Bunun yerine, bunu özel bir bileşen, veri işlem hattı veya veritabanı motoru sürdürür; dolayısıyla bu, özelleşmiş bir önbellektir.

Görünümün kaynak verileri değiştiğinde, görünümün yeni bilgileri içerecek şekilde güncelleştirilmelidir. Bu güncelleştirmeyi otomatik olarak veya sistem özgün verilerde bir değişiklik algıladığında gerçekleşecek şekilde zamanlayabilirsiniz. Bazı durumlarda görünümü el ile yeniden oluşturmanız gerekebilir. Aşağıdaki şekilde, Gerçekleştirilmiş Görünüm deseninin nasıl kullanılabileceğini gösteren bir örnek gösterilmektedir.

Gerçekleştirilmiş Görünüm desenini gösteren diyagram. Kaynak veri depoları, uygulamaların kaynak depoları sorgulamak yerine doğrudan sorguladığı bir gerçekleştirilmiş görünümü dolduran gerçekleştirilmiş görünüm oluşturma sürecine girdi sağlar.

Sorunlar ve dikkat edilmesi gerekenler

Bu düzenin nasıl uygulaneceğine karar velarken aşağıdaki noktaları göz önünde bulundurun:

• Yenileme stratejisini görüntüleyin. İdeal olarak, görünüm kaynak verilerde değişiklik olduğunu belirten bir olaya yanıt olarak yeniden oluşturulur, ancak bu yaklaşım kaynak veriler hızla değişirse aşırı ek yüke yol açabilir. Alternatif olarak, görünümü yeniden oluşturmak için zamanlanmış bir görev, bir dış tetikleyici veya manuel bir eylem kullanmayı düşünebilirsiniz.

• Yenileme davranışı. Uygulamanın tam yeniden derleme gerçekleştirip gerçekleştirmediğini veya değişiklikleri artımlı olarak uygulayıp uygulamadığını belirleyin. Yenileme işlemlerinin okumaları engelleyip engellemediğine de karar vermeniz gerekir.

  Bu kararlar sorguların eski olabilecek gerçekleştirilmiş veriler döndüreceğini, gerçekleştirilmiş verileri işlenmemiş kaynak değişiklikleriyle birleştirerek geçerli sonuçları döndüreceğini veya yenileme tamamlanana kadar son tam sürümü kullanmaya devam edip etmediğini belirler.

• Sinyal güvenilirliğini yenileyin. Görünüm yeniden oluşturmayı tetikleyen etkinleştirme sinyali kaybolur veya gecikirse (örneğin, yanıtsız bir değişiklik akışı olayı veya başarısız bir zamanlanmış görev) görünüm eski sonuçları sessizce sağlar. Görünümün yaşı kabul edilebilir bayatlık süresini aştığında yenilemenin güncelliğini izleyin ve uyarı verin.

• İşlem maliyetini yenileyin. Görünümü yeniden oluşturmak, kaynak verilerin hacmine ve dönüştürmelerin karmaşıklığıyla orantılı olarak işlem kaynaklarını tüketir. Hızla değişen kaynak verilerde olay odaklı yenileme veya büyük analitik görünümlerin tam yeniden oluşturulması için yenileme işleminin işlem maliyeti önemli bir maliyet sürücüsü olabilir. Veri tazeliğini işlem harcamalarına karşı dengelemek için yenileme sıklığını ve kapsamını doğru boyutlandırın.

• Olay Kaynaklama bağımlılığı. Bazı sistemlerde, örneğin yalnızca verileri değiştiren olayların depolarını korumak için Olay Kaynağını Belirleme desenini kullandığınızda, gerçekleştirilmiş görünümler genellikle gereklidir. Etkinlik deposundan bilgi edinmenin tek yolu, tüm olayları inceleyip geçerli durumu belirlemek için görünümleri önceden hazırlamak olabilir. Event Sourcing kullanmıyorsanız, maddeselleştirilmiş bir görünümün yararlı olup olmayacağını değerlendirin. Somutlaştırılmış görünümler genellikle bir veya birkaç sorgu için özel olarak tasarlanır. Çok sayıda sorgu kullanılıyorsa gerçekleştirilmiş görünümler kabul edilemez nitelikte depolama kapasitesi gereksinimlerine ve depolama maliyetlerine neden olabilir.

• Veri tutarlılığı. Görünümü oluştururken ve bu işlem bir zamanlamaya göre gerçekleşirse görünümü güncelleştirirken veri tutarlılığı üzerindeki etkiyi göz önünde bulundurun. Kaynak veriler görünüm oluşturulurken aynı anda değişirse, görünümdeki verilerin kopyası özgün verilerle tam olarak tutarlı değildir. Maksimum eskime penceresi yenileme aralığının veya olay işleme gecikmesinin doğrudan bir sonucudur; bu nedenle olay temelli, zamanlanmış veya el ile yenileme arasında seçim yapmadan önce kabul edilebilir eskime durumunu tanımlayın.

• Depolama konumunu görüntüleyin. Görünümün özgün verilerle aynı depoda veya bölümde yer alması gerekmez. Birkaç farklı bölümden alt kümeleri birleştirebilirsiniz.

• Kayıp durumunda yeniden oluşturun. Görünüm kaybolursa yeniden oluşturulabilir. Bu nedenle, görünüm geçiciyse ve yalnızca verilerin geçerli durumunu yansıtarak sorgu performansını geliştirmek veya ölçeklenebilirliği geliştirmek için kullanılıyorsa, bunu bir önbellekte veya daha az güvenilir bir konumda depolayabilirsiniz.

  Ancak yenileme işleminin kendisi yarı yarıya başarısız olursa (örneğin, zamanlanmış bir yeniden oluşturma görevi kilitleniyorsa) iş yükünün önceki tam görünüme mi, kısmen güncelleştirilmiş bir görünüme mi yoksa yeniden oluşturma başarılı olana kadar hiç görünüme mi hizmet vermeyeceğini belirler.

  En güvenli yaklaşım genellikle atomik yayımlama veya sürümlü değiştirme yöntemidir; bu yöntemde, yeni görünümü oluşturup doğrularken iş yükünüz son eksiksiz görünümü sunmaya ve kullanmaya devam eder. Doğrulama tamamlandıktan sonra yeni görünüme geçin.

• Hesaplanmış sütunlar. Gerçekleştirilmiş bir görünüm tanımlarken, mevcut veri öğelerinin hesaplamasına veya dönüşümüne, sorguya geçirilen değerlere veya uygun olduğunda bu değerlerin birleşimlerine göre veri öğeleri veya sütunlar ekleyerek değerini en üst düzeye çıkarın.

• İndekslemeyi görüntüle Performansı daha da artırmak amacıyla, depolama mekanizmasının desteklediği ölçüde malzemeleştirilmiş görünümü dizinlemeyi değerlendirin. Birçok ilişkisel veritabanı, görünümler için dizin oluşturmayı destekler. Ancak, görünümdeki dizin bakımı her yenileme döngüsü sırasında yazma yolu ek yükü ekler, bu nedenle okuma performansı kazançlarını ek yenileme süresi ve işlem maliyetiyle dengeleyin.

• Görünümler için erişim denetimi. Güvenlik veya gizlilik gibi belirli tüketicilerin hangi veri alt kümelerinin görünür olduğunu kısıtlamak için gerçekleştirilmiş bir görünüm kullanıldığında, görünüm deposunun kaynak verilerle aynı veya daha katı erişim denetimlerini zorunlu kılması gerekir. Yenileme işlem hattınız, istenmeyen sütunları veya satırları dışlamalıdır; çünkü yanlışlıkla amaçlanan kapsamın ötesindeki verileri içeren bir görünüm, korumalı verileri açığa çıkarabilir.

• Görünümlerde veri yaşam döngüsü. Kaynak verilerin saklama ve silme gereksinimlerini her bir somutlaştırılmış görünüme uygulayın. Kaynak silme ve redaksiyon işlemlerini gerekli süre içinde yansıtın ve her görünümü uyumluluk izlemesine dahil edin. Daha fazla bilgi için bkz. Microsoft Purview ile veri idaresi ve güvenlik temelleri.

• Yaşam döngüsü yönetimini görüntüleyin. Görünüm tanımlarını, özellikle görünümler bildirimli olarak tanımlandığında kaynak denetimi ve CI/CD işlem hatları aracılığıyla yönetilen dağıtılabilir yapıtlar olarak değerlendirin. Yaşam döngüsü yönetimi olmadan görünüm tanımları ortamlar arasında kayarak geliştirme, hazırlama ve üretim genelinde tutarsız sorgu davranışına neden olabilir.

Bu desen ne zaman kullanılır?

Bu düzeni aşağıdaki durumlarda kullanın:

• Doğrudan sorgulanması zor olan veya sorguların normalleştirilmiş, yarı yapılandırılmış veya yapılandırılmamış bir şekilde depolanan verileri ayıklamak için çok karmaşık olması gereken veriler üzerinde görünümler oluşturmanız gerekir.
• Sorgu performansını geliştiren yeniden derlenebilir veya geçici önbelleğe alınmış projeksiyonlar veya kullanıcı arabirimi, rapor veya görüntü için veri aktarımı nesneleri oluşturmak için kullanılan şekil verilerini oluşturmak istiyorsunuz.
• Veri deposuna bağlantının her zaman mevcut olmadığı durumlarda, ara sıra bağlı olunan veya bağlantısız çalışma senaryolarını desteklemeniz gerekir. Bu durumda görünümü yerel olarak önbelleğe alabilirsiniz.
• Sorguları basitleştirmek ve verileri deneme için kaynak veri biçimi hakkında bilgi gerektirmeyen bir şekilde kullanıma açmak istiyorsunuz. Örneğin, farklı tabloları bir veya birden fazla veritabanında ya da NoSQL depolarındaki bir veya birden fazla etki alanında birleştirme ve sonra verileri nihai kullanıma uyacak şekilde biçimlendirme.
• Güvenlik veya gizlilik nedenleriyle genel olarak erişilebilir olmaması, değişikliğe açık veya kullanıcılara tamamen açık olmaması gereken kaynak verilerin belirli alt kümelerine erişim sağlamak istiyorsunuz.
• Her birinin kendine özgü yeteneklerinden yararlanmak için farklı veri depoları arasında köprü kurmak istiyorsunuz. Örneğin, başvuru veri deposu olarak yazma açısından verimli bir bulut deposu ve gerçekleştirilmiş görünümleri tutmak için iyi sorgu ve okuma performansı sunan ilişkisel bir veritabanı kullanabilirsiniz.
• Mikro hizmetleri kullandığınızda, veri depolama alanları da dahil olmak üzere bunları gevşek bir şekilde bağlı tutun. Gerçekleştirilmiş görünümler, hizmetlerinizdeki verileri birleştirmenize yardımcı olabilir. Maddileştirilmiş görünümler mikro hizmet mimariniz için veya belirli bir senaryoda uygun değilse, etki alanı odaklı tasarımla (DDD) uyumlu, iyi tanımlanmış sınırlar belirlemeyi ve verilerini gerektiğinde bir araya getirmeyi değerlendirin.

Bu düzen aşağıdaki durumlarda uygun olmayabilir:

• Veri kaynağının basit ve kolay bir şekilde sorgulanabilmesi.
• Veri kaynağının çok hızlı bir şekilde değişmesi ya da bir görünüm kullanılmadan erişilebilmesi. Bu gibi durumlarda, görünüm oluşturma işleminin ek yükünden kaçının.
• Tutarlılık yüksek öncelik taşır. Görünümler özgün verilerle her zaman tam olarak tutarlı olmayabilir.

İş yükü tasarımı

Bir mimar, Azure Well-Architected Framework sütunları kapsamında yer alan hedefleri ve ilkeleri ele almak için Materialized View desenini iş yükü tasarımında nasıl kullanabileceğini değerlendirmelidir. Örneğin:

Temel	Bu desen sütun hedeflerini nasıl destekler?
Performans Verimliliği , ölçeklendirme, veri ve kod iyileştirmeleri aracılığıyla iş yükünüzün talepleri verimli bir şekilde karşılamasını sağlar.	Gerçekleştirilmiş görünümler, veritabanı altyapısının veya istemcinin her istek için yeniden derlemesini gerektirmeden karmaşık hesaplamaların veya sorguların sonuçlarını depolar. Bu tasarım, genel kaynak tüketimini azaltır. - PE:08 Veri performansı

Bu model bir sütun içinde dengeleri ortaya çıkartıyorsa, bunları diğer sütunların hedeflerine karşı değerlendirin.

Example

Azure Tablo Depolaması'de Order, OrderItem ve Customer varlıklarını depolayan bir satış uygulaması düşünün. Siparişler müşteri kimliğine, sipariş kimliğine göre sipariş öğelerine ve bölgeye göre müşterilere göre bölümlenir. Bu anahtarlar uygulamanın işletimsel erişim desenlerini destekler, ancak ürüne göre gruplandırılmış bir satış raporunun bölümler arasında verileri okuması ve uygulama kodunda birleştirmesi gerekir.

Aşağıdaki şekil, Elektronik kategorisindeki her ürün için toplam satış değerini ve satın alan farklı müşteri sayısını depolayan bir somutlaştırılmış görünümü göstermektedir. Kaynak satırlar ve özet değerleri, gösterilen toplamlar için tam bir giriş veri kümesi değil, açıklayıcıdır.

Sol tarafta üç tablo görünür: Üstte sıra, ortada OrderItem ve altta Müşteri. Bölüm anahtarları sırasıyla müşteri kimliği, sipariş kimliği ve bölgedir. Büyük bir ok, kaynak tablolardan sağ taraftaki Gerçekleştirilmiş Görünüm tablosuna yönlendirir. Görünüm, bölüm anahtarı olarak ürün kategorisini ve satır anahtarı olarak ürün kimliğini kullanır. Her satırda bir ürün adı, toplam satış değeri ve müşteri sayısı bulunur. Resimli görünümün Elektronik bölümünde iki ürün satırı vardır.

Arka plan işlemi gerekli kaynak varlıkları okur, sipariş öğelerini siparişleri ve müşterileri ile ilişkilendirir ve satışları ürüne göre toplar. Müşterinin birden çok siparişi veya sipariş satırı olsa bile ürün başına her müşteriyi bir kez sayar. İşlem, sonuçları ürün kategorisi RowKey ve ürün kimliği PartitionKey olan ayrı bir özet tablosuna yazar. Bu özet tablo, veritabanının yerel bir somutlaştırılmış görünümü değil, uygulamanın yönettiği bir projeksiyondur.

Bir gösterge paneli, daha sonra her istek için bölümler arası okumaları ve toplulaştırmayı yinelemek yerine Elektronik bölümünü sorgulayabilir. Bir ürün için yapılan arama her iki anahtarı da sağlar. Bu anahtarların sorgu performansı üzerindeki etkileri için bkz. Sorgulama için tasarlama.

Raporun kabul edilebilir eskime penceresine uyan bir zamanlamada özeti yenileyin. Yeni sürümü yayımlamadan önce derleyin ve doğrulayın; böylece okuyucular yeniden derleme sırasında önceki tam sürümü kullanmaya devam eder. Yenileme işlemi hâlâ bölümler arası okuma ve toplulaştırma maliyetlerine neden olur, ancak tekrarlanan rapor sorguları sonucu yeniden kullanır. Kaynak değişiklikleri, bunları içeren sonraki bir yenileme gerçekleşene kadar görünmez.

Sonraki Adımlar

• Dizinli görünümler oluşturma , SQL veritabanlarının bir görünümde dizin oluşturarak hesaplanan görünüm sonuçlarını nasıl kalıcı hale döndürebileceğini açıklar.
• NoSQL için Azure Cosmos DB değişiklik akışı tasarım desenleri, değişiklik akışı tüketicilerinin gerçekleştirilmiş görünümleri nasıl koruyabileceğini açıklar.
• Somutlaştırılmış görünümlere genel bakış, Azure Veri Gezgini’daki somutlaştırılmış görünümleri açıklar.
• Azure Yönetilen Redis, önceden derlenmiş sorgu sonuçlarını kalıcı veri depolarının önünde okuma için iyileştirilmiş bir katman olarak önbelleğe alabilir.
• Azure Tablo Depolaması, uygulama mantığı veya arka plan işlemi tarafından oluşturulan önceden derlenmiş görünüm verilerini depolayabilir.

İlgili kaynaklar

Bu deseni uyguladığınızda aşağıdaki desenler de ilgili olabilir:

• Komut ve Sorgu Sorumluluğu Ayrımı (CQRS) düzeni. Temel alınan veri değerleri değiştiğinde gerçekleşen olaylara tepki vererek bir materyalize görünümdeki bilgileri güncellemek için kullanın.
• Olay Kaynağını Belirleme düzeni. Bilgileri somutlaştırılmış bir görünümde tutmak için CQRS deseniyle birlikte kullanın. Gerçekleştirilmiş bir görünümün veri değerleri değişikliğe dayalı olduğunda, sistem bu değişiklikleri açıklayan olaylar oluşturabilir ve bunları bir olay deposuna kaydedebilir.
• Dizin Tablosu kalıbı. Bir gerçekleştirilmiş görünümdeki veriler genellikle bir birincil anahtara göre düzenlenir, ancak sorguların diğer alanlardaki verileri inceleyerek bu görünümden bilgi alması gerekebilir. Yerel ikincil dizinleri desteklemeyen veri depoları için veri kümeleri üzerinde ikincil dizinler oluşturmak için bu düzeni kullanın.