NoSQL için Azure Cosmos DB'de veri modelleme

Azure Cosmos DB gibi şemasız veritabanları yapılandırılmamış ve yarı yapılandırılmış verileri depolamayı ve sorgulamayı kolaylaştırırken performansı, ölçeklenebilirliği ve maliyeti iyileştirmek için veri modelinizi düşünün.

Veriler nasıl depolanır? Uygulamanız verileri nasıl alır ve sorgular? Uygulamanız yoğun okuma veya yazma yoğun mu?

Bu makaleyi okuduktan sonra aşağıdaki soruları yanıtlayabilirsiniz:

• Veri modelleme nedir ve neden umursamalıyım?
• Azure Cosmos DB'deki verileri modellemenin ilişkisel veritabanından farkı nedir?
• İlişkisel olmayan bir veritabanında veri ilişkilerini nasıl ifade edebilirsiniz?
• Verileri ne zaman eklerim ve verilere ne zaman bağlanırım?

JSON'daki sayılar

Azure Cosmos DB belgeleri JSON'a kaydeder, bu nedenle sayıları JSON'da depolamadan önce dizelere dönüştürmenin gerekip gerekmediğini belirlemek önemlidir. String tarafından tanımlanan çift duyarlıklı sayıların sınırlarını aşabileceklerse, tüm sayıları a'ya dönüştürün. JSON belirtimi, birlikte çalışabilirlik sorunları nedeniyle bu sınırın dışındaki sayıları kullanmanın neden kötü bir uygulama olduğunu açıklar. Bu sorunlar özellikle bölüm anahtarı sütunu için geçerlidir çünkü sabittir ve daha sonra veri geçişinin değiştirilmesini gerektirir.

Veri ekleme

Azure Cosmos DB'de verileri modellerken varlıklarınızı JSON belgeleri olarak temsil edilen bağımsız öğeler olarak değerlendirin.

Karşılaştırma için öncelikle ilişkisel veritabanındaki verileri nasıl modelleyebileceğimizi görelim. Aşağıdaki örnekte, bir kişinin ilişkisel veritabanında nasıl depolanabileceği gösterilmektedir.

strateji, ilişkisel veritabanlarıyla çalışırken tüm verilerinizi normalleştirmektir. Verilerinizi normalleştirmek genellikle kişi gibi bir varlığı alıp ayrı bileşenlere ayırmayı içerir. Örnekte, bir kişinin birden çok kişi ayrıntı kaydı ve birden çok adres kaydı olabilir. Tür gibi ortak alanları ayıklayarak kişi ayrıntılarını daha ayrıntılı olarak inceleyebilirsiniz. Aynı yaklaşım adresler için de geçerlidir. Her kayıt Ev veya İş olarak sınıflandırılabilir.

Verileri normalleştirirken yol gösteren şirket, her kayıtta yedekli verilerin depolanmasını önlemek ve bunun yerine verilere başvurmaktır. Bu örnekte, bir kişiyi tüm kişi ayrıntıları ve adresleriyle okumak için, çalışma zamanında verilerinizi etkili bir şekilde oluşturmak (veya normalden çıkarmak) için JOINS kullanmanız gerekir.

SELECT p.FirstName, p.LastName, a.City, cd.Detail
FROM Person p
JOIN ContactDetail cd ON cd.PersonId = p.Id
JOIN ContactDetailType cdt ON cdt.Id = cd.TypeId
JOIN Address a ON a.PersonId = p.Id

Tek bir kişinin kişi ayrıntılarını ve adreslerini güncelleştirmek için birçok ayrı tabloda yazma işlemleri yapılması gerekir.

Şimdi Azure Cosmos DB'de bağımsız bir varlıkla aynı verileri nasıl modellediğimize göz atalım.

{
    "id": "1",
    "firstName": "Thomas",
    "lastName": "Andersen",
    "addresses": [
        {
            "line1": "100 Some Street",
            "line2": "Unit 1",
            "city": "Seattle",
            "state": "WA",
            "zip": 98012
        }
    ],
    "contactDetails": [
        {"email": "thomas@andersen.com"},
        {"phone": "+1 555 555-5555", "extension": 5555}
    ]
}

Bu yaklaşımı kullanarak, kişi ayrıntıları ve adresleri gibi bu kişiyle ilgili tüm bilgileri tek bir JSON belgesine ekleyerek kişi kaydını normal dışıleştirdik. Ayrıca, sabit bir şemayla sınırlı kalmadığımız için, tamamen farklı şekillerin iletişim ayrıntılarına sahip olma gibi işlemler yapma esnekliğine sahibiz.

Veritabanından tam bir kişi kaydı almak artık tek bir öğe için tek bir kapsayıcıya karşı tek bir okuma işlemidir . Kişi kaydının kişi ayrıntılarını ve adreslerini güncelleştirmek de tek bir öğeye karşı tek bir yazma işlemidir .

Verileri normalden çıkarma, yaygın işlemleri tamamlamak için uygulamanızın ihtiyaç duyduğu sorgu ve güncelleştirme sayısını azaltabilir.

Ekleme zamanları

Genel olarak, aşağıdaki durumlarda eklenmiş veri modellerini kullanın:

• Varlıklar arasında kapsanan ilişkiler vardır.
• Varlıklar arasında bire birkaç ilişki vardır.
• Veriler seyrek değişir.
• Veriler bağlı olmadan büyümez.
• Veriler sık sık birlikte sorgulanır.

Not

Normal olmayan veri modelleri genellikle daha iyi okuma performansı sağlar.

Gömmekten kaçınılması gereken durumlar

Azure Cosmos DB'de temel kural, her şeyi normalden çıkarmak ve tüm verileri tek bir öğeye eklemek olsa da, bu yaklaşım kaçınılması gereken durumlara yol açabilir.

Bu JSON parçacığını alın.

{
    "id": "1",
    "name": "What's new in the coolest Cloud",
    "summary": "A blog post by someone real famous",
    "comments": [
        {"id": 1, "author": "anon", "comment": "something useful, I'm sure"},
        {"id": 2, "author": "bob", "comment": "wisdom from the interwebs"},
        …
        {"id": 100001, "author": "jane", "comment": "and on we go ..."},
        …
        {"id": 1000000001, "author": "angry", "comment": "blah angry blah angry"},
        …
        {"id": ∞ + 1, "author": "bored", "comment": "oh man, will this ever end?"},
    ]
}

Bu örnek, genel bir blogu veya içerik yönetim sistemini (CMS) modellediğimizde ekli açıklamaları olan bir gönderi varlığının nasıl görüneceği olabilir. Bu örnekteki sorun, açıklamalar dizisinin ilişkisiz olmasıdır, yani tek bir gönderinin sahip olabileceği açıklama sayısı için (pratik) bir sınır yoktur. Öğenin boyutu sonsuz büyük olabileceğinden bu tasarım sorunlara neden olabilir, bu nedenle bundan kaçının.

Öğe boyutu arttıkça verileri büyük ölçekte iletmek, okumak ve güncelleştirmek daha zor hale gelir.

Bu durumda, aşağıdaki veri modelini göz önünde bulundurmak daha iyi olacaktır.

Post item:
{
    "id": "1",
    "name": "What's new in the coolest Cloud",
    "summary": "A blog post by someone real famous",
    "recentComments": [
        {"id": 1, "author": "anon", "comment": "something useful, I'm sure"},
        {"id": 2, "author": "bob", "comment": "wisdom from the interwebs"},
        {"id": 3, "author": "jane", "comment": "....."}
    ]
}

Comment items:
[
    {"id": 4, "postId": "1", "author": "anon", "comment": "more goodness"},
    {"id": 5, "postId": "1", "author": "bob", "comment": "tails from the field"},
    ...
    {"id": 99, "postId": "1", "author": "angry", "comment": "blah angry blah angry"},
    {"id": 100, "postId": "2", "author": "anon", "comment": "yet more"},
    ...
    {"id": 199, "postId": "2", "author": "bored", "comment": "will this ever end?"}   
]

Bu model, her açıklama için post tanımlayıcısını içeren bir özelliğe sahip bir öğeye sahiptir. Bu model, gönderilerin herhangi bir sayıda yorum içermesine ve verimli bir şekilde büyümesine olanak tanır. En son açıklamalardan daha fazlasını görmek isteyen kullanıcılar bu kapsayıcıyı postId değerini geçirerek sorgular. Bu, açıklamalar kapsayıcısının bölüm anahtarı olmalıdır.

Veri eklemenin iyi bir fikir olmadığı bir diğer durum da eklenen verilerin öğeler arasında sık sık kullanılması ve sık sık değişmesidir.

Bu JSON parçacığını alın.

{
    "id": "1",
    "firstName": "Thomas",
    "lastName": "Andersen",
    "holdings": [
        {
            "numberHeld": 100,
            "stock": { "symbol": "zbzb", "open": 1, "high": 2, "low": 0.5 }
        },
        {
            "numberHeld": 50,
            "stock": { "symbol": "xcxc", "open": 89, "high": 93.24, "low": 88.87 }
        }
    ]
}

Bu örnek, bir kişinin hisse senedi portföyünü temsil edebilir. Hisse senedi bilgilerini her portföy belgesine eklemeyi seçtik. İlgili verilerin sık sık eklendiği ve sık değişen verilerin değiştirildiği bir ortamda, her portföyü sürekli güncelleştirdiğiniz anlamına gelir. Bir hisse senedi alım satım uygulaması örneğini kullanarak, hisse senedi alım satımında her portföy öğesini güncelleştirmiş olursunuz.

Hisse senetleri zbzb tek bir günde yüzlerce kez takas edilebilir ve binlerce kullanıcı portföylerinde yer alabilir zbzb . Örnek gibi bir veri modeliyle sistemin her gün binlerce portföy belgesini birçok kez güncelleştirmesi gerekir ve bu da iyi ölçeklendirilemez.

Referans verileri

Verileri ekleme çoğu durumda düzgün çalışır, ancak verilerinizi normal dışı durumdan çıkarmanın değerinden daha fazla soruna neden olduğu senaryolar vardır. Peki, ne yapabilirsin?

Yalnızca ilişkisel veritabanlarında değil, belge veritabanlarındaki varlıklar arasında ilişkiler oluşturabilirsiniz. Belge veritabanında, bir öğe diğer belgelerdeki verilere bağlanan bilgileri içerebilir. Azure Cosmos DB, ilişkisel veritabanlarındakiler gibi karmaşık ilişkiler için tasarlanmamıştır, ancak öğeler arasındaki basit bağlantılar mümkündür ve yararlı olabilir.

JSON'da, daha önceki bir hisse senedi portföyü örneğini kullanırız, ancak bu kez portföye eklemek yerine portföydeki hisse senedi öğesine başvururuz. Bu şekilde, hisse senedi maddesi gün boyunca sık sık değiştiğinde güncelleştirilmesi gereken tek öğe tek hisse senedi belgesidir.

Person document:
{
    "id": "1",
    "firstName": "Thomas",
    "lastName": "Andersen",
    "holdings": [
        { "numberHeld":  100, "stockId": 1},
        { "numberHeld":  50, "stockId": 2}
    ]
}

Stock documents:
{
    "id": "1",
    "symbol": "zbzb",
    "open": 1,
    "high": 2,
    "low": 0.5,
    "vol": 11970000,
    "mkt-cap": 42000000,
    "pe": 5.89
},
{
    "id": "2",
    "symbol": "xcxc",
    "open": 89,
    "high": 93.24,
    "low": 88.87,
    "vol": 2970200,
    "mkt-cap": 1005000,
    "pe": 75.82
}

Bu yaklaşımın bir dezavantajı, uygulamanızın bir kişinin portföyündeki her hisse senedi hakkında bilgi almak için birkaç veritabanı isteğinde bulunması gerektiğidir. Bu tasarım, güncelleştirmeler sık gerçekleştiğinden veri yazmayı hızlandırır. Ancak, bu sistem için daha az önemli olan verileri okumayı veya sorgulamayı daha yavaş hale getirir.

Not

Normalleştirilmiş veri modelleri , sunucuya daha fazla gidiş dönüş gerektirebilir.

Yabancı anahtarlar ne olacak?

Yabancı anahtar gibi bir kısıtlama kavramı olmadığından, veritabanı belgelerdeki belgeler arası ilişkileri doğrulamaz; bu bağlantılar etkili bir şekilde "zayıftır". Bir öğenin başvurduğunu verilerin gerçekten var olduğundan emin olmak istiyorsanız, bu adımı uygulamanızda veya Azure Cosmos DB'de sunucu tarafı tetikleyicileri veya saklı yordamları kullanarak yapmanız gerekir.

Ne zaman referans verilecek?

Genel olarak, aşağıdaki durumlarda normalleştirilmiş veri modellerini kullanın:

• Bire çok ilişkileri temsil eder.
• Çoka çok ilişkilerini temsil eder.
• İlgili veriler sık sık değişir.
• Başvuruda bulunulan veriler sınırsız olabilir.

Not

Normalleştirme genellikle daha iyi yazma performansı sağlar.

İlişkiyi nereye koyayım?

İlişkinin büyümesi, başvurunun depolandığı öğeyi belirlemeye yardımcı olur.

Yayımcıları ve kitapları modelleyen JSON'ı gözlemlersek.

Publisher document:
{
    "id": "mspress",
    "name": "Microsoft Press",
    "books": [ 1, 2, 3, ..., 100, ..., 1000]
}

Book documents:
{"id": "1", "name": "Azure Cosmos DB 101" }
{"id": "2", "name": "Azure Cosmos DB for RDBMS Users" }
{"id": "3", "name": "Taking over the world one JSON doc at a time" }
...
{"id": "100", "name": "Learn about Azure Cosmos DB" }
...
{"id": "1000", "name": "Deep Dive into Azure Cosmos DB" }

Yayımcı başına kitap sayısı küçükse ve büyüme sınırlıysa, kitap başvurularını yayımcı öğesi içinde depolamak yararlı olabilir. Ancak, yayımcı başına kitap sayısı ilişkisizse, bu veri modeli örnek yayımcı belgesinde olduğu gibi değişken ve artan dizilere yol açabilir.

Yapı değiştirilse de aynı verileri temsil eden ancak büyük değiştirilebilir koleksiyonlardan kaçınan bir model elde edilir.

Publisher document:
{
    "id": "mspress",
    "name": "Microsoft Press"
}

Book documents:
{"id": "1","name": "Azure Cosmos DB 101", "pub-id": "mspress"}
{"id": "2","name": "Azure Cosmos DB for RDBMS Users", "pub-id": "mspress"}
{"id": "3","name": "Taking over the world one JSON doc at a time", "pub-id": "mspress"}
...
{"id": "100","name": "Learn about Azure Cosmos DB", "pub-id": "mspress"}
...
{"id": "1000","name": "Deep Dive into Azure Cosmos DB", "pub-id": "mspress"}

Bu örnekte, yayımcı belgesi artık ilişkisiz bir koleksiyon içermiyor. Bunun yerine, her kitap belgesi yayımcısına bir başvuru içerir.

Çoktan çoka ilişkileri nasıl modelleyebilirim?

İlişkisel veritabanında, çoka çok ilişkiler genellikle birleştirme tablolarıyla modellenir. Bu ilişkiler yalnızca diğer tablolardaki kayıtları birleştirir.

Belgeleri kullanarak aynı şeyi çoğaltmak ve aşağıdakine benzer bir veri modeli oluşturmak isteyebilirsiniz.

Author documents:
{"id": "a1", "name": "Thomas Andersen" }
{"id": "a2", "name": "William Wakefield" }

Book documents:
{"id": "b1", "name": "Azure Cosmos DB 101" }
{"id": "b2", "name": "Azure Cosmos DB for RDBMS Users" }
{"id": "b3", "name": "Taking over the world one JSON doc at a time" }
{"id": "b4", "name": "Learn about Azure Cosmos DB" }
{"id": "b5", "name": "Deep Dive into Azure Cosmos DB" }

Joining documents:
{"authorId": "a1", "bookId": "b1" }
{"authorId": "a2", "bookId": "b1" }
{"authorId": "a1", "bookId": "b2" }
{"authorId": "a1", "bookId": "b3" }

Bu yaklaşım işe yarar, ancak bir yazarı kitaplarıyla veya yazarıyla birlikte bir kitap yüklemek için her zaman en az iki ek veritabanı sorgusu gerekir. Birleştirilen öğeye bir sorgu ve sonra birleştirilen gerçek öğeyi getirmek için başka bir sorgu.

Bu birleştirme yalnızca iki veri parçasını birbirine yapıştırıyorsa neden tamamen bırakılmıyor? Aşağıdaki örneği inceleyin.

Author documents:
{"id": "a1", "name": "Thomas Andersen", "books": ["b1", "b2", "b3"]}
{"id": "a2", "name": "William Wakefield", "books": ["b1", "b4"]}

Book documents:
{"id": "b1", "name": "Azure Cosmos DB 101", "authors": ["a1", "a2"]}
{"id": "b2", "name": "Azure Cosmos DB for RDBMS Users", "authors": ["a1"]}
{"id": "b3", "name": "Learn about Azure Cosmos DB", "authors": ["a1"]}
{"id": "b4", "name": "Deep Dive into Azure Cosmos DB", "authors": ["a2"]}

Bu modelle, bir yazarın kendi belgesine bakarak hangi kitapları yazdığını kolayca görebilirsiniz. Kitap belgesini denetleyerek hangi yazarların kitap yazdığını da görebilirsiniz. Ayrı bir birleştirme tablosu kullanmanız veya ek sorgular yapmanız gerekmez. Bu model, uygulamanızın ihtiyaç duyduğu verileri alabilmesini daha hızlı ve basit hale getirir.

Karma veri modelleri

Verileri ekleme (veya normalleştirme) ve başvurma (veya normalleştirme) hakkında bilgi ediniyoruz. Her yaklaşım avantajlar sunar ve dengeleri içerir.

Her zaman ya da olmak zorunda değildir. Her şeyi biraz karıştırmaktan çekinmeyin.

Uygulamanızın belirli kullanım desenlerine ve iş yüklerine bağlı olarak, eklenmiş ve başvuruldu verileri karıştırmak mantıklı olabilir. Bu yaklaşım uygulama mantığını basitleştirebilir, sunucu gidiş dönüşlerini azaltabilir ve iyi performans sağlayabilir.

Aşağıdaki JSON'yi göz önünde bulundurun.

Author documents:
{
    "id": "a1",
    "firstName": "Thomas",
    "lastName": "Andersen",
    "countOfBooks": 3,
    "books": ["b1", "b2", "b3"],
    "images": [
        {"thumbnail": "https://....png"}
        {"profile": "https://....png"}
        {"large": "https://....png"}
    ]
},
{
    "id": "a2",
    "firstName": "William",
    "lastName": "Wakefield",
    "countOfBooks": 1,
    "books": ["b1"],
    "images": [
        {"thumbnail": "https://....png"}
    ]
}

Book documents:
{
    "id": "b1",
    "name": "Azure Cosmos DB 101",
    "authors": [
        {"id": "a1", "name": "Thomas Andersen", "thumbnailUrl": "https://....png"},
        {"id": "a2", "name": "William Wakefield", "thumbnailUrl": "https://....png"}
    ]
},
{
    "id": "b2",
    "name": "Azure Cosmos DB for RDBMS Users",
    "authors": [
        {"id": "a1", "name": "Thomas Andersen", "thumbnailUrl": "https://....png"},
    ]
}

Burada (çoğunlukla) diğer varlıklardaki verilerin en üst düzey belgeye eklendiği ancak diğer verilere başvurulduğu eklenmiş modeli takip ettik.

Kitap belgesine bakarsanız, yazar dizisine baktığımızda birkaç ilginç alan görebiliriz. Bir id alanı, yazar belgesine başvurmak için kullandığımız ve normalleştirilmiş bir modelde standart uygulama olan bir alandır, ancak name ve thumbnailUrl alanlarımız da vardır. Yalnızca öğesini id kullanabilir ve uygulamanın "bağlantı" kullanarak ilgili yazar öğesinden ihtiyaç duyduğu ek bilgileri almasına izin verebiliriz. Ancak, uygulama yazarın adını ve her kitapla birlikte küçük resim resmini görüntülediğinden, yazardan bazı verilerin normal dışılaştırılması, listedeki kitap başına sunucu gidiş dönüş sayısını azaltır.

Yazarın adı değişirse veya fotoğrafını güncelleştirirse, yayımladığı her kitabı güncelleştirmeniz gerekir. Ancak bu uygulama için yazarların adlarını nadiren değiştirdikleri varsayıldığında, bu uzlaşma kabul edilebilir bir tasarım kararıdır.

Örnekte, okuma işlemi sırasında pahalı işlemeden tasarruf etmek için önceden hesaplanmış toplama değerleri vardır. Örnekte, yazar öğesine eklenen verilerden bazıları çalışma zamanında hesaplanan verilerdir. Her yeni kitap yayımlandığında, bir kitap öğesi oluşturulur ve countOfBooks alanı, belirli bir yazar için var olan kitap belgelerinin sayısına göre hesaplanan bir değere ayarlanır. Bu iyileştirme, okumaları optimize etmek için yazma işlemlerinde hesaplamalar yapabileceğimiz, okuma yoğun sistemlerde iyi olacaktır.

Azure Cosmos DB çok belgeli işlemleri desteklediğinden , önceden hesaplanmış alanlara sahip bir modele sahip olma özelliği mümkündür. Birçok NoSQL deposu belgeler arasında işlem gerçekleştiremez ve bu nedenle bu sınırlama nedeniyle "her şeyi her zaman ekle" gibi tasarım kararlarını savunur. Azure Cosmos DB ile sunucu tarafı tetikleyicileri veya bir ACID işlemi içinde kitap ekleyip yazarları güncelleştiren saklı yordamlar kullanabilirsiniz. Artık verilerinizin tutarlı kaldığından emin olmak için her şeyi tek bir öğeye eklemek zorunda değilsiniz.

Farklı öğe türleri arasında ayrım

Bazı senaryolarda, aynı koleksiyonda farklı öğe türlerini karıştırmak isteyebilirsiniz; bu tasarım seçimi genellikle birden çok ilgili belgenin aynı bölümde yer almak istediğinizde geçerli olur. Örneğin, hem kitapları hem de kitap incelemelerini aynı koleksiyona koyabilir ve ile bookIdbölümleyebilirsiniz. Böyle bir durumda, genellikle belgelerinize, bunları ayırt etmek için türlerini tanımlayan bir alan eklemek istersiniz.

Book documents:
{
    "id": "b1",
    "name": "Azure Cosmos DB 101",
    "bookId": "b1",
    "type": "book"
}

Review documents:
{
    "id": "r1",
    "content": "This book is awesome",
    "bookId": "b1",
    "type": "review"
}
{
    "id": "r2",
    "content": "Best book ever!",
    "bookId": "b1",
    "type": "review"
}

Azure Synapse Link ve Azure Cosmos DB analiz deposu için veri modelleme

Azure Cosmos DB için Azure Synapse Link, Azure Cosmos DB'deki operasyonel veriler üzerinde neredeyse gerçek zamanlı analiz çalıştırmanızı sağlayan bulutta yerel hibrit işlem ve analitik işleme (HTAP) özelliğidir. Azure Synapse Link, Azure Cosmos DB ile Azure Synapse Analytics arasında sorunsuz bir tümleştirme oluşturur.

Bu tümleştirme, işlem iş yüklerinizi etkilemeden büyük ölçekli analizlere olanak tanıyan işlem verilerinizin sütunlu bir gösterimi olan Azure Cosmos DB analiz deposu aracılığıyla gerçekleşir. Analiz deposu, büyük veri kümelerinde hızlı ve uygun fiyatlı sorgular çalıştırmanızı sağlar. Verileri kopyalamanız veya ana veritabanınızı yavaşlatma konusunda endişelenmeniz gerekmez. Bir kapsayıcı için analiz deposunu açtığınızda, verilerinizde yaptığınız her değişiklik hemen hemen analiz deposuna kopyalanır. Değişiklik Akışı'nı ayarlamanız veya ayıklama, dönüştürme ve yükleme (ETL) işleri çalıştırmanız gerekmez. Sistem her iki depoyu da sizin için eşitlenmiş durumda tutar.

Azure Synapse Link ile artık Azure Synapse Analytics'ten Azure Cosmos DB kapsayıcılarınıza doğrudan bağlanabilir ve analiz deposuna istek birimi (istek birimi) maliyeti olmadan erişebilirsiniz. Azure Synapse Analytics şu anda Synapse Apache Spark ve sunucusuz SQL havuzları ile Azure Synapse Link'i desteklemektedir. Genel olarak dağıtılmış bir Azure Cosmos DB hesabınız varsa, bir kapsayıcı için analiz deposunu etkinleştirdikten sonra bu hesap tüm bölgelerde kullanılabilir.

Analitik depo otomatik şema çözümlemesi

Azure Cosmos DB işlem deposu satır odaklı yarı yapılandırılmış verilerdir, analiz deposu ise sütunlu ve yapılandırılmış bir biçim kullanır. Bu dönüştürme, analiz deposu için şema çıkarım kuralları kullanılarak müşteriler için otomatik olarak yapılır. Dönüştürme işleminde sınırlar vardır: iç içe düzey sayısı üst sınırı, maksimum özellik sayısı, desteklenmeyen veri türleri ve daha fazlası.

Not

Analiz deposu bağlamında, aşağıdaki yapıları özellik olarak değerlendiririz:

• JSON "elements" veya "string-value pair separated by a :"
• ve ile { sınırlandırılmış JSON nesneleri }
• ve ile [ sınırlandırılmış JSON dizileri ]

Aşağıdaki teknikleri kullanarak şema çıkarım dönüşümlerinin etkisini en aza indirip analiz yeteneklerinizi en üst düzeye çıkarabilirsiniz.

Normalleştirme

Azure Synapse Link, T-SQL veya Spark SQL kullanarak kapsayıcılara katılmanıza olanak sağladığından normalleştirme daha az ilgili hale gelir. Normalleştirmenin beklenen avantajları şunlardır:

• İşlem ve analitik depolarda daha küçük bir veri ayak izi.
• Daha küçük işlemler.
• Belge başına daha az özellik.
• Daha az iç içe düzeye sahip veri yapıları.

Verilerinizde daha az özelliğe ve daha az düzeye sahip olmak analiz sorgularını hızlandırır. Ayrıca verilerinizin tüm bölümlerinin analiz deposuna dahil olduğundan emin olunmasını sağlar. Otomatik şema çıkarımı kurallarıyla ilgili makalede açıklandığı gibi, analiz deposunda temsil edilen düzey ve özellik sayısının sınırları vardır.

Normalleştirme için bir diğer önemli faktör de, Azure Synapse'deki SQL sunucusuz havuzların en fazla 1.000 sütun içeren sonuç kümelerini desteklemesi ve iç içe sütunları kullanıma çıkarmanın da bu sınıra doğru sayılmasıdır. Başka bir deyişle hem analiz deposu hem de Synapse SQL sunucusuz havuzları 1.000 özellik sınırına sahiptir.

Ancak normal dışı hale getirme, Azure Cosmos DB için önemli bir veri modelleme tekniği olduğundan ne yapmalı? Bunun yanıtı, işlemsel ve analitik iş yükleriniz için doğru dengeyi bulmanız gerektiğidir.

Bölüm Anahtarı

Azure Cosmos DB bölüm anahtarı (PK) analiz deposunda kullanılmaz. Artık analiz deposu özel bölümlemesini, istediğiniz PK'yi kullanarak analiz deposu kopyalarının alınmasında kullanabilirsiniz. Bu yalıtım nedeniyle işlem verileriniz için veri alımına ve nokta okumalarına odaklanan bir PK seçebilirsiniz; bölümler arası sorgular ise Azure Synapse Link ile yapılabilir. Bir örnek görelim:

Varsayımsal bir genel IoT senaryosunda, device id tüm cihazlar sık erişimli bölüm sorunlarını önleyen benzer bir veri hacmi oluşturduğundan iyi bir bölüm anahtarı görevi görür. Ancak "dünkü tüm veriler" veya "şehir başına toplamlar" gibi birden fazla cihazın verilerini analiz etmek istiyorsanız, bu sorgular bölümler arası sorgular olduğundan sorunlarla karşılaşabilirsiniz. Bu sorgular, çalıştırmak için istek birimlerinde aktarım hızınızın bir kısmını kullandığından işlem performansınıza zarar verebilir. Ancak Azure Synapse Link ile bu analiz sorgularını istek birimi maliyeti olmadan çalıştırabilirsiniz. Analiz deposu sütunlu biçimi analiz sorguları için iyileştirilmiştir ve Azure Synapse Link, Azure Synapse Analytics çalışma zamanlarında harika performansı destekler.

Veri türleri ve özellik adları

Otomatik şema çıkarımı kuralları makalesinde desteklenen veri türlerinin ne olduğu listelenir. Azure Synapse çalışma zamanları desteklenen veri türlerini farklı şekilde işleyebilecek olsa da, desteklenmeyen veri türleri analiz deposunda gösterimi engeller. Örneklerden biri: ISO 8601 UTC standardına uyan DateTime dizelerini kullanırken, Azure Synapse'teki Spark havuzları bu sütunları olarak, Azure Synapse'deki SQL sunucusuz havuzları ise bu sütunları olarak stringvarchar(8000)temsil eder.

Bir diğer zorluk da Azure Synapse Spark'ın tüm karakterleri kabul etmemesidir. Beyaz boşluklar kabul edilirken iki nokta üst üste, aksan işareti ve virgül gibi karakterler kabul edilmez. Öğenizin "Ad, Soyadı" adlı bir özelliği olduğunu varsayalım. Bu özellik analiz deposunda temsil edilir ve Synapse SQL sunucusuz havuzu bunu sorunsuz bir şekilde okuyabilir. Ancak analiz deposunda olduğundan Azure Synapse Spark diğer tüm özellikler de dahil olmak üzere analiz deposundan veri okuyamaz. Günün sonunda, adlarında desteklenmeyen karakterleri kullanan bir özelliğiniz olduğunda Azure Synapse Spark'ı kullanamazsınız.

Veri düzleştirme

Azure Cosmos DB verilerinizin en üst düzeyindeki her özellik analiz deposunda bir sütuna dönüşür. İç içe nesneler veya diziler içindeki özellikler analiz deposunda JSON olarak depolanır ve yapıları tutulur. İç içe yapılar, verileri yapılandırılmış biçimde düzleştirmek için Azure Synapse çalışma zamanlarından ek işlemeye ihtiyaç duyar. Bu, büyük veri senaryolarında bir zorluk olarak görülebilir.

Öğenin analiz deposunda id yalnızca iki sütunu vardır ve contactDetails. , ve emaildiğer tüm veriler, phoneSQL işlevleri aracılığıyla ayrı ayrı okunmasını gerektirir.

{
    "id": "1",
    "contactDetails": [
        {"email": "thomas@andersen.com"},
        {"phone": "+1 555 555-5555"}
    ]
}

Öğenin analiz deposunda üç sütunu vardır: id, emailve phone. Tüm verilere doğrudan sütun olarak erişilebilir.

{
    "id": "1",
    "email": "thomas@andersen.com",
    "phone": "+1 555 555-5555"
}

Veri katmanlama

Azure Synapse Link, maliyetleri aşağıdaki açılardan azaltmanıza olanak tanır:

• İşlem veritabanınızda daha az sorgu çalışıyor.
• Veri alımı ve nokta okumaları için iyileştirilmiş bir PK, veri ayak izini, sık erişimli bölüm senaryolarını ve bölüm bölmelerini azaltır.
• Veri katmanlama, analitik yaşam süresi (attl) işlem yaşam süresinden (tttl) bağımsız olduğundan. İşlem verilerinizi birkaç gün, hafta, ay boyunca işlem deposunda tutabilir ve verileri yıllar boyunca veya sonsuza kadar analiz deposunda tutabilirsiniz. Analitik depo sütunlu biçimi , %50'den %90'a kadar doğal bir veri sıkıştırması getirir. Gb başına maliyeti ise işlemsel mağaza gerçek fiyatının yaklaşık %10'unu oluşturur. Geçerli yedekleme sınırlamaları hakkında daha fazla bilgi için bkz Analitik Depolama Genel Bakışı.
• Ortamınızda çalıştırılan ETL işi yok, yani bunlar için istek birimleri ayırmanız gerekmez.

Denetimli yedeklilik

Bu teknik, veri modelinin zaten mevcut olduğu ve değiştirilebildiği durumlar için harika bir alternatiftir. Geçerli veri modeli analiz deposuyla iyi çalışmıyor. Analiz deposu, verileri iç içe yerleştirebileceğiniz düzey sayısını ve her belgede sahip olabileceğiniz özellikleri sınırlayan kurallar içerdiği için bu avantaj vardır. Verileriniz çok karmaşıksa veya çok fazla alanı varsa bazı önemli bilgiler analiz deposuna eklenmeyebilir. Bu senaryo sizin durumunuzsa, Azure Synapse Link kolay veri modeli için gerekli dönüştürmeleri uygulayarak verilerinizi başka bir kapsayıcıya çoğaltmak için Azure Cosmos DB Değişiklik Akışı'nı kullanabilirsiniz. Bir örnek görelim:

Senaryo

Müşteri ve ürün ayrıntıları dahil olmak üzere satır içi siparişleri depolamak için kapsayıcı CustomersOrdersAndItems kullanılır: fatura adresi, teslimat adresi, teslimat yöntemi, teslimat durumu, ürün fiyatı vb. Yalnızca ilk 1.000 özellik temsil edilir ve analiz deposuna önemli bilgiler eklenmediğinden Azure Synapse Link kullanımı engellenir. Kapsayıcıda petabaytlarça kayıt var, uygulamayı değiştirmek ve verileri yeniden modellemek mümkün değildir.

Sorunun bir diğer yönü de büyük veri hacmidir. Analiz Departmanı tarafından eski veri silme işlemleri için tttl kullanılmasını engelleyen milyarlarca satır sürekli olarak kullanılır. Analiz gereksinimleri nedeniyle işlem veritabanında veri geçmişinin tamamını korumak, bunları istek birimi sağlamayı sürekli artırmaya zorlayarak maliyetleri etkiler. İşlemsel ve analitik iş yükleri aynı anda aynı kaynaklar için rekabet eder.

Ne yapabilirsin ki?

Değişiklik Akışı ile Çözüm

• Mühendislik ekibi, üç yeni kapsayıcıyı doldurmak için Değişiklik Akışı'nı kullanmaya karar verdi: Customers, Ordersve Items. Değişiklik Akışı ile verileri normalleştirir ve düzleştirir. Gereksiz bilgiler veri modelinden kaldırılır ve her kapsayıcı 100'e yakın özelliğe sahiptir ve otomatik şema çıkarım sınırları nedeniyle veri kaybını önler.
• Bu yeni kapsayıcılarda analiz deposu etkindir ve Analiz Departmanı verileri okumak için Synapse Analytics'i kullanır. Bu, analiz sorguları Synapse Apache Spark ve sunucusuz SQL havuzlarında çalıştırıldığından istek birimi kullanımını azaltır.
• Azure CustomersOrdersAndItems Cosmos DB'de GB başına en az bir istek birimi olduğundan kapsayıcının artık verileri yalnızca altı ay boyunca tutacak şekilde ayarlanmış yaşam süresi (TTL) vardır. Bu da başka bir istek birimi kullanımını azaltmaya olanak tanır. Daha az veri, daha az istek birimi.

Çıkarımlar

Bu makaleden en büyük sonuç, şemasız bir senaryoda veri modellemenin her zamanki gibi önemli olmasıdır.

Ekranda bir veri parçasını temsil etmenin tek bir yolu olmadığı gibi, verilerinizi modellemenin tek bir yolu yoktur. Uygulamanızı ve verileri nasıl ürettiğini, tükettiği ve işlediğini anlamanız gerekir. Burada sunulan yönergeleri uygulayarak, uygulamanızın hemen gereksinimlerini karşılayan bir model oluşturabilirsiniz. Uygulamanız değiştiğinde, veri modelinizi kolayca uyarlamak ve geliştirmek için şemasız veritabanının esnekliğini kullanın.

İlgili içerik

• Azure Cosmos DB'de verileri bölümleme
• Veri modelleme ve bölümleme - gerçek dünya örneği
• Azure Cosmos DB'de verilerinizi modelleme ve bölümleme