Azure Cosmos DB analiz deposu nedir?

Uygulama hedefı: MongoDB IÇIN SQL API Azure Cosmos DB API 'si

Azure Cosmos DB analiz deposu, işlemsel iş yüklerinizi etkilemeden Azure Cosmos DB'nizin işletimsel verilerine karşı büyük ölçekli analizlere olanak sağlayan, tamamen yalıtılmış bir sütun deposu.

Azure Cosmos DB işlem deposu şemadan bağımsızdır ve şema veya dizin yönetimiyle uğraşmak zorunda kalmadan işlem uygulamalarınızı yeniden kullanmanızı sağlar. Buna karşılık Azure Cosmos DB analiz deposu, analiz sorgusu performansı için en iyi duruma getirmek için şemaya göre hazır hale getirildi. Bu makalede analiz depolaması hakkında ayrıntılı bilgiler ve bilgiler yer almaktadır.

operasyonel veriler üzerinde büyük ölçekli analizle ilgili zorluklar

Azure Cosmos DB kapsayıcısı içinde bulunan çok modelli işletimsel veriler, dizine alınan satır tabanlı "işlem deposu" içinde depolanır. Satır deposu biçimi, milisaniyelik yanıt süreleri ve işlem sorgularında hızlı işlem okuma ve yazma işlemlerine izin verecek şekilde tasarlanmıştır. Veri kümeniz büyük ölçüde büyürse, bu biçimde depolanan veriler üzerinde sağlanan aktarım hızı açısından karmaşık analiz sorguları pahalı olabilir. Sağlanan aktarım hızının yüksek tüketimi, gerçek zamanlı uygulama ve hizmetleriniz tarafından kullanılan işlem iş yüklerinin performansını etkiler.

Geleneksel olarak, büyük miktarlardaki verileri analiz etmek için işlem verileri Azure Cosmos DB'nin işlem depolamadan ayıklanır ve ayrı bir veri katmanında depolanır. Örneğin, veriler uygun bir biçimde bir veri ambarında veya veri gölünde depolanır. Bu veriler daha sonra büyük ölçekli analizler için kullanılır ve kümeler gibi işlem altyapısı kullanılarak Apache Spark analiz edilir. İşlemsel iş yükleriniz üzerindeki olası etkiyi en aza indirmek için ETL(Ayıkla, Dönüştür, Yükle) işlem hatları daha az sıklıkta çalıştırılana kadar analiz depolama ve işlem katmanlarının işlem verilerinden ayrılması ek gecikme süresine neden olur.

EtL işlem hatları, yalnızca yeni alınan işletimsel verileri işlemeye kıyasla işletimsel verilerde güncelleştirmeleri işleme konusunda da karmaşık hale geliyor.

Sütun odaklı analiz deposu

Azure Cosmos DB analiz deposu, geleneksel ETL işlem hatlarında oluşan karmaşıklık ve gecikme süresi zorluklarını karşılar. Azure Cosmos DB analiz deposu, operasyonel verilerinizi ayrı bir sütun deposuna otomatik olarak eşitler. Sütun deposu biçimi, büyük ölçekli analitik sorguların iyileştirilmiş bir şekilde gerçekleştirerek bu tür sorguların gecikme süresini artırmaya uygundur.

Azure Synapse Link'i kullanarak artık azure Cosmos DB analiz deposuna doğrudan bağlantı kurarak no-ETL HTAP çözümleri Azure Synapse Analytics. İşletimsel verileriniz üzerinde gerçek zamanlıya yakın büyük ölçekli analizler çalıştırmanıza olanak sağlar.

Analiz deposu özellikleri

Azure Cosmos DB kapsayıcısı üzerinde analiz deposunu etkinleştiren yeni bir sütun deposu, kapsayıcıdaki işlem verilerine göre oluşturulur. Bu sütun deposu, bu kapsayıcı için satır odaklı işlem deposundan ayrı olarak kalıcıdır. İşletimsel verilerinize yapılan eklemeler, güncelleştirmeler ve silmeler analiz deposuna otomatik olarak eşitlenir. Verileri eşitlemek için değişiklik akışına veya ETL'ye ihtiyacınız yok.

İşletimsel veriler üzerinde analitik iş yükleri için sütun deposu

Analitik iş yükleri genellikle seçili alanların toplamalarını ve sıralı taramalarını içerir. Analiz deposu, verileri sütun anadili sırasıyla depolayarak her bir alan için bir değer grubunun birlikte seri hale getirmelerini sağlar. Bu biçim, belirli alanlar üzerinde istatistikleri taramak veya hesaplamak için gereken IOPS'i azaltır. Büyük veri kümeleri üzerinde taramalar için sorgu yanıt sürelerini önemli ölçüde iyiler.

Örneğin, işletimsel tablolarınız aşağıdaki biçimde ise:

Örnek işlem tablosu

Satır deposu, yukarıdaki verileri diskte satır başına serileştirilmiş biçimde kalıcı hale getirmektedir. Bu biçim, "Product1 hakkında bilgi iade" gibi daha hızlı işlem okuma, yazma ve işlem sorguları sağlar. Ancak, veri kümesi büyüdükçe ve veriler üzerinde karmaşık analitik sorgular çalıştırmak için pahalı olabilir. Örneğin, "farklı iş birimlerinde ve aylarda "Ekipman" kategorisindeki bir ürünün satış eğilimlerini almak için karmaşık bir sorgu çalıştırmamız gerekir. Bu veri kümesinde yapılan büyük taramalar sağlanan aktarım hızı açısından pahalıya mal olabilir ve gerçek zamanlı uygulama ve hizmetlerinizi etkileyen işlem iş yüklerinin performansını da etkileyebilir.

Sütun deposu olan analiz deposu, benzer veri alanlarını birlikte seri hale getirmesi ve disk IOPS'yi azaltması nedeniyle bu tür sorgular için daha uygun olur.

Aşağıdaki görüntüde Azure Cosmos DB'de işlem satırı deposu ile analiz sütun deposu karşılaştırması yer alır:

Azure Cosmos DB'de işlem satırı deposu ile analiz sütun deposu karşılaştırması

Analiz iş yükleri için birlikte çalışan performans

Analiz deposu, işlem deposundan ayrı olduğu için analiz sorguları nedeniyle işlemsel iş yüklerinin performansı üzerinde herhangi bir etki olmaz. Analiz deposu için ayrı istek birimleri (RU) ayırmak zorunda değildir.

Otomatik Eşitleme

Otomatik Eşitleme, azure Cosmos DB'nin işletimsel verilere ekleme, güncelleştirme ve silme işlemlerinin işlemsel depodan analiz deposuna neredeyse gerçek zamanlı olarak otomatik olarak eşitlenen tam olarak yönetilen özelliğini ifade eder. Otomatik eşitleme gecikmesi genellikle 2 dakika içinde olur. Çok sayıda kapsayıcıya sahip paylaşılan aktarım hızı veritabanı durumlarında, tek tek kapsayıcıların otomatik eşitleme gecikme süresi daha yüksek olabilir ve 5 dakikaya kadar sürebilir. Bu gecikme süresinin senaryolarınıza nasıl uyduğunu öğrenmek için daha fazla bilgi edinmek istiyorum. Bunun için lütfen Azure veritabanı ekibine Cosmos edin.

Otomatik eşitleme işleminin her yürütmesi sonunda, işlem verileriniz çalışma zamanları için anında Azure Synapse Analytics olur:

  • Azure Synapse Analytics Spark havuzları, en son güncelleştirmeler dahil olmak üzere tüm verileri, otomatik olarak güncelleştirilen Spark tabloları aracılığıyla veya her zaman verilerin son durumunun okunan komutu aracılığıyla spark.read okuyabilir.

  • Azure Synapse Analytics SQL sunucusuz havuzlar, en son güncelleştirmeler dahil olmak üzere tüm verileri, otomatik olarak güncelleştirilen görünümler aracılığıyla veya her zaman verilerin en son durumunun okunan komutlarla birlikte SELECT OPENROWSET okuyabilir.

Not

İşlem TTL'niz 2 dakikadan kısa olsa bile işlem verileriniz analiz deposuyla eşitlenir.

Ölçeklenebilirlik & esneklik

Yatay bölümleme kullanarak Azure Cosmos DB işlem deposu, kapalı kalma süresi olmadan depolama ve aktarım hızını esnek bir şekilde ölçeklendirebilirsiniz. İşlem deposuna yatay bölümleme, verilerin & gerçek zamanlıya yakın bir şekilde analiz deposuna eşitlenmiş olduğundan emin olmak için otomatik eşitlemede ölçeklenebilirlik ve esneklik sağlar. Veri eşitleme, işlem trafiği aktarım hızına bakılmaksızın(1000 işlem/sn veya 1 milyon işlem/sn) gerçekleşir ve işlem deposu içinde sağlanan aktarım hızını etkilemez.

Şema güncelleştirmelerini otomatik olarak işleme

Azure Cosmos DB işlem deposu şemadan bağımsızdır ve şema veya dizin yönetimiyle uğraşmak zorunda kalmadan işlem uygulamalarınızı yeniden kullanmanızı sağlar. Buna karşılık Azure Cosmos DB analiz deposu, analiz sorgusu performansı için en iyi duruma getirmek için şemaya göre hazır hale getirildi. Otomatik eşitleme özelliğiyle Azure Cosmos DB, işlem deposuna gelen en son güncelleştirmeler üzerinden şema çıkarma özelliğini yönetir. Ayrıca, iç içe veri türlerini işlemeyi de içeren, analiz deposu şema gösterimini kullanımdan yönetir.

Şemanız geliştikçe ve zaman içinde yeni özellikler eklendikçe, analiz deposu işlem deposuna tüm geçmiş şemalar arasında otomatik olarak birleştirilmiş bir şema sunar.

Not

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

  • JSON "elements" veya "string-value pairs separated by a : ".
  • ve ile ayrılmış JSON { } nesneleri.
  • ve ile ayrılmış JSON [ ] dizileri.

Şema kısıtlamaları

Analiz deposuna otomatik olarak çıkarım yapmak ve şemayı doğru şekilde temsil etmek için etkinleştirilen Azure Cosmos DB'nin işletimsel verileri için aşağıdaki kısıtlamalar geçerlidir:

  • Şemada herhangi bir iç içe yerleştirme düzeyinde en fazla 1000 özellik ve iç içe yerleştirme derinliği en fazla 127 olabilir.

    • Analiz depoda yalnızca ilk 1000 özellik temsil edildi.
    • Analiz deposu içinde yalnızca ilk 127 iç içe geçmiş düzey temsil edildi.
    • JSON belgesinin ilk düzeyi kök / düzeyidir.
    • Belgenin ilk düzeyindeki özellikler sütun olarak temsil edilen özelliklerdir.
  • Örnek senaryolar:

    • Belgenizin ilk düzeyi 2000 özeliklere sahipse yalnızca ilk 1000 temsili olur.
    • Belgeleriniz her biri 200 özellik ile 5 düzeye sahipse, tüm özellikler temsil olur.
    • Belgeleriniz her biri 400 özellik ile 10 düzeye sahipse, analiz deposuna yalnızca 2 ilk düzey tam olarak temsil olacaktır. Üçüncü düzeyin yarısı da temsili olur.
  • Aşağıdaki kuramsal belgede 4 özellik ve 3 düzey yer almaktadır.

    • Düzeyleri , root myArray ve içindeki iç içe geçmiş myArray yapıdır.
    • Özellikler , id myArray ve myArray.nested1 myArray.nested2 'tir.
    • Analiz deposu gösteriminin 2 sütunu ve id myArray olacak. İç içe geçmiş yapıları sütun olarak SQL spark veya T-SQL işlevlerini de kullanabilirsiniz.
{
  "id": "1",
  "myArray": [
    "string1",
    "string2",
    {
      "nested1": "abc",
      "nested2": "cde"
    }
  ]
}
  • JSON belgeleri (Cosmos DB koleksiyonları/kapsayıcıları) benzersizlik açısından büyük/büyük/büyük harfe duyarlıdır, ancak analiz deposu değildir.

    • Aynı belgede: Büyük/büyük/büyük harfe duyarlı olmayan özellikler aynı düzeyde benzersiz olmalıdır. Örneğin, aşağıdaki JSON belgesinde aynı düzeyde "Name" ve "name" vardır. Geçerli bir JSON belgesi olduğu için benzersizlik kısıtlamasını karşılamaz ve bu nedenle analiz deposuna tam olarak temsili olmaz. Bu örnekte büyük/küçük harfe duyarsız bir şekilde karşılaştırıldıklarında "Ad" ve "ad" aynı olur. Yalnızca "Name": "fred" analiz deposuna temsil edilen, ilk oluşum olduğu için. "name": "john"Ve hiçbir şekilde temsil olmayacak.
    {"id": 1, "Name": "fred", "name": "john"}
    
    • Farklı belgelerde: Aynı düzeyde ve aynı adla ancak farklı durumlarda özellikler, ilk oluşum ad biçimi kullanılarak aynı sütunda temsil edilen özelliklerdir. Örneğin, aşağıdaki JSON belgelerde "Name" ve "name" aynı düzeydedir. İlk belge biçimi olduğu "Name" için analiz deposu özellik adını temsil etmek için bu kullanılır. Başka bir deyişle analiz deposu sütun adı "Name" olur. hem "fred" "john" hem de sütununda temsil "Name" edilen.
    {"id": 1, "Name": "fred"}
    {"id": 2, "name": "john"}
    
  • Koleksiyonun ilk belgesi ilk analitik depo şemasını tanımlar.

    • İlk şemadan daha fazla özelliği olan belgeler, analitik depoda yeni sütunlar oluşturacak.
    • Sütunlar kaldırılamaz.
    • Bir koleksiyondaki tüm belgelerin silinmesi analitik depo şemasını sıfırlayamaz.
    • Şema sürümü oluşturma yok. İşlemsel depodan çıkarılan son sürüm, analitik depoda göreceğiniz şeydir.
  • Şu anda Azure SYNAPSE Spark, adlarında aşağıda listelenen bazı özel karakterleri içeren özellikleri okuyamamaktadır. Azure Synapse SQL sunucusuz etkilenmez.

    • : (İki nokta üst üste)
    • ' (Aksan işareti)
    • , (Virgül)
    • ; Noktalı virgülle
    • {}
    • ()
    • \n
    • \t
    • = (Eşittir işareti)
    • "(Tırnak işareti)
  • Yukarıda listelenen karakterleri kullanarak Özellikler adlarınız varsa, alternatifler şunlardır:

    • Bu karakterleri önlemek için veri modelinizi önceden değiştirin.
    • Şu anda şema sıfırlamayı desteklemediğimiz için, uygulamanızı değiştirerek benzer bir ada sahip gereksiz bir özellik ekleyebilirsiniz ve bu karakterleri önleyebilirsiniz.
    • Özellikler adlarında bu karakterler olmadan kapsayıcının gerçekleştirilmiş bir görünümünü oluşturmak için değişiklik akışını kullanın.
    • dropColumnEtkilenen sütunları yoksaymak ve diğer tüm sütunları bir veri çerçevesine yüklemek için Spark seçeneğini kullanın. Söz dizimi aşağıdaki gibidir:
df = spark.read\
     .format("cosmos.olap")\
     .option("spark.synapse.linkedService","<your-linked-service-name>")\
     .option("spark.synapse.container","<your-container-name>")\
     .option("spark.synapse.dropColumn","FirstName,LastName")\
     .load()  

Not

Birden çok sütunu bırakmak için dilediğiniz sırada daha fazla seçenek eklemeniz yeterlidir dropColumn . Örnek:

df = spark.read\
    .format("cosmos.olap")\
    .option("spark.synapse.linkedService","<your-linked-service-name>")\
    .option("spark.synapse.container","<your-container-name>")\
    .option("spark.synapse.dropColumn","FirstName,LastName")\
    .option("spark.synapse.dropColumn","StreetName,StreetNumber")\
    .load()  
  • Azure SYNAPSE Spark artık adlarında boşluklar boşluk olan özellikleri destekliyor. Bu şekilde, allowWhiteSpaceInFieldNames etkilenen sütunları bir veri çerçevesine yüklemek için Spark seçeneğini kullanmanız gerekir ve özgün adı saklayın. Söz dizimi aşağıdaki gibidir:
df = spark.read\
     .format("cosmos.olap")\
     .option("spark.synapse.linkedService","<your-linked-service-name>")\
     .option("spark.synapse.container","<your-container-name>")\
     .option("spark.cosmos.allowWhiteSpaceInFieldNames", "true")\
    .load()
  • Aşağıdaki BSON veri türleri desteklenmez ve analitik depoda gösterilmez:

    • Decimal128
    • Normal ifade
    • DB Işaretçisi
    • JavaScript
    • Sembol
    • MinKey/MaxKey
  • ISO 8601 UTC standardını izleyen DateTime dizelerini kullanırken aşağıdaki davranışı bekler:

    • Azure SYNAPSE 'daki Spark havuzları bu sütunları olarak temsil eder string .
    • Azure Synapse 'deki sunucusuz havuzlar SQL, bu sütunları olarak temsil eder varchar(8000) .
  • Azure Synapse 'da sunucusuz havuzlar SQL en fazla 1000 sütun içeren ve iç içe geçmiş sütunları göstermek de bu sınıra doğru sayılır. Veri mimarinizi tasarlarken ve işlem verilerinizi modellarken lütfen bu bilgileri göz önünde bulundurun.

Şema gösterimi

Analitik depoda iki tür şema gösterimi vardır. Bu türler, veritabanı hesabındaki tüm kapsayıcılar için şema gösterimi yöntemini tanımlar ve çok biçimli şemalar için daha kapsamlı bir sütun temsilinin rahatlığını ve sorgu deneyiminin basitliği arasında dengelere sahiptir.

  • iyi tanımlanmış şema temsili, SQL (çekirdek) apı hesapları için varsayılan seçenektir.
  • tam uygunluk şeması temsili, mongodb hesapları için Azure Cosmos DB apı 'si için varsayılan seçenek.

SQL apı hesapları için tam uygunluk şeması

varsayılan seçenek yerine SQL (çekirdek) apı hesapları için tam uygunluk şeması, bir Cosmos DB hesabında ilk kez Synapse bağlantısı etkinleştirildiğinde şema türü ayarlanarak kullanılabilir. Varsayılan şema gösterimi türünü değiştirmekle ilgili konular aşağıda verilmiştir:

  • Bu seçenek yalnızca SYNAPSE bağlantısı etkinleştirilmemiş olan hesaplar için geçerlidir.
  • Şema temsili türü, iyi tanımlanmış ve tam uygunluk veya tam tersi gibi sıfırlanabilir.
  • mongodb hesapları için şu anda Azure Cosmos DB apı 'si, şema gösterimini değiştirme olasılığa uygun değildir. Tüm MongoDB hesaplarının her zaman tam uygunluk şeması temsili türü olacaktır.
  • Şu anda bu değişiklik Azure portal aracılığıyla yapılamaz. Azure portal tarafından etkinleştirilmiş SYNAPSE bağlantısı olan tüm veritabanı hesaplarında varsayılan şema temsili türü, iyi tanımlanmış şema olacaktır.

Şema gösterim türü kararı, hesapta SYNAPSE bağlantısının etkinleştirildiği anda, Azure CLı veya PowerShell kullanılarak yapılmalıdır.

Azure CLı ile:

az cosmosdb create --name MyCosmosDBDatabaseAccount --resource-group MyResourceGroup --subscription MySubscription --analytical-storage-schema-type "FullFidelity" --enable-analytical-storage true

Not

Yukarıdaki komutta, ' yi create update Mevcut hesaplar için ile değiştirin.

PowerShell ile:

 New-AzCosmosDBAccount -ResourceGroupName MyResourceGroup -Name MyCosmosDBDatabaseAccount  -EnableAnalyticalStorage true -AnalyticalStorageSchemaType "FullFidelity"

Not

Yukarıdaki komutta, ' yi New-AzCosmosDBAccount Update-AzCosmosDBAccount Mevcut hesaplar için ile değiştirin.

İyi tanımlanmış şema gösterimi

İyi tanımlanmış şema gösterimi, işlem deposundaki şema belirsiz verilerin basit tablolu bir gösterimini oluşturur. İyi tanımlanmış şema gösterimi aşağıdaki noktalara dikkat edin:

  • İlk belge, temel şemayı tanımlar ve özelliği her zaman tüm belgeler arasında aynı türde olmalıdır. Tek özel durumlar şunlardır:
    • Null değerinden başka herhangi bir veri türü. Null olmayan ilk oluşum, sütun veri türünü tanımlar. İlk null olmayan veri türünü takip edilmeyen tüm belgeler analitik depoda gösterilmeyecektir.
    • Kaynağından float integer . Tüm belgeler analitik depoda temsil edilir.
    • Kaynağından integer float . Tüm belgeler analitik depoda temsil edilir. ancak, bu verileri Azure Synapse SQL sunucusuz havuzlarla okumak için, bir wıth yan tümcesini kullanarak sütunu ' a dönüştürmeniz gerekir varchar . Bu ilk dönüştürmeden sonra tekrar bir sayıya dönüştürmek mümkündür. Lütfen aşağıdaki örneği kontrol edin; burada num Initial değeri bir tamsayı, ikincisi ise bir float idi.
SELECT CAST (num as float) as num
FROM OPENROWSET(PROVIDER = 'CosmosDB',
                CONNECTION = '<your-connection',
                OBJECT = 'IntToFloat',
                SERVER_CREDENTIAL = 'your-credential'
) 
WITH (num varchar(100)) AS [IntToFloat]
  • Temel şema veri türünü takip edilmeyen Özellikler analitik depoda gösterilmez. Örneğin, aşağıdaki 2 belgeyi ve birinci bir analitik depo temel şemasını tanımlacağınızı düşünün. id 2 Özelliğin "a" bir dize olduğu ve ilk belgenin bir sayı olduğu ikinci belge, burada olduğu gibi iyi tanımlanmış bir şemaya sahip değildir "a" . Bu durumda, analitik mağaza "a" integer kapsayıcının kullanım ömrü için veri türünü kaydeder. İkinci belge yine analitik depoya dahil edilecek, ancak "a" özelliği olmayacaktır.

    • {"id": "1", "a":123}
    • {"id": "2", "a": "str"}

Not

Yukarıdaki bu koşul, null özellikler için uygulanmaz. Örneğin, {"a":123} and {"a":null} hala iyi tanımlanmış.

  • Dizi türleri tek bir tekrarlanmış tür içermelidir. Örneğin, {"a": ["str",12]} dizi tamsayı ve dize türleri karışımı içerdiğinden iyi tanımlanmış bir şema değildir.

Not

Azure Cosmos DB analitik depo iyi tanımlanmış şema gösterimini izliyorsa ve yukarıdaki belirtim belirli öğeler tarafından ihlal edilirse, bu öğeler analitik depoya dahil edilmez.

  • İyi tanımlanmış şemadaki farklı türlere göre farklı davranışlar beklenir:

    • Azure SYNAPSE 'daki Spark havuzları bu değerleri olarak temsil eder undefined .
    • Azure Synapse 'deki sunucusuz havuzlar SQL, bu değerleri olarak temsil eder NULL .
  • Açık değerlere göre farklı davranış beklenir null :

    • Azure SYNAPSE 'daki Spark havuzları bu değerleri 0 (sıfır) olarak okur. undefinedSütun null olmayan bir değere sahip olduğu anda olarak değişir.
    • Azure Synapse 'deki sunucusuz havuzlar SQL, bu değerleri olarak okur NULL .
  • Eksik sütunlara göre farklı davranış bekliyor:

    • Azure SYNAPSE 'daki Spark havuzları bu sütunları olarak temsil eder undefined .
    • Azure Synapse 'deki sunucusuz havuzlar SQL, bu sütunları olarak temsil eder NULL .

Tam uygunluk şeması temsili

Tam uygunluk şeması temsili, şema belirsiz işlemsel verilerde çok biçimli şemaların tam kapsamını işlemek için tasarlanmıştır. Bu şema gösteriminde, iyi tanımlanmış şema kısıtlamaları (karışık veri türü alanları veya karışık veri türü dizileri olmayan) ihlal edildiğinde hiçbir öğe analitik depodan atılamaz.

Bu, işletimsel verilerin yaprak özelliklerinin, özelliğindeki değerlerin veri türüne göre ayrı sütunlara sahip analitik depoya çevrilirken elde edilir. Yaprak Özellik adları, analitik depo şemasında, belirsizlik olmadan sorgu olabilecek bir sonek olarak veri türleriyle genişletilir.

Tam doğruluk şeması gösteriminde her bir özelliğin her veri türü, bu veri türü için bir sütun oluşturacaktır. Her biri 1000 en yüksek özelliklerden biri olarak sayılır.

Örneğin, işlem deposunda aşağıdaki örnek belgeyi ele alalım:

{
name: "John Doe",
age: 32,
profession: "Doctor",
address: {
  streetNo: 15850,
  streetName: "NE 40th St.",
  zip: 98052
},
salary: 1000000
}

streetNoİç içe yerleştirilmiş nesne içindeki yaprak özelliği, address analitik depo şemasında bir sütun olarak temsil edilir address.object.streetNo.int32 . Veri türü, sütuna bir sonek olarak eklenir. Bu şekilde, yaprak özelliğinin değerinin streetNo "123" olduğu (bir dize olduğunu notta), analitik deponun şeması, önceden yazılmış bir sütunun türünü değiştirmeden otomatik olarak gelişir. address.object.streetNo.stringBu "123" değerinin depolandığı şekilde analitik depoya eklenen yeni bir sütun.

Sonek eşlemesine veri türü

Bu, tüm özellik veri türlerinin ve bunların son ek temsillerini analitik deposunda bir eşlemedir:

Özgün veri türü Önekini Örnek
Çift ". float64" 24,99
Dizi ". Array" ["a", "b"]
İkili ". Binary" 0
Boole ". bool" Doğru
Int32 ". Int32" 123
Int64 ". Int64" 255486129307
Null ". null" null
Dize ". String" "ABC"
Timestamp ". Timestamp" Zaman damgası (0, 0)
DateTime ". Date" Iztarihi ("2020-08-21T07:43:07.375 Z")
ObjectId ". ObjectID" ObjectID ("5f3f7b59330ec25c132623a2")
Belge ". Object" {"a": "a"}
  • Açık değerlere göre farklı davranış beklenir null :

    • Azure SYNAPSE 'daki Spark havuzları bu değerleri 0 (sıfır) olarak okur.
    • Azure Synapse 'deki sunucusuz havuzlar SQL, bu değerleri olarak okur NULL .
  • Eksik sütunlara göre farklı davranış bekliyor:

    • Azure SYNAPSE 'daki Spark havuzları bu sütunları olarak temsil eder undefined .
    • Azure Synapse 'deki sunucusuz havuzlar SQL, bu sütunları olarak temsil eder NULL .

Geçmiş verilerin düşük maliyetli Arşivi

Veri katmanlaması, farklı senaryolar için optimize edilmiş depolama altyapıları arasındaki verilerin ayrılmasının anlamına gelir. Böylece uçtan uca veri yığınının genel performansını ve maliyet verimliliğini artırmaktır. analitik depolarla Azure Cosmos DB artık, işlem deposundan farklı veri düzenleriyle analitik depoya verilerin otomatik olarak katmanlamasını desteklemektedir. Depolama maliyeti ile karşılaştırıldığında, işlemsel depolamayla karşılaştırıldığında analitik depolamayla en iyi duruma getirilmiş bir işlem, geçmiş analizi için işletimsel verilerin çok daha uzun Horizons.

Analitik depo etkinleştirildikten sonra, işlem iş yüklerinin veri bekletme gereksinimlerine bağlı olarak, belirli bir süre sonra işlem deposundan kayıtları otomatik olarak silmek için ' Işlem depolama süresi canlı (Işlem TTL) ' özelliğini yapılandırabilirsiniz. Benzer şekilde, ' etkin analitik depolama süresi (analitik TTL) ', analitik depoda saklanan veri yaşam döngüsünü işlem deposundan bağımsız olarak yönetmenizi sağlar. Analitik depoyu etkinleştirerek ve TTL özelliklerini yapılandırarak, iki depo için veri saklama süresini sorunsuzca düzenleyebilir ve tanımlayabilirsiniz.

Not

Şu anda analitik Depo yedekleme ve geri yüklemeyi desteklemiyor. Yedekleme ilkeniz, analitik depoya bağlı olarak planlanalınamaz. Daha fazla bilgi için Bu belgenin sınırlamalar bölümüne bakın. Analitik depodaki verilerin, işlem deposunda bulunandan farklı bir şemaya sahip olduğunu unutmamak önemlidir. Analitik mağaza verilerinizin anlık görüntülerini, her bir RUs maliyette oluşturmak için, bu anlık görüntünün kullanımını garanti edemeyiz. Bu işlem desteklenmiyor.

Genel Dağıtım

küresel olarak dağıtılmış bir Azure Cosmos DB hesabınız varsa, bir kapsayıcı için analitik depoyu etkinleştirdikten sonra, bu hesabın tüm bölgelerinde kullanılabilir olacaktır. İşletimsel verilerde yapılan tüm değişiklikler genel olarak tüm bölgelerde çoğaltılır. analitik sorguları, Azure Cosmos DB verilerinizin en yakın bölgesel kopyasına göre etkili bir şekilde çalıştırabilirsiniz.

Bölümleme

Analitik depo bölümlendirme işlemi, işlem deposundaki bölümlemeden tamamen bağımsızdır. Varsayılan olarak, analitik depodaki veriler bölümlenmez. Analitik sorgularınızda sık kullanılan filtreler varsa, daha iyi sorgu performansı için bu alanlara göre bölümleme seçeneğiniz vardır. Daha fazla bilgi edinmek için özel bölümlemeye giriş ve özel bölümlendirme makalelerini yapılandırma konusuna bakın.

Güvenlik

  • Analitik depo Ile kimlik doğrulaması , belirli bir veritabanı için işlem deposuyla aynıdır. Kimlik doğrulaması için birincil, ikincil veya salt okunurdur anahtarlarını kullanabilirsiniz. Spark not defterlerindeki Azure Cosmos DB anahtarlarının yapıştırmayı engellemek için Synapse Studio 'daki bağlı hizmetten yararlanabilirsiniz. Azure Synapse SQL sunucusuz için SQL kimlik bilgilerini kullanarak SQL not defterlerindeki Azure Cosmos DB anahtarların yapıştırmayı da önleyebilirsiniz. bu bağlı hizmetlere veya bu SQL kimlik bilgilerine erişim, çalışma alanına erişimi olan herkes tarafından kullanılabilir.

  • Özel uç noktalar kullanarak ağ yalıtımı -işlem ve analitik mağazalardaki verilere yönelik olarak ağ erişimini denetleyebilirsiniz. Ağ yalıtımı, Azure SYNAPSE çalışma alanlarındaki yönetilen sanal ağlarda bulunan her bir mağaza için ayrı yönetilen özel uç noktalar kullanılarak yapılır. Daha fazla bilgi için bkz. analitik depo için özel uç noktaları yapılandırma makalesi.

  • Müşteri tarafından yönetilen anahtarlarla veri şifreleme -aynı müşteri tarafından yönetilen anahtarları otomatik ve şeffaf bir şekilde kullanarak işlem ve analitik mağazalardaki verileri sorunsuzca şifreleyebilirsiniz. Azure Synapse Link yalnızca Azure Cosmos DB hesabınızın yönetilen kimliğini kullanarak müşteri tarafından yönetilen anahtarların yapılandırılmasını destekler. Hesabınızda Azure SYNAPSE bağlantısını etkinleştirmeden önce hesabınızın yönetilen kimliğini Azure Key Vault erişim ilkenizde yapılandırmanız gerekir. daha fazla bilgi edinmek için bkz. Azure Cosmos DB hesaplarının yönetilen kimliklerini kullanarak müşteri tarafından yönetilen anahtarları yapılandırma .

Birden çok Azure SYNAPSE Analytics çalışma zamanı desteği

Analitik depo, işlem çalıştırma sürelerine hiçbir bağımlılığı olmadan analitik iş yükleri için ölçeklenebilirlik, esneklik ve performans sağlamak üzere iyileştirilmiştir. Depolama teknolojisi, el ile gerçekleştirilen çalışmalar olmadan analiz iş yüklerinizi iyileştirmek için kendi kendine yönetilir.

analitik depolama sistemi analitik işlem sisteminden ayrıldıktan sonra, Azure Cosmos DB analitik depodaki veriler Azure Synapse analytics tarafından desteklenen farklı analiz çalışma zamanları ile aynı anda sorgulanabilir. bugün itibariyle Azure Synapse Analytics, Azure Cosmos DB analitik depolarla Apache Spark ve sunucusuz SQL havuzunu destekler.

Not

Yalnızca Azure SYNAPSE Analytics çalışma zamanları kullanarak analitik depolamadan okuyabilirsiniz. Ayrıca, tersi de geçerlidir; Azure SYNAPSE Analytics çalışma zamanları yalnızca analitik depodan okunabilir. Analitik depodaki verileri yalnızca otomatik eşitleme işlemi değiştirebilir. yerleşik Azure Cosmos DB OLTP SDK 'sını kullanarak Azure Synapse Analytics Spark havuzunu kullanarak Cosmos DB işlem deposuna geri veri yazabilirsiniz.

Fiyat

Analitik mağaza, ücretlendirilebilen tüketim tabanlı bir fiyatlandırma modeli izler:

  • Depolama: analitik TTL tarafından tanımlanan geçmiş veriler de dahil olmak üzere her ay analitik depoda tutulan verilerin hacmi.

  • Analitik yazma işlemleri: işletimsel veri güncelleştirmelerinin tam olarak yönetilen işlem, işlem deposundan analitik depoya eşitlenmesi (otomatik eşitleme)

  • Analitik okuma işlemleri: Spark havuzundan analiz deposuna karşı gerçekleştirilen okuma Azure Synapse Analytics sunucusuz SQL çalışma süreleri.

Analiz deposu fiyatlandırması, işlem deposu fiyatlandırma modelinden ayrıdır. Analiz mağazasında sağlanan RU kavramı yoktur. Analiz deposu Cosmos modeli hakkında ayrıntılı bilgi için bkz. Azure Cosmos DB fiyatlandırma sayfası.

Analiz deposu verilerine yalnızca Azure Synapse Link üzerinden erişilebilir. Bu, Azure Synapse Analytics çalışma zamanlarında yapılır: Azure Synapse Apache Spark havuzları ve Azure Synapse sunucusuz SQL havuzları. Analiz Azure Synapse Analytics erişmek için fiyatlandırma modeliyle ilgili tüm ayrıntılar için bkz. fiyatlandırma sayfası.

Bir Azure Cosmos DB kapsayıcısı üzerinde analiz depolarını etkinleştirmek üzere yüksek düzey maliyet tahmini elde etmek için analiz deposu perspektifinden Azure Cosmos DB Kapasite planlayıcısını kullanabilir, analiz depolama ve yazma işlemleri maliyetlerinize ilişkin bir tahmin elde edersiniz. Analiz okuma işlemleri maliyetleri analiz iş yükü özelliklerine bağlıdır, ancak üst düzey bir tahmin olarak analiz deposuna 1 TB veri taraması normalde 130.000 analiz okuma işlemiyle ve 0,065 ABD doları maliyetle sonuç verir.

Not

Analiz deposu okuma işlemleri tahminleri analiz iş yük Cosmos veritabanı maliyet hesaplayıcısına dahil değildir. Yukarıdaki tahmin analiz deposuna 1 TB veri taramak içinse, filtrelerin uygulanması taranan veri hacmini azaltır ve bu da tüketim fiyatlandırma modeline göre analiz okuma işlemlerinin tam sayısını belirler. Analiz iş yüküyle ilgili kavram kanıtı, analiz okuma işlemlerinin daha ince bir tahminini sağlar. Bu tahmin, maliyetlerin maliyetini Azure Synapse Analytics.

Analiz Yaşam Süresi (TTL)

Analiz TTL değeri, bir kapsayıcı için verilerin analiz deponuzda ne kadar süreyle tutulacağını belirtir.

Analiz deposu etkinleştirilirse, işlemsel TTL yapılandırmasına bakılmaksızın işlemsel depodan analiz deposuna otomatik olarak eklemeler, güncelleştirmeler, silmeler eşitlenir. Bu işlem verilerini analiz deposuna saklama, aşağıda belirtilen şekilde kapsayıcı düzeyinde Analiz TTL değeri tarafından denetlenebilirsiniz:

Kapsayıcıda analiz TTL değeri özelliği kullanılarak AnalyticalStoreTimeToLiveInSeconds ayarlanır:

  • Değer "0" olarak ayarlanırsa, eksikse (veya null olarak ayarlanırsa): Analiz deposu devre dışı bırakılır ve işlem deposundan analiz deposuna hiçbir veri çoğaltılmaz

  • Varsa ve değer "-1" olarak ayarlanırsa: analiz deposu, işlem deposuna verilerin elde tutulmasına bakılmaksızın tüm geçmiş verileri korur. Bu ayar analiz deposuna operasyonel verilerinizin sonsuz saklama süresine sahip olduğunu gösterir

  • Varsa ve değer "n" pozitif sayıya ayarlanırsa: öğelerin işlem deposuna son değiştirilme zamanından "n" saniye sonra analiz deposundan süresi dolar. İşlemsel depoda verilerin elde tutulmasına bakılmaksızın işlem verilerinizi analiz deposuna sınırlı bir süre saklamak için bu ayardan faydalanabilirsiniz

Dikkat edilmesi gereken bazı noktalar:

  • Analiz deposu bir analiz TTL değeriyle etkinleştirildikten sonra, daha sonra farklı bir geçerli değere güncelleştirilebilir.
  • İşlem TTL'leri kapsayıcı veya öğe düzeyinde ayarlansa da analitik TTL şu anda yalnızca kapsayıcı düzeyinde ayarlanabilirsiniz.
  • Analiz TTL değerini kapsayıcı düzeyinde >= işlem TTL'sinde ayar >işlemsel verilerinizi analiz deposuna alabilirsiniz.
  • Analiz deposu, analiz TTL = işlem TTL'si ayar tarafından işlem depolarını yansıtmak için yapılmış olabilir.

Bir kapsayıcıda analiz depolarını etkinleştirme:

  • Bu Azure portal analiz TTL seçeneği, açık olduğunda varsayılan -1 değerine ayarlanır. Uygulamanın altındaki kapsayıcı ayarlarına giderek bu değeri 'n' saniye olarak Veri Gezgini.

  • Azure Yönetim SDK'sı, Azure Cosmos DB SDK'ları, PowerShell veya CLI'dan analiz TTL seçeneği -1 veya 'n' saniye olarak ayar tarafından etkinleştirilebilir.

Daha fazla bilgi edinmek için bkz. Kapsayıcıda analiz TTL'lerini yapılandırma.

Sonraki adımlar

Daha fazla bilgi edinmek için aşağıdaki belgelere bakın: