Share via

Pertimbangan platform data untuk beban kerja misi penting di Azure

  • Artikel

Pemilihan platform data aplikasi yang efektif adalah area keputusan yang lebih penting, yang memiliki implikasi yang jauh di seluruh area desain lainnya. Azure pada akhirnya menawarkan banyak platform data relasional, non-relasional, dan analitik, yang sangat berbeda dalam kemampuan. Oleh karena itu penting bahwa persyaratan non-fungsi utama sepenuhnya dipertimbangkan bersama faktor keputusan lainnya seperti konsistensi, pengoperasian, biaya, dan kompleksitas. Misalnya, kemampuan untuk beroperasi dalam konfigurasi tulis multi-wilayah akan memiliki bantalan penting pada kesesuaian untuk platform yang tersedia secara global.

Area desain ini memperluas desain aplikasi, memberikan pertimbangan dan rekomendasi utama untuk menginformasikan pemilihan platform data yang optimal.

Penting

Artikel ini adalah bagian dari seri beban kerja azure Well-Architected misi penting . Jika Anda tidak terbiasa dengan seri ini, kami sarankan Anda memulai dengan apa itu beban kerja misi penting?

Empat Vs Big Data

'Four Vs of Big Data' menyediakan kerangka kerja untuk lebih memahami karakteristik yang diperlukan untuk platform data yang sangat tersedia, dan bagaimana data dapat digunakan untuk memaksimalkan nilai bisnis. Oleh karena itu, bagian ini akan mengeksplorasi bagaimana karakteristik Volume, Velocity, Variety, dan Veracity dapat diterapkan pada tingkat konseptual untuk membantu merancang platform data menggunakan teknologi data yang sesuai.

  • Volume: berapa banyak data yang masuk untuk menginformasikan kapasitas penyimpanan dan persyaratan tingkatan -yaitu ukuran himpunan data.
  • Elokitas V: kecepatan di mana data diproses, baik sebagai batch atau aliran berkelanjutan -yaitu laju aliran.
  • Arity V: organisasi dan format data, menangkap format terstruktur, semi terstruktur, dan tidak terstruktur -yaitu data di beberapa penyimpanan atau jenis.
  • Ketidakpastian V: mencakup pembuktian dan kurasi himpunan data yang dipertimbangkan untuk tata kelola dan jaminan kualitas data -yaitu akurasi data.

Pertimbangan Desain

Volume

  • Volume data yang ada (jika ada) dan yang diharapkan di masa mendatang berdasarkan perkiraan tingkat pertumbuhan data yang selaras dengan tujuan dan rencana bisnis.

    • Volume data harus mencakup data dan indeks, log, telemetri, dan himpunan data lain yang berlaku.
    • Aplikasi penting bisnis besar dan penting misi biasanya menghasilkan dan menyimpan volume tinggi (GB dan TB) setiap hari.
    • Mungkin ada implikasi biaya yang signifikan yang terkait dengan ekspansi data.

  • Volume data dapat berfluktuasi karena perubahan keadaan bisnis atau prosedur pembenahan.

  • Volume data dapat berdampak besar pada performa kueri platform data.

  • Mungkin ada dampak mendalam yang terkait dengan mencapai batas volume platform data.

    • Apakah akan mengakibatkan waktu henti? dan jika demikian, untuk berapa lama?
    • Apa saja prosedur mitigasinya? dan apakah mitigasi memerlukan perubahan aplikasi?
    • Apakah akan ada risiko kehilangan data?

  • Fitur seperti Time to Live (TTL) dapat digunakan untuk mengelola pertumbuhan data dengan menghapus rekaman secara otomatis setelah waktu yang berlalu, menggunakan pembuatan atau modifikasi rekaman.

    • Misalnya, Azure Cosmos DB menyediakan kemampuan TTL bawaan.

Kecepatan

  • Kecepatan data yang dipancarkan dari berbagai komponen aplikasi, dan persyaratan throughput tentang seberapa cepat data perlu diterapkan dan diambil sangat penting untuk menentukan teknologi data yang optimal untuk skenario beban kerja utama.

    • Sifat persyaratan throughput akan berbeda dengan skenario beban kerja, seperti persyaratan yang baca-berat atau tulis-berat.
      • Misalnya, beban kerja analitis biasanya perlu memenuhi throughput baca yang besar.
    • Apa throughput yang diperlukan? Dan bagaimana throughput diharapkan tumbuh?
    • Apa saja persyaratan latensi data di P50/P99 di bawah tingkat beban referensi?

  • Kemampuan seperti mendukung desain bebas kunci, penyetelan indeks, dan kebijakan konsistensi sangat penting untuk mencapai throughput tinggi.

    • Mengoptimalkan konfigurasi untuk throughput tinggi menimbulkan trade-off, yang harus sepenuhnya dipahami.
    • Persistensi tingkat beban dan pola olahpesan, seperti CQRS dan Event Sourcing, dapat digunakan untuk mengoptimalkan throughput lebih lanjut.

  • Tingkat beban secara alami akan berfluktuasi untuk banyak skenario aplikasi, dengan puncak alami yang membutuhkan tingkat elastisitas yang memadai untuk menangani permintaan variabel sambil mempertahankan throughput dan latensi.

    • Skalabilitas tangkas adalah kunci untuk secara efektif mendukung throughput variabel dan tingkat beban tanpa tingkat kapasitas provisi berlebih.
      • Throughput baca dan tulis harus diskalakan sesuai dengan persyaratan dan beban aplikasi.
      • Operasi skala vertikal dan horizontal dapat diterapkan untuk merespons perubahan tingkat beban.

  • Dampak dips throughput dapat bervariasi berdasarkan skenario beban kerja.

    • Apakah akan ada gangguan konektivitas?
    • Apakah operasi individu akan mengembalikan kode kegagalan saat sarana kontrol terus beroperasi?
    • Apakah platform data akan mengaktifkan pembatasan, dan jika demikian untuk berapa lama?

  • Rekomendasi desain aplikasi mendasar untuk menggunakan distribusi geografis aktif-aktif memperkenalkan tantangan sekeliling konsistensi data.

    • Ada trade-off antara konsistensi dan performa sehubungan dengan semantik transaksional ACID penuh dan perilaku penguncian tradisional.
      • Meminimalkan latensi tulis akan dikenakan biaya konsistensi data.

  • Dalam konfigurasi tulis multi-wilayah, perubahan harus disinkronkan dan digabungkan antara semua replika, dengan resolusi konflik jika diperlukan, dan ini dapat memengaruhi tingkat performa dan skalabilitas.

  • Replika baca-saja (intra-wilayah dan antar-wilayah) dapat digunakan untuk meminimalkan latensi pulang pergi dan mendistribusikan lalu lintas untuk meningkatkan performa, throughput, ketersediaan, dan skalabilitas.

  • Lapisan penembolokan dapat digunakan untuk meningkatkan throughput baca untuk meningkatkan pengalaman pengguna dan waktu respons klien end-to-end.

    • Waktu dan kebijakan kedaluwarsa cache perlu dipertimbangkan untuk mengoptimalkan data terkini.

Berbagai

  • Model data, jenis data, hubungan data, dan model kueri yang dimaksudkan akan sangat memengaruhi keputusan platform data.

    • Apakah aplikasi memerlukan model data relasional atau dapatkah aplikasi mendukung model data variabel atau non-relasional?
    • Bagaimana data kueri aplikasi akan? Dan apakah kueri akan bergantung pada konsep lapisan database seperti gabungan relasional? Atau apakah aplikasi menyediakan semantik seperti itu?

  • Sifat himpunan data yang dipertimbangkan oleh aplikasi dapat bervariasi, dari konten yang tidak terstruktur seperti gambar dan video, atau lebih banyak file terstruktur seperti CSV dan Parquet.

    • Beban kerja aplikasi komposit biasanya akan memiliki himpunan data yang berbeda dan persyaratan terkait.

  • Selain platform data relasional atau non-relasional, platform data grafik atau nilai kunci mungkin juga cocok untuk beban kerja data tertentu.

    • Beberapa teknologi melayani model data skema variabel, di mana item data secara semantik mirip dan/atau disimpan dan dikueri bersama tetapi berbeda secara struktural.

  • Dalam arsitektur layanan mikro, layanan aplikasi individual dapat dibangun dengan penyimpanan data yang dioptimalkan skenario yang berbeda daripada tergantung pada satu datastore monolitik.

    • Pola desain seperti SAGA dapat diterapkan untuk mengelola konsistensi dan dependensi antara penyimpanan data yang berbeda.
      • Kueri langsung antar-database dapat memberlakukan batasan lokasi bersama.
    • Penggunaan beberapa teknologi data akan menambahkan tingkat overhead manajemen untuk mempertahankan teknologi yang mencakup.

  • Set fitur untuk setiap layanan Azure berbeda di seluruh bahasa, SDK, dan API, yang dapat sangat memengaruhi tingkat penyetelan konfigurasi yang dapat diterapkan.

  • Kemampuan untuk penyelarasan yang dioptimalkan dengan model data dan jenis data yang mencakup akan sangat memengaruhi keputusan platform data.

    • Lapisan kueri seperti prosedur tersimpan dan pemeta relasional objek.
    • Kemampuan kueri netral bahasa, seperti lapisan REST API yang aman.
    • Kemampuan kelangsungan bisnis, seperti pencadangan dan pemulihan.

  • Datastore analitis biasanya mendukung penyimpanan poliglot untuk berbagai jenis struktur data.

    • Lingkungan runtime analitis, seperti Apache Spark, mungkin memiliki batasan integrasi untuk menganalisis struktur data poliglot.

  • Dalam konteks perusahaan, penggunaan proses dan perkakas yang ada, dan kelangsungan keterampilan, dapat memiliki bantalan signifikan pada desain platform data dan pemilihan teknologi data.

Kebenaran

  • Beberapa faktor harus dipertimbangkan untuk memvalidasi keakuratan data dalam aplikasi, dan manajemen faktor-faktor ini dapat memiliki bantalan signifikan pada desain platform data.

    • Konsistensi data.
    • Fitur keamanan platform.
    • Tata kelola data.
    • Mengubah manajemen dan evolusi skema.
    • Dependensi antar himpunan data.

  • Dalam aplikasi terdistribusi apa pun dengan beberapa replika data, ada trade-off antara konsistensi dan latensi, seperti yang dinyatakan dalam teorema CAP dan PACELC .

    • Ketika pembaca dan penulis didistribusikan secara jelas, aplikasi harus memilih untuk mengembalikan versi tercepat yang tersedia dari item data, bahkan jika sudah kedaluarsa dibandingkan dengan tulis baru selesai (pembaruan) item data tersebut di replika lain, atau versi terbaru item data, yang dapat menimbulkan latensi tambahan untuk menentukan dan mendapatkan status terbaru.
    • Konsistensi dan ketersediaan dapat dikonfigurasi pada tingkat platform atau pada tingkat permintaan data individual.
    • Apa pengalaman pengguna jika data akan dilayani dari replika yang paling dekat dengan pengguna yang tidak mencerminkan status terbaru dari replika yang berbeda? yaitu dapatkah aplikasi mendukung mungkin melayani data kedaluarsa?

  • Dalam konteks penulisan multi-wilayah, ketika item data yang sama diubah dalam dua replika tulis terpisah sebelum perubahan dapat direplikasi, konflik dibuat yang harus diselesaikan.

    • Kebijakan resolusi konflik standar, seperti "Last Write Wins", atau strategi kustom dengan logika kustom dapat diterapkan.

  • Implementasi persyaratan keamanan dapat berdampak buruk pada throughput atau performa.

  • Enkripsi saat tidak aktif dapat diimplementasikan di lapisan aplikasi menggunakan enkripsi sisi klien dan/atau lapisan data menggunakan enkripsi sisi server jika perlu.

  • Azure mendukung berbagai model enkripsi, termasuk enkripsi sisi server yang menggunakan kunci yang dikelola layanan, kunci yang dikelola pelanggan di Key Vault, atau kunci yang dikelola pelanggan pada perangkat keras yang dikontrol pelanggan.

    • Dengan enkripsi sisi klien, kunci dapat dikelola di Key Vault atau lokasi aman lainnya.

  • Enkripsi tautan data MACsec (IEEE 802.1AE MAC) digunakan untuk mengamankan semua lalu lintas yang berpindah di antara pusat data Azure di jaringan backbone Microsoft.

    • Paket dienkripsi dan didekripsi pada perangkat sebelum dikirim, mencegah serangan fisik 'man-in-the-middle' atau menginjak/menyadap.

  • Autentikasi dan otorisasi ke sarana data dan sarana kontrol.

    • Bagaimana platform data akan mengautentikasi dan mengotorisasi akses aplikasi dan akses operasional?

  • Pengamatan melalui pemantauan kesehatan platform dan akses data.

    • Bagaimana pemberitahuan akan diterapkan untuk kondisi di luar batas operasional yang dapat diterima?

Rekomendasi Desain

Volume

  • Pastikan volume data di masa mendatang yang terkait dengan pertumbuhan organik tidak diharapkan melebihi kemampuan platform data.

    • Memperkirakan tingkat pertumbuhan data yang selaras dengan rencana bisnis dan menggunakan tarif yang ditetapkan untuk menginformasikan persyaratan kapasitas yang sedang berlangsung.
    • Bandingkan volume rekaman agregat dan per data dengan batas platform data.
    • Jika ada risiko batasan yang dicapai dalam keadaan luar biasa, pastikan mitigasi operasional diberlakukan untuk mencegah waktu henti dan kehilangan data.

  • Pantau volume data dan validasi terhadap model kapasitas, pertimbangkan batas skala dan tingkat pertumbuhan data yang diharapkan.

    • Pastikan operasi skala selaras dengan persyaratan penyimpanan, performa, dan konsistensi.
    • Ketika unit skala baru diperkenalkan, data yang mendasar mungkin perlu direplikasi yang akan memakan waktu dan kemungkinan memperkenalkan penalti performa saat replikasi terjadi. Jadi pastikan operasi ini dilakukan di luar jam kerja penting jika memungkinkan.

  • Tentukan tingkat data aplikasi untuk mengklasifikasikan himpunan data berdasarkan penggunaan dan kekritisan untuk memfasilitasi penghapusan atau offload data yang lebih lama.

    • Pertimbangkan untuk mengklasifikasikan himpunan data ke tingkat 'panas', 'hangat', dan 'dingin' ('arsip').
      • Misalnya, implementasi referensi dasar menggunakan Azure Cosmos DB untuk menyimpan data 'panas' yang secara aktif digunakan oleh aplikasi, sementara Azure Storage digunakan untuk data operasi 'dingin' untuk tujuan analitis.

  • Konfigurasikan prosedur housekeeping untuk mengoptimalkan pertumbuhan data dan mendorong efisiensi data, seperti performa kueri, dan mengelola ekspansi data.

    • Mengonfigurasi kedaluwarsa Time-To-Live (TTL) untuk data yang tidak lagi diperlukan dan tidak memiliki nilai analitik jangka panjang.
      • Validasi bahwa data lama dapat dengan aman dijenjangkan ke penyimpanan sekunder, atau dihapus langsung, tanpa dampak buruk pada aplikasi.
    • Offload data non-kritis ke penyimpanan dingin sekunder, tetapi pertahankan untuk nilai analitis dan untuk memenuhi persyaratan audit.
    • Kumpulkan telemetri platform data dan statistik penggunaan untuk memungkinkan tim DevOps terus mengevaluasi persyaratan housekeeping dan datastore 'ukuran yang tepat'.

  • Sejalan dengan desain aplikasi layanan mikro, pertimbangkan penggunaan beberapa teknologi data yang berbeda secara paralel, dengan solusi data yang dioptimalkan untuk skenario beban kerja dan persyaratan volume tertentu.

    • Hindari membuat datastore monolitik tunggal di mana volume data dari ekspansi bisa sulit dikelola.

Kecepatan

  • Platform data secara inheren harus dirancang dan dikonfigurasi untuk mendukung throughput tinggi, dengan beban kerja dipisahkan menjadi konteks yang berbeda untuk memaksimalkan performa menggunakan solusi data yang dioptimalkan skenario.

    • Pastikan throughput baca dan tulis untuk setiap skenario data dapat menskalakan sesuai dengan pola beban yang diharapkan, dengan toleransi yang cukup untuk varians yang tidak terduga.
    • Pisahkan beban kerja data yang berbeda, seperti operasi transaksi dan analitis, ke dalam konteks performa yang berbeda.

  • Tingkat beban melalui penggunaan pesan non-pemblokiran asinkron, misalnya menggunakan pola CQRS atau Event Sourcing .

    • Mungkin ada latensi antara permintaan tulis dan ketika data baru tersedia untuk dibaca, yang mungkin berdampak pada pengalaman pengguna.
      • Dampak ini harus dipahami dan dapat diterima dalam konteks persyaratan bisnis utama.

  • Pastikan skalabilitas tangkas untuk mendukung throughput variabel dan tingkat beban.

    • Jika tingkat beban sangat volatil, pertimbangkan tingkat kapasitas provisi berlebih untuk memastikan throughput dan performa dipertahankan.
    • Uji dan validasi dampak ke beban kerja aplikasi komposit saat throughput tidak dapat dipertahankan.

  • Prioritaskan layanan data asli Azure dengan operasi skala otomatis untuk memfasilitasi respons cepat terhadap volatilitas tingkat beban.

    • Konfigurasikan autoscaling berdasarkan ambang batas service-internal dan application-set.
    • Penskalakan harus dimulai dan diselesaikan dalam jangka waktu yang konsisten dengan persyaratan bisnis.
    • Untuk skenario di mana interaksi manual diperlukan, tetapkan 'playbook' operasional otomatis yang dapat dipicu daripada melakukan tindakan operasional manual.
      • Pertimbangkan apakah pemicu otomatis dapat diterapkan sebagai bagian dari investasi rekayasa berikutnya.

  • Pantau throughput baca dan tulis data aplikasi terhadap persyaratan latensi P50/P99 dan selaras dengan model kapasitas aplikasi.

  • Throughput berlebih harus ditangani dengan baik oleh platform data atau lapisan aplikasi dan ditangkap oleh model kesehatan untuk representasi operasional.

  • Terapkan penembolokan untuk skenario data 'panas' untuk meminimalkan waktu respons.

    • Terapkan kebijakan yang sesuai untuk kedaluwarsa cache dan penyimpanan rumah untuk menghindari pertumbuhan data yang melarikan diri.
      • Kedaluwarsa item cache saat data pendukung berubah.
      • Jika kedaluwarsa cache benar-benar berbasis Time-To-Live (TTL), dampak dan pengalaman pelanggan dalam menyajikan data yang sudah kedaluwarsa perlu dipahami.

Berbagai

  • Selaras dengan prinsip desain cloud dan Azure-native, sangat disarankan untuk memprioritaskan layanan Azure terkelola untuk mengurangi kompleksitas operasional dan manajemen, dan memanfaatkan investasi platform Microsoft di masa depan.

  • Selaras dengan prinsip desain aplikasi arsitektur layanan mikro yang digabungkan secara longgar, memungkinkan layanan individual untuk menggunakan penyimpanan data yang berbeda dan teknologi data yang dioptimalkan skenario.

    • Identifikasi jenis struktur data yang akan ditangani aplikasi untuk skenario beban kerja tertentu.
    • Hindari membuat dependensi pada satu datastore monolitik.
      • Pertimbangkan pola desain SAGA di mana dependensi antar penyimpanan data ada.

  • Validasi bahwa kemampuan yang diperlukan tersedia untuk teknologi data yang dipilih.

    • Pastikan dukungan untuk bahasa dan kemampuan SDK yang diperlukan. Tidak setiap kemampuan tersedia untuk setiap bahasa/SDK dengan cara yang sama.

Kebenaran

  • Mengadopsi desain platform data multi-wilayah dan mendistribusikan replika di seluruh wilayah untuk keandalan, ketersediaan, dan performa maksimum dengan memindahkan data lebih dekat ke titik akhir aplikasi.

    • Distribusikan replika data di seluruh Zona Ketersediaan (AZ) dalam suatu wilayah (atau gunakan tingkat layanan zona redundan) untuk memaksimalkan ketersediaan intra-wilayah.

  • Jika persyaratan konsistensi memungkinkannya, gunakan desain platform data tulis multi-wilayah untuk memaksimalkan ketersediaan dan keandalan global secara keseluruhan.

    • Pertimbangkan persyaratan bisnis untuk resolusi konflik ketika item data yang sama diubah dalam dua replika tulis terpisah sebelum perubahan dapat direplikasi dan dengan demikian menciptakan konflik.
      • Gunakan kebijakan penyelesaian konflik standar seperti "Terakhir menang" jika memungkinkan
        • Jika strategi kustom dengan logika kustom diperlukan, pastikan praktik CI/CD DevOps diterapkan untuk mengelola logika kustom.

  • Uji dan validasi kemampuan pencadangan dan pemulihan, serta operasi failover melalui pengujian chaos dalam proses pengiriman berkelanjutan.

  • Jalankan tolok ukur performa untuk memastikan persyaratan throughput dan performa tidak terpengaruh oleh dimasukkannya kemampuan keamanan yang diperlukan, seperti enkripsi.

    • Pastikan proses pengiriman berkelanjutan mempertimbangkan pengujian beban terhadap tolok ukur performa yang diketahui.

  • Saat menerapkan enkripsi, sangat disarankan untuk menggunakan kunci enkripsi yang dikelola layanan sebagai cara mengurangi kompleksitas manajemen.

    • Jika ada persyaratan keamanan khusus untuk kunci yang dikelola pelanggan, pastikan prosedur manajemen kunci yang sesuai diterapkan untuk memastikan ketersediaan, pencadangan, dan rotasi semua kunci yang dipertimbangkan.

Catatan

Saat berintegrasi dengan implementasi organisasi yang lebih luas, sangat penting bahwa pendekatan sentris aplikasi diterapkan untuk provisi dan pengoperasian komponen platform data dalam desain aplikasi.

Lebih khusus lagi, untuk memaksimalkan keandalan sangat penting bahwa masing-masing komponen platform data merespons kesehatan aplikasi dengan tepat melalui tindakan operasional yang mungkin mencakup komponen aplikasi lainnya. Misalnya, dalam skenario di mana sumber daya platform data tambahan diperlukan, penskalaan platform data bersama dengan komponen aplikasi lain sesuai dengan model kapasitas kemungkinan akan diperlukan, berpotensi melalui penyediaan unit skala tambahan. Pendekatan ini pada akhirnya akan dibatasi jika ada dependensi keras dari tim operasi terpusat untuk mengatasi masalah yang terkait dengan platform data dalam isolasi.

Pada akhirnya, penggunaan layanan data terpusat (yaitu CENTRAL IT DBaaS) memperkenalkan hambatan operasional yang secara signifikan menghambat kelincahan melalui pengalaman manajemen yang sebagian besar tidak kontekstual, dan harus dihindari dalam konteks misi penting atau kritis bisnis.

Referensi tambahan

Panduan platform data tambahan tersedia dalam Panduan Arsitektur Aplikasi Azure.

Datastore tulis multi-wilayah yang didistribusikan secara global

Untuk sepenuhnya mengakomodasi aspirasi aktif-aktif yang didistribusikan secara global dari desain aplikasi, sangat disarankan untuk mempertimbangkan platform data tulis multi-wilayah terdistribusi, di mana perubahan pada replika yang dapat ditulis terpisah disinkronkan dan digabungkan antara semua replika, dengan resolusi konflik jika diperlukan.

Penting

Layanan mikro mungkin tidak semua memerlukan datastore tulis multi-wilayah terdistribusi, jadi pertimbangan harus diberikan kepada konteks arsitektur dan persyaratan bisnis dari setiap skenario beban kerja.

Azure Cosmos DB menyediakan penyimpanan data NoSQL yang didistribusikan secara global dan sangat tersedia, menawarkan penulisan multi-wilayah dan konsistensi yang dapat disetel di luar kotak. Oleh karena itu, pertimbangan desain dan rekomendasi dalam bagian ini akan berfokus pada penggunaan Azure Cosmos DB yang optimal.

Mempertimbangkan rancangan

Azure Cosmos DB

  • Azure Cosmos DB menyimpan data dalam Kontainer, yang diindeks, penyimpanan transaksional berbasis baris yang dirancang untuk memungkinkan pembacaan dan penulisan transaksional yang cepat dengan waktu respons pada urutan milidetik.

  • Azure Cosmos DB mendukung beberapa API berbeda dengan set fitur yang berbeda, seperti SQL, Cassandra, dan MongoDB.

    • Azure Cosmos DB untuk NoSQL pihak pertama menyediakan set fitur terkaya dan biasanya merupakan API tempat kemampuan baru akan tersedia terlebih dahulu.

  • Azure Cosmos DB mendukung mode konektivitas Gateway dan Direct, di mana Direct memfasilitasi konektivitas melalui TCP untuk backend node replika Azure Cosmos DB untuk meningkatkan performa dengan lebih sedikit hop jaringan, sementara Gateway menyediakan konektivitas HTTPS ke node gateway frontend.

    • Mode langsung hanya tersedia saat menggunakan Azure Cosmos DB untuk NoSQL dan saat ini hanya didukung pada platform .NET dan Java SDK.

  • Dalam wilayah yang diaktifkan Zona Ketersediaan, Azure Cosmos DB menawarkan dukungan redundansi Zona Ketersediaan (AZ) untuk ketersediaan tinggi dan ketahanan terhadap kegagalan zonal dalam suatu wilayah.

  • Azure Cosmos DB mempertahankan empat replika data dalam satu wilayah, dan ketika redundansi Zona Ketersediaan (AZ) diaktifkan, Azure Cosmos DB memastikan replika data ditempatkan di beberapa AZ untuk melindungi dari kegagalan zonal.

    • Protokol konsekuensi Paxos diterapkan untuk mencapai kuorum di seluruh replika dalam suatu wilayah.

  • Akun Azure Cosmos DB dapat dengan mudah dikonfigurasi untuk mereplikasi data di beberapa wilayah untuk mengurangi risiko satu wilayah menjadi tidak tersedia.

    • Replikasi dapat dikonfigurasi dengan penulisan wilayah tunggal atau penulisan multi-wilayah.
      • Dengan penulisan wilayah tunggal, wilayah 'hub' utama digunakan untuk melayani semua penulisan dan jika wilayah 'hub' ini menjadi tidak tersedia, operasi failover harus terjadi untuk mempromosikan wilayah lain sebagai dapat ditulis.
      • Dengan penulisan multi-wilayah, aplikasi dapat menulis ke wilayah penyebaran yang dikonfigurasi, yang akan mereplikasi perubahan antara semua wilayah lain. Jika suatu wilayah tidak tersedia, maka wilayah yang tersisa akan digunakan untuk melayani lalu lintas tulis.

  • Dalam konfigurasi tulis multi-wilayah, konflik pembaruan (sisipkan, ganti, hapus) dapat terjadi di mana penulis memperbarui item yang sama secara bersamaan di beberapa wilayah.

  • Azure Cosmos DB menyediakan dua kebijakan penyelesaian konflik, yang dapat diterapkan untuk mengatasi konflik secara otomatis.

    • Last Write Wins (LWW) menerapkan protokol jam sinkronisasi waktu menggunakan properti tanda _ts waktu yang ditentukan sistem sebagai jalur resolusi konflik. Jika dari konflik item dengan nilai tertinggi untuk jalur resolusi konflik menjadi pemenang, dan jika beberapa item memiliki nilai numerik yang sama maka sistem memilih pemenang sehingga semua wilayah dapat bertemu dengan versi yang sama dari item yang diterapkan.
      • Dengan konflik penghapusan, versi yang dihapus selalu menang atas konflik sisipan atau penggantian terlepas dari nilai jalur resolusi konflik.
      • Last Write Wins adalah kebijakan resolusi konflik default.
      • Saat menggunakan Azure Cosmos DB untuk NoSQL, properti numerik kustom seperti definisi tanda waktu kustom dapat digunakan untuk resolusi konflik.
    • Kebijakan resolusi kustom memungkinkan semantik yang ditentukan aplikasi untuk mendamaikan konflik menggunakan prosedur tersimpan gabungan terdaftar yang secara otomatis dipanggil ketika konflik terdeteksi.
      • Sistem menyediakan hanya satu jaminan untuk pelaksanaan prosedur penggabungan sebagai bagian dari protokol komitmen.
      • Kebijakan resolusi konflik kustom hanya tersedia dengan Azure Cosmos DB untuk NoSQL dan hanya dapat diatur pada waktu pembuatan kontainer.

  • Dalam konfigurasi penulisan multi-wilayah, ada dependensi pada satu wilayah 'hub' Azure Cosmos DB untuk melakukan semua resolusi konflik, dengan protokol konsekuensi Paxos diterapkan untuk mencapai kuorum di seluruh replika dalam wilayah hub.

    • Platform ini menyediakan buffer pesan untuk konflik tulis dalam wilayah hub untuk memuat tingkat dan memberikan redundansi untuk kesalahan sementara.
      • Buffer mampu menyimpan pembaruan tulis bernilai beberapa menit yang membutuhkan konensus.

Arah strategis platform Azure Cosmos DB adalah menghapus dependensi wilayah tunggal ini untuk resolusi konflik dalam konfigurasi tulis multi-wilayah, menggunakan pendekatan Paxos 2 fase untuk mencapai kuorum pada tingkat global dan dalam suatu wilayah.

  • Wilayah 'hub' utama ditentukan oleh wilayah pertama tempat Azure Cosmos DB dikonfigurasi.

    • Urutan prioritas dikonfigurasi untuk wilayah penyebaran satelit tambahan untuk tujuan failover.

  • Model data dan partisi di seluruh partisi logis dan fisik memainkan peran penting dalam mencapai performa dan ketersediaan yang optimal.

  • Saat disebarkan dengan satu wilayah tulis, Azure Cosmos DB dapat dikonfigurasi untuk failover otomatis berdasarkan prioritas failover yang ditentukan dengan mempertimbangkan semua replika wilayah baca.

  • RTO yang disediakan oleh platform Azure Cosmos DB adalah ~ 10-15 menit, menangkap waktu yang berlalu untuk melakukan failover regional layanan Azure Cosmos DB jika bencana besar yang berdampak pada wilayah hub.

    • RTO ini juga relevan dalam konteks penulisan multi-wilayah mengingat dependensi pada satu wilayah 'hub' untuk resolusi konflik.
      • Jika wilayah 'hub' menjadi tidak tersedia, penulisan yang dibuat ke wilayah lain akan gagal setelah buffer pesan terisi karena resolusi konflik tidak akan dapat terjadi sampai layanan gagal dan wilayah hub baru dibuat.

Arah strategis platform Azure Cosmos DB adalah mengurangi RTO menjadi ~5 menit dengan memungkinkan failover tingkat partisi.

  • Tujuan Titik Pemulihan (RPO) dan Tujuan Waktu Pemulihan (RTO) dapat dikonfigurasi melalui tingkat konsistensi, dengan trade-off antara durabilitas data dan throughput.

    • Azure Cosmos DB menyediakan RTO minimum 0 untuk tingkat konsistensi yang dilonggarkan dengan penulisan multi-wilayah atau RPO 0 untuk konsistensi yang kuat dengan wilayah tulis tunggal.

  • Azure Cosmos DB menawarkan SLA 99,999% untuk ketersediaan baca dan tulis untuk Akun Database yang dikonfigurasi dengan beberapa wilayah Azure sebagai dapat ditulis.

    • SLA diwakili oleh Persentase Waktu Aktif Bulanan, yang dihitung sebagai 100% - Tingkat Kesalahan Rata-Rata.
    • Tingkat Kesalahan Rata-Rata didefinisikan sebagai jumlah Tingkat Kesalahan untuk setiap jam dalam bulan penagihan dibagi dengan jumlah total jam dalam bulan penagihan, di mana Tingkat Kesalahan adalah jumlah total Permintaan Gagal dibagi dengan Total Permintaan selama interval satu jam tertentu.

  • Azure Cosmos DB menawarkan SLA 99,99% untuk throughput, konsistensi, ketersediaan, dan latensi untuk Akun Database yang dilingkup ke satu wilayah Azure saat dikonfigurasi dengan salah satu dari lima Tingkat Konsistensi.

    • SLA 99,99% juga berlaku untuk Akun Database yang mencakup beberapa wilayah Azure yang dikonfigurasi dengan salah satu dari empat Tingkat Konsistensi yang dilonggarkan.

  • Ada dua jenis throughput yang dapat disediakan di Azure Cosmos DB, standar dan skala otomatis, yang diukur menggunakan Unit Permintaan per detik (RU/dtk).

    • Throughput standar mengalokasikan sumber daya yang diperlukan untuk menjamin nilai RU/dtk tertentu.
      • Standar ditagih per jam untuk throughput yang disediakan.
    • Skala otomatis menentukan nilai throughput maksimum, dan Azure Cosmos DB akan secara otomatis meningkatkan atau menurunkan skala tergantung pada beban aplikasi, antara nilai throughput maksimum dan minimal 10% dari nilai throughput maksimum.
      • Skala otomatis ditagih per jam untuk throughput maksimum yang digunakan.

  • Throughput yang disediakan statis dengan beban kerja variabel dapat mengakibatkan kesalahan pembatasan, yang akan berdampak pada ketersediaan aplikasi yang dirasakan.

    • Skala otomatis melindungi dari kesalahan pembatasan dengan memungkinkan Azure Cosmos DB untuk meningkatkan skala sesuai kebutuhan, sambil mempertahankan perlindungan biaya dengan menurunkan skala kembali saat beban menurun.

  • Saat Azure Cosmos DB direplikasi di beberapa wilayah, Unit Permintaan (RU) yang disediakan akan ditagih per wilayah.

  • Ada delta biaya yang signifikan antara konfigurasi penulisan multi-wilayah dan penulisan wilayah tunggal yang dalam banyak kasus dapat membuat biaya platform data Azure Cosmos DB multi-master melarang.

Baca/Tulis Wilayah Tunggal Penulisan Wilayah Tunggal - Baca Wilayah Ganda Baca/Tulis Wilayah Ganda
1 RU 2 RU 4 RU

Delta antara penulisan wilayah tunggal dan multi-wilayah-tulis sebenarnya kurang dari rasio 1:2 yang tercermin dalam tabel di atas. Lebih khusus lagi, ada biaya transfer data lintas wilayah yang terkait dengan pembaruan tulis dalam konfigurasi penulisan tunggal, yang tidak ditangkap dalam biaya RU seperti halnya konfigurasi tulis multi-wilayah.

  • Penyimpanan yang digunakan ditagih sebagai tarif tetap untuk jumlah total penyimpanan (GB) yang digunakan untuk menghosting data dan indeks selama jam tertentu.

  • Session adalah tingkat konsistensi default dan paling banyak digunakan karena data diterima dalam urutan yang sama dengan penulisan.

  • Azure Cosmos DB mendukung autentikasi melalui identitas Microsoft Entra atau kunci Azure Cosmos DB dan token sumber daya, yang menyediakan kemampuan yang tumpang tindih.

Kemampuan Akses Azure Cosmos DB Kemampuan

  • Dimungkinkan untuk menonaktifkan operasi manajemen sumber daya menggunakan kunci atau token sumber daya untuk membatasi kunci dan token sumber daya hanya untuk operasi data, memungkinkan kontrol akses sumber daya terperinci menggunakan kontrol akses berbasis peran (RBAC) Microsoft Entra.

    • Membatasi akses sarana kontrol melalui kunci atau token sumber daya akan menonaktifkan operasi sarana kontrol untuk klien menggunakan SDK Azure Cosmos DB dan oleh karena itu harus dievaluasi dan diuji secara menyeluruh.
    • Pengaturan disableKeyBasedMetadataWriteAccess dapat dikonfigurasi melalui definisi IaC Templat ARM, atau melalui Azure Policy Bawaan.

  • Microsoft Entra dukungan RBAC di Azure Cosmos DB berlaku untuk operasi manajemen sarana kontrol akun dan sumber daya.

    • Administrator aplikasi dapat membuat penetapan peran untuk pengguna, grup, perwakilan layanan, atau identitas terkelola untuk memberikan atau menolak akses ke sumber daya dan operasi pada sumber daya Azure Cosmos DB.
    • Ada beberapa Peran RBAC Bawaan yang tersedia untuk penetapan peran, dan peran RBAC kustom juga dapat digunakan untuk membentuk kombinasi hak istimewa tertentu.
      • Pembaca Akun Cosmos DB memungkinkan akses baca-saja ke sumber daya Azure Cosmos DB.
      • Kontributor Akun DocumentDB memungkinkan manajemen akun Azure Cosmos DB termasuk kunci dan penetapan peran, tetapi tidak mengaktifkan akses bidang data.
      • Operator Cosmos DB, yang mirip dengan Kontributor Akun DocumentDB, tetapi tidak menyediakan kemampuan untuk mengelola kunci atau penetapan peran.

  • Sumber daya Azure Cosmos DB (akun, database, dan kontainer) dapat dilindungi dari modifikasi atau penghapusan yang salah menggunakan Kunci Sumber Daya.

    • Kunci Sumber Daya dapat diatur di tingkat akun, database, atau kontainer.
    • Kunci Sumber Daya yang diatur pada sumber daya akan diwariskan oleh semua sumber daya anak. Misalnya, Kunci Sumber Daya yang diatur pada akun Azure Cosmos DB akan diwariskan oleh semua database dan kontainer dalam akun.
    • Kunci Sumber Daya hanya berlaku untuk operasi sarana kontrol dan tidak mencegah operasi sarana data, seperti membuat, mengubah, atau menghapus data.
    • Jika akses sarana kontrol tidak dibatasi dengan disableKeyBasedMetadataWriteAccess, maka klien akan dapat melakukan operasi sarana kontrol menggunakan kunci akun.

  • Umpan perubahan Azure Cosmos DB menyediakan umpan perubahan yang diurutkan waktu pada data dalam kontainer Azure Cosmos DB.

    • Umpan perubahan hanya mencakup operasi sisipkan dan perbarui ke kontainer Azure Cosmos DB sumber; ini tidak termasuk penghapusan.

  • Umpan perubahan dapat digunakan untuk mempertahankan penyimpanan data terpisah dari Kontainer utama yang digunakan oleh aplikasi, dengan pembaruan berkelanjutan ke penyimpanan data target yang disalurkan oleh umpan perubahan dari Kontainer sumber.

    • Umpan perubahan dapat digunakan untuk mengisi penyimpanan sekunder untuk redundansi platform data tambahan atau untuk skenario analitik berikutnya.

  • Jika operasi penghapusan secara rutin memengaruhi data dalam Kontainer sumber, maka penyimpanan yang diumpankan oleh umpan perubahan akan tidak akurat dan tidak fleksibel dari data yang dihapus.

    • Pola Penghapusan Sementara dapat diimplementasikan sehingga rekaman data disertakan dalam umpan perubahan.
      • Alih-alih menghapus rekaman data secara eksplisit, rekaman data diperbarui dengan mengatur bendera (misalnya IsDeleted) untuk menunjukkan bahwa item dianggap dihapus.
      • Setiap penyimpanan data target yang diumpankan oleh umpan perubahan harus mendeteksi dan memproses item dengan bendera yang dihapus diatur ke True; alih-alih menyimpan rekaman data yang dihapus sementara, versi rekaman data yang ada di penyimpanan target harus dihapus.
    • Time-To-Live (TTL) singkat biasanya digunakan dengan pola penghapusan sementara sehingga Azure Cosmos DB secara otomatis menghapus data yang kedaluwarsa, tetapi hanya setelah tercermin dalam umpan perubahan dengan bendera yang dihapus diatur ke True.
      • Menyelesaikan niat penghapusan asli sementara juga menyebarkan penghapusan melalui umpan perubahan.

  • Azure Cosmos DB dapat dikonfigurasi sebagai penyimpanan analitik, yang menerapkan format kolom untuk kueri analitik yang dioptimalkan untuk mengatasi tantangan kompleksitas dan latensi yang terjadi dengan alur ETL tradisional.

  • Azure Cosmos DB secara otomatis mencadangkan data secara berkala tanpa memengaruhi performa atau ketersediaan, dan tanpa menggunakan RU/dtk.

  • Azure Cosmos DB dapat dikonfigurasi sesuai dengan dua mode pencadangan yang berbeda.

    • Berkala adalah mode pencadangan default untuk semua akun, di mana cadangan diambil pada interval berkala dan data dipulihkan dengan membuat permintaan dengan tim dukungan.
      • Periode retensi cadangan berkala default adalah delapan jam dan interval pencadangan default adalah empat jam, yang berarti hanya dua cadangan terbaru yang disimpan secara default.
      • Interval cadangan dan periode retensi dapat dikonfigurasi dalam akun.
        • Periode retensi maksimum diperpanjang hingga sebulan dengan interval pencadangan minimum satu jam.
        • Penetapan peran ke Azure "Peran Pembaca Akun Cosmos DB" diperlukan untuk mengonfigurasi redundansi penyimpanan cadangan.
      • Dua salinan cadangan disertakan tanpa biaya tambahan, tetapi cadangan tambahan dikenakan biaya tambahan.
      • Secara default, cadangan berkala disimpan dalam Geo-Redundant Storage (GRS) terpisah yang tidak dapat diakses secara langsung.
      • Melakukan operasi pemulihan memerlukan Permintaan Dukungan karena pelanggan tidak dapat langsung melakukan pemulihan.
        • Sebelum membuka tiket dukungan, periode retensi cadangan harus ditingkatkan menjadi setidaknya tujuh hari dalam waktu delapan jam setelah peristiwa kehilangan data.
      • Operasi pemulihan membuat akun Azure Cosmos DB baru tempat data dipulihkan.
        • Akun Azure Cosmos DB yang ada tidak dapat digunakan untuk Pemulihan
        • Secara default, akun Azure Cosmos DB baru bernama <Azure_Cosmos_account_original_name>-restored<n> akan digunakan.
          • Nama ini dapat disesuaikan, seperti dengan menggunakan kembali nama yang ada jika akun asli dihapus.
      • Jika throughput disediakan di tingkat database, pencadangan dan pemulihan akan terjadi di tingkat database
        • Tidak dimungkinkan untuk memilih subset kontainer untuk dipulihkan.
    • Mode pencadangan berkelanjutan memungkinkan pemulihan ke titik waktu mana pun dalam 30 hari terakhir.
      • Operasi pemulihan dapat dilakukan untuk kembali ke titik waktu tertentu (PITR) dengan granularitas satu detik.
      • Jendela yang tersedia untuk operasi pemulihan hingga 30 hari.
        • Dimungkinkan juga untuk memulihkan ke status instansiasi sumber daya.
      • Pencadangan berkelanjutan diambil di setiap wilayah Azure tempat akun Azure Cosmos DB berada.
        • Pencadangan berkelanjutan disimpan dalam wilayah Azure yang sama dengan setiap replika Azure Cosmos DB, menggunakan Locally-Redundant Storage (LRS) atau Zone Redundant Storage (ZRS) dalam wilayah yang mendukung Zona Ketersediaan.
      • Pemulihan layanan mandiri dapat dilakukan menggunakan artefak portal Azure atau IaC seperti templat ARM.
      • Ada beberapa batasan dengan Pencadangan Berkelanjutan.
        • Mode pencadangan berkelanjutan saat ini tidak tersedia dalam konfigurasi penulisan multi-wilayah.
        • Hanya Azure Cosmos DB untuk NoSQL dan Azure Cosmos DB for MongoDB yang dapat dikonfigurasi untuk Pencadangan berkelanjutan saat ini.
        • Jika kontainer memiliki TTL yang dikonfigurasi, data yang dipulihkan yang telah melebihi TTL-nya dapat segera dihapus
      • Operasi pemulihan membuat akun Azure Cosmos DB baru untuk pemulihan titik waktu.
      • Ada biaya penyimpanan tambahan untuk operasi pencadangan dan pemulihan berkelanjutan.

  • Akun Azure Cosmos DB yang ada dapat dimigrasikan dari Periodik ke Berkelanjutan, tetapi tidak dari Berkelanjutan ke Berkala; migrasi adalah satu arah dan tidak dapat dibalik.

  • Setiap cadangan Azure Cosmos DB terdiri dari data itu sendiri dan detail konfigurasi untuk throughput yang disediakan, kebijakan pengindeksan, wilayah penyebaran, dan pengaturan TTL kontainer.

  • Dimungkinkan untuk menerapkan kemampuan pencadangan dan pemulihan kustom untuk skenario di mana pendekatan Periodik dan Berkelanjutan tidak cocok.

    • Pendekatan kustom memperkenalkan biaya yang signifikan dan overhead administratif tambahan, yang harus dipahami dan dinilai dengan hati-hati.
      • Skenario pemulihan umum harus dimodelkan, seperti kerusakan atau penghapusan akun, database, kontainer, pada item data.
      • Prosedur pembenahan harus dilaksanakan untuk mencegah penyebaran cadangan.
    • Azure Storage atau teknologi data alternatif dapat digunakan, seperti kontainer Azure Cosmos DB alternatif.
      • Azure Storage dan Azure Cosmos DB menyediakan integrasi asli dengan layanan Azure seperti Azure Functions dan Azure Data Factory.

  • Dokumentasi Azure Cosmos DB menunjukkan dua opsi potensial untuk menerapkan pencadangan kustom.

    • Umpan perubahan Azure Cosmos DB untuk menulis data ke fasilitas penyimpanan terpisah.
    • Pencadangan kustom berkelanjutan atau berkala (batch) dapat diimplementasikan menggunakan umpan perubahan.
    • Umpan perubahan Azure Cosmos DB belum mencerminkan penghapusan, sehingga pola penghapusan sementara harus diterapkan menggunakan properti boolean dan TTL.
      • Pola ini tidak akan diperlukan ketika umpan perubahan menyediakan pembaruan keakuratan penuh.
    • Azure Data Factory Connector untuk Azure Cosmos DB (konektor Azure Cosmos DB for NoSQL atau MongoDB API) untuk menyalin data.
      • Azure Data Factory (ADF) mendukung eksekusi manual dan Jadwalkan, jendela Tumbling, dan pemicu berbasis Peristiwa.
        • Menyediakan dukungan untuk Storage dan Event Grid.
      • ADF terutama cocok untuk implementasi pencadangan kustom berkala karena orkestrasi berorientasi batch.
        • Ini kurang cocok untuk implementasi pencadangan berkelanjutan dengan peristiwa yang sering karena overhead eksekusi orkestrasi.
      • ADF mendukung Azure Private Link untuk skenario keamanan jaringan tinggi

Azure Cosmos DB digunakan dalam desain banyak layanan Azure, sehingga pemadaman regional yang signifikan untuk Azure Cosmos DB akan memiliki efek bertingkat di berbagai layanan Azure dalam wilayah tersebut. Dampak yang tepat terhadap layanan tertentu akan sangat bergantung pada bagaimana desain layanan yang mendasar menggunakan Azure Cosmos DB.

Rekomendasi Desain

Azure Cosmos DB

  • Gunakan Azure Cosmos DB sebagai platform data utama di mana persyaratan memungkinkan.

  • Untuk skenario beban kerja yang sangat penting, konfigurasikan Azure Cosmos DB dengan replika tulis di dalam setiap wilayah penyebaran untuk mengurangi latensi dan memberikan redundansi maksimum.

    • Konfigurasikan aplikasi untuk memprioritaskan penggunaan replika Azure Cosmos DB lokal untuk menulis dan membaca untuk mengoptimalkan beban aplikasi, performa, dan konsumsi RU/dtk regional.
    • Konfigurasi penulisan multi-wilayah dikenakan biaya yang signifikan dan harus diprioritaskan hanya untuk skenario beban kerja yang membutuhkan keandalan maksimum.

  • Untuk skenario beban kerja yang kurang penting, prioritaskan penggunaan konfigurasi penulisan wilayah tunggal (saat menggunakan Zona Ketersediaan) dengan replika baca yang didistribusikan secara global, karena ini menawarkan tingkat keandalan platform data yang tinggi (99,999% SLA untuk SLA baca, 99,995% untuk operasi tulis) pada titik harga yang lebih menarik.

    • Konfigurasikan aplikasi untuk menggunakan replika baca Azure Cosmos DB lokal untuk mengoptimalkan performa baca.

  • Pilih wilayah penyebaran 'hub' yang optimal di mana resolusi konflik akan terjadi dalam konfigurasi penulisan multi-wilayah, dan semua penulisan akan dilakukan dalam konfigurasi penulisan wilayah tunggal.

    • Pertimbangkan jarak relatif terhadap wilayah penyebaran lain dan latensi terkait dalam memilih wilayah utama, dan kemampuan yang diperlukan seperti dukungan Zona Ketersediaan.

  • Konfigurasikan Azure Cosmos DB dengan redundansi Zona Ketersediaan (AZ) di semua wilayah penyebaran dengan dukungan AZ, untuk memastikan ketahanan terhadap kegagalan zonal dalam suatu wilayah.

  • Gunakan Azure Cosmos DB untuk NoSQL karena menawarkan set fitur yang paling komprehensif, terutama di mana penyetelan performa menjadi perhatian.

    • API alternatif terutama harus dipertimbangkan untuk skenario migrasi atau kompatibilitas.
      • Saat menggunakan API alternatif, validasi bahwa kemampuan yang diperlukan tersedia dengan bahasa dan SDK yang dipilih untuk memastikan konfigurasi dan performa yang optimal.

  • Gunakan mode koneksi Langsung untuk mengoptimalkan performa jaringan melalui konektivitas TCP langsung ke node Azure Cosmos DB backend, dengan jumlah 'hop' jaringan yang berkurang.

Azure Cosmos DB SLA dihitung dengan rata-rata permintaan yang gagal, yang mungkin tidak secara langsung selaras dengan anggaran kesalahan tingkat keandalan 99,999%. Saat merancang untuk SLO 99,999%, sangat penting untuk merencanakan tidak tersedianya penulisan Azure Cosmos DB regional dan multi-wilayah, memastikan teknologi penyimpanan fallback diposisikan jika kegagalan, seperti antrean pesan yang bertahan untuk pemutaran ulang berikutnya.

  • Tentukan strategi partisi di seluruh partisi logis dan fisik untuk mengoptimalkan distribusi data sesuai dengan model data.

    • Meminimalkan kueri lintas partisi.
    • Uji dan validasi strategi partisi secara berulang untuk memastikan performa yang optimal.

  • Pilih kunci partisi yang optimal.

    • Kunci partisi tidak dapat diubah setelah dibuat dalam koleksi.
    • Kunci partisi harus berupa nilai properti yang tidak berubah.
    • Pilih kunci partisi yang memiliki kardinalitas tinggi, dengan berbagai nilai yang mungkin.
    • Kunci partisi harus menyebarkan konsumsi RU dan penyimpanan data secara merata di semua partisi logis untuk memastikan bahkan konsumsi RU dan distribusi penyimpanan di seluruh partisi fisik.
    • Jalankan kueri baca terhadap kolom yang dipartisi untuk mengurangi konsumsi dan latensi RU.

  • Pengindeksan juga penting untuk performa, jadi pastikan pengecualian indeks digunakan untuk mengurangi RU/dtk dan persyaratan penyimpanan.

    • Hanya indeks bidang yang diperlukan untuk pemfilteran dalam kueri; indeks desain untuk predikat yang paling banyak digunakan.

  • Manfaatkan kemampuan penanganan kesalahan bawaan, coba lagi, dan keandalan yang lebih luas dari Azure Cosmos DB SDK.

  • Gunakan kunci enkripsi yang dikelola layanan untuk mengurangi kompleksitas manajemen.

    • Jika ada persyaratan keamanan khusus untuk kunci yang dikelola pelanggan, pastikan prosedur manajemen kunci yang sesuai diterapkan, seperti pencadangan dan rotasi.

  • Nonaktifkan akses tulis metadata berbasis kunci Azure Cosmos DB dengan menerapkan Azure Policy bawaan.

  • Aktifkan Azure Monitor untuk mengumpulkan metrik utama dan log diagnostik, seperti throughput yang disediakan (RU/dtk).

    • Rutekan data operasional Azure Monitor ke ruang kerja Analitik Log yang didedikasikan untuk Azure Cosmos DB dan sumber daya global lainnya dalam desain aplikasi.
    • Gunakan metrik Azure Monitor untuk menentukan apakah pola lalu lintas aplikasi cocok untuk skala otomatis.

  • Evaluasi pola lalu lintas aplikasi untuk memilih opsi optimal untuk jenis throughput yang disediakan.

    • Pertimbangkan throughput yang disediakan secara otomatis untuk meningkatkan permintaan beban kerja secara otomatis.

  • Evaluasi tips performa Microsoft untuk Azure Cosmos DB untuk mengoptimalkan konfigurasi sisi klien dan sisi server untuk meningkatkan latensi dan throughput.

  • Saat menggunakan AKS sebagai platform komputasi: Untuk beban kerja intensif kueri, pilih SKU simpul AKS yang telah mempercepat jaringan yang diaktifkan untuk mengurangi latensi dan jitter CPU.

  • Untuk penyebaran wilayah tulis tunggal, sangat disarankan untuk mengonfigurasi Azure Cosmos DB untuk failover otomatis.

  • Tingkat beban melalui penggunaan olahpesan non-pemblokiran asinkron dalam alur sistem, yang menulis pembaruan ke Azure Cosmos DB.

  • Konfigurasikan akun Azure Cosmos DB untuk pencadangan berkelanjutan untuk mendapatkan granularitas titik pemulihan yang baik selama 30 hari terakhir.

    • Pertimbangkan penggunaan cadangan Azure Cosmos DB dalam skenario di mana data yang terkandung atau akun Azure Cosmos DB dihapus atau rusak.
    • Hindari penggunaan pendekatan pencadangan kustom kecuali benar-benar diperlukan.

  • Sangat disarankan untuk mempraktikkan prosedur pemulihan pada sumber daya dan data non-produksi, sebagai bagian dari persiapan operasi kelangsungan bisnis standar.

  • Tentukan artefak IaC untuk membangun kembali pengaturan konfigurasi dan kemampuan pemulihan cadangan Azure Cosmos DB.

  • Evaluasi dan terapkan panduan kontrol Garis Besar Keamanan Azure untuk Pencadangan dan Pemulihan Azure Cosmos DB.

  • Untuk beban kerja analitis yang memerlukan ketersediaan multi-wilayah, gunakan Azure Cosmos DB Analytical Store, yang menerapkan format kolom untuk kueri analitik yang dioptimalkan.

Teknologi data relasional

Untuk skenario dengan model data yang sangat relasional atau dependensi pada teknologi relasional yang ada, penggunaan Azure Cosmos DB dalam konfigurasi tulis multi-wilayah mungkin tidak berlaku secara langsung. Dalam kasus seperti itu, sangat penting bahwa teknologi relasional yang digunakan dirancang dan dikonfigurasi untuk menjunjung tinggi aspirasi aktif-aktif multi-wilayah dari desain aplikasi.

Azure menyediakan banyak platform data relasional terkelola, termasuk Azure SQL Database dan Azure Database untuk solusi relasional OSS umum, termasuk MySQL, PostgreSQL, dan MariaDB. Oleh karena itu, pertimbangan desain dan rekomendasi dalam bagian ini akan berfokus pada penggunaan Azure SQL Database dan rasa OSS Azure Database yang optimal untuk memaksimalkan keandalan dan ketersediaan global.

Mempertimbangkan rancangan

  • Sementara teknologi data relasional dapat dikonfigurasi untuk menskalakan operasi baca dengan mudah, penulisan biasanya dibatasi untuk melalui satu instans utama, yang menempatkan batasan signifikan pada skalabilitas dan performa.

  • Pemecahan dapat diterapkan untuk mendistribusikan data dan pemrosesan di beberapa database terstruktur yang identik, mempartisi database secara horizontal untuk menavigasi batasan platform.

    • Misalnya, sharding sering diterapkan dalam platform SaaS multi-penyewa untuk mengisolasi grup penyewa ke dalam konstruksi platform data yang berbeda.

Azure SQL Database

  • Azure SQL Database menyediakan mesin database terkelola penuh yang selalu berjalan pada versi stabil terbaru dari mesin database SQL Server dan Sistem Operasi yang mendasar.

    • Menyediakan fitur cerdas seperti penyetelan performa, pemantauan ancaman, dan penilaian kerentanan.

  • Azure SQL Database menyediakan ketersediaan tinggi regional bawaan dan replikasi geografis turnkey untuk mendistribusikan replika baca di seluruh wilayah Azure.

    • Dengan replikasi geografis, replika database sekunder tetap baca-saja sampai failover dimulai.
    • Hingga empat sekunder didukung di wilayah yang sama atau berbeda.
    • Replika sekunder juga dapat digunakan untuk akses kueri baca-saja untuk mengoptimalkan performa baca.
    • Failover harus dimulai secara manual tetapi dapat dibungkus dalam prosedur operasional otomatis.

  • Azure SQL Database menyediakan Grup Failover Otomatis, yang mereplikasi database ke server sekunder dan memungkinkan failover transparan jika gagal.

    • Grup failover otomatis mendukung replikasi semua database dalam grup ke hanya satu server sekunder atau instans di wilayah yang berbeda.
    • Grup failover otomatis saat ini tidak didukung di tingkat layanan Hyperscale.
    • Database sekunder dapat digunakan untuk membongkar lalu lintas baca.

  • Replika database tingkat layanan Premium atau Bisnis Penting dapat didistribusikan di seluruh Zona Ketersediaan tanpa biaya tambahan.

    • Cincin kontrol juga diduplikasi di beberapa zona sebagai tiga cincin gateway (GW).
      • Perutean ke cincin gateway tertentu dikendalikan oleh Azure Traffic Manager.
    • Saat menggunakan tingkat Bisnis Penting, konfigurasi redundansi zona hanya tersedia saat perangkat keras komputasi Gen5 dipilih.

  • Azure SQL Database menawarkan SLA ketersediaan dasar 99,99% di semua tingkat layanannya, tetapi menyediakan SLA 99,995% yang lebih tinggi untuk tingkat Business Critical atau Premium di wilayah yang mendukung zona ketersediaan.

    • Azure SQL Database Business Critical atau tingkat Premium yang tidak dikonfigurasi untuk Penyebaran Zona Redundan memiliki ketersediaan SLA sebesar 99,99%.

  • Saat dikonfigurasi dengan replikasi geografis, tingkat Azure SQL Database Business Critical menyediakan Recovery Time Objective (RTO) 30 detik selama 100% jam yang disebarkan.

  • Saat dikonfigurasi dengan replikasi geografis, tingkat Azure SQL Database Business Critical memiliki Tujuan titik pemulihan (RPO) 5 detik selama 100% jam yang disebarkan.

  • Azure SQL tingkat Hyperscale Database, ketika dikonfigurasi dengan setidaknya dua replika, memiliki ketersediaan SLA 99,99%.

  • Biaya komputasi yang terkait dengan Azure SQL Database dapat dikurangi menggunakan Diskon Reservasi.

    • Tidak dimungkinkan untuk menerapkan kapasitas yang dipesan untuk database berbasis DTU.

  • Pemulihan titik waktu dapat digunakan untuk mengembalikan database dan memuat data ke titik waktu sebelumnya.

  • Pemulihan geografis dapat digunakan untuk memulihkan database dari cadangan geo-redundan.

Azure Database For PostgreSQL

  • Azure Database For PostgreSQL ditawarkan dalam tiga opsi penyebaran yang berbeda:

    • Server Tunggal, SLA 99,99%
    • Server Fleksibel, yang menawarkan redundansi Zona Ketersediaan, SLA 99,99%
    • Hyperscale (Citus), SLA 99,95% saat mode Ketersediaan Tinggi diaktifkan.

  • Hyperscale (Citus) memberikan skalabilitas dinamis melalui sharding tanpa perubahan aplikasi.

    • Mendistribusikan baris tabel di beberapa server PostgreSQL adalah kunci untuk memastikan kueri yang dapat diskalakan di Hyperscale (Citus).
    • Beberapa simpul secara kolektif dapat menyimpan lebih banyak data daripada database tradisional, dan dalam banyak kasus dapat menggunakan CPU pekerja secara paralel untuk mengoptimalkan biaya.

  • Skala otomatis dapat dikonfigurasi melalui otomatisasi runbook untuk memastikan elastisitas sebagai respons terhadap perubahan pola lalu lintas.

  • Server fleksibel memberikan efisiensi biaya untuk beban kerja non-produksi melalui kemampuan untuk menghentikan/memulai server, dan tingkat komputasi yang dapat meledak yang cocok untuk beban kerja yang tidak memerlukan kapasitas komputasi berkelanjutan.

  • Tidak ada biaya tambahan untuk penyimpanan cadangan hingga 100% dari total penyimpanan server yang disediakan.

    • Konsumsi tambahan penyimpanan cadangan dibebankan sesuai dengan GB/bulan yang dikonsumsi.

  • Biaya komputasi yang terkait dengan Azure Database for PostgreSQL dapat dikurangi menggunakan Diskon Reservasi Server Tunggal atau Diskon Reservasi Hyperscale (Citus).

Rekomendasi Desain

  • Pertimbangkan pemecahan ke database relasional partisi berdasarkan konteks aplikasi dan data yang berbeda, membantu menavigasi batasan platform, memaksimalkan skalabilitas dan ketersediaan, dan isolasi kesalahan.

    • Rekomendasi ini sangat umum ketika desain aplikasi mempertimbangkan tiga wilayah Azure atau lebih karena kendala teknologi relasional dapat secara signifikan menghambat platform data yang didistribusikan secara global.
    • Pemecahan tidak sesuai untuk semua skenario aplikasi, sehingga evaluasi kontekstual diperlukan.

  • Prioritaskan penggunaan Azure SQL Database di mana persyaratan relasional ada karena kematangannya pada platform Azure dan berbagai kemampuan keandalan.

Azure SQL Database

  • Gunakan tingkat layanan Business-Critical untuk memaksimalkan keandalan dan ketersediaan, termasuk akses ke kemampuan ketahanan penting.

  • Gunakan model konsumsi berbasis vCore untuk memfasilitasi pemilihan sumber daya komputasi dan penyimpanan independen, disesuaikan dengan persyaratan volume beban kerja dan throughput.

    • Pastikan model kapasitas yang ditentukan diterapkan untuk menginformasikan persyaratan sumber daya komputasi dan penyimpanan.

  • Konfigurasikan model penyebaran Zone-Redundant untuk menyebarkan replika database Business Critical dalam wilayah yang sama di seluruh Zona Ketersediaan.

  • Gunakan Active Geo-Replication untuk menyebarkan replika yang dapat dibaca di semua wilayah penyebaran (hingga empat).

  • Gunakan Grup Failover Otomatis untuk menyediakan failover transparan ke wilayah sekunder, dengan replikasi geografis diterapkan untuk memberikan replikasi ke wilayah penyebaran tambahan untuk pengoptimalan baca dan redundansi database.

    • Untuk skenario aplikasi yang terbatas hanya pada dua wilayah penyebaran, penggunaan Grup Failover Otomatis harus diprioritaskan.

  • Pertimbangkan pemicu operasional otomatis, berdasarkan peringatan yang selaras dengan model kesehatan aplikasi, untuk melakukan failover ke instans yang direplikasi secara geografis jika kegagalan berdampak pada primer dan sekunder dalam Grup Failover Otomatis.

Penting

Untuk aplikasi yang mempertimbangkan lebih dari empat wilayah penyebaran, pertimbangan serius harus diberikan pada sharding tercakup aplikasi atau pemfaktoran ulang aplikasi untuk mendukung teknologi penulisan multi-wilayah, seperti Azure Cosmos DB. Namun, jika ini tidak layak dalam skenario beban kerja aplikasi, disarankan untuk meningkatkan wilayah dalam satu geografi ke status utama yang mencakup instans yang direplikasi secara geografis untuk akses baca yang lebih merata.

  • Konfigurasikan aplikasi untuk mengkueri instans replika untuk kueri baca guna mengoptimalkan performa baca.

  • Gunakan Azure Monitor dan Azure SQL Analytics untuk wawasan operasional yang mendekati real-time di Azure SQL DB untuk mendeteksi insiden keandalan.

  • Gunakan Azure Monitor untuk mengevaluasi penggunaan untuk semua database guna menentukan apakah ukurannya telah tepat.

    • Pastikan alur CD mempertimbangkan pengujian beban di bawah tingkat beban representatif untuk memvalidasi perilaku platform data yang sesuai.

  • Hitung metrik kesehatan untuk komponen database untuk mengamati kesehatan relatif terhadap persyaratan bisnis dan pemanfaatan sumber daya, menggunakan pemantauan dan pemberitahuan untuk mendorong tindakan operasional otomatis jika sesuai.

    • Pastikan metrik performa kueri utama dimasukkan sehingga tindakan cepat dapat diambil saat degradasi layanan terjadi.

  • Optimalkan kueri, tabel, dan database menggunakan Wawasan Performa Kueri dan rekomendasi performa umum yang disediakan oleh Microsoft.

  • Terapkan logika coba lagi menggunakan SDK untuk mengurangi kesalahan sementara yang memengaruhi konektivitas database Azure SQL.

  • Prioritaskan penggunaan kunci yang dikelola layanan saat menerapkan Enkripsi Data Transparan (TDE) sisi server untuk enkripsi saat tidak aktif.

    • Jika kunci yang dikelola pelanggan atau enkripsi sisi klien (AlwaysEncrypted) diperlukan, pastikan kunci sangat tahan terhadap pencadangan dan fasilitas rotasi otomatis.

  • Pertimbangkan penggunaan pemulihan point-in-time sebagai playbook operasional untuk pulih dari kesalahan konfigurasi yang parah.

Azure Database For PostgreSQL

  • Server Fleksibel disarankan untuk menggunakannya untuk beban kerja penting bisnis karena dukungan Zona Ketersediaannya.

  • Saat menggunakan Hyperscale (Citus) untuk beban kerja penting bisnis, aktifkan mode Ketersediaan Tinggi untuk menerima jaminan SLA 99,95%.

  • Gunakan konfigurasi server Hyperscale (Citus) untuk memaksimalkan ketersediaan di beberapa simpul.

  • Tentukan model kapasitas untuk aplikasi guna menginformasikan persyaratan sumber daya komputasi dan penyimpanan dalam platform data.

Penembolokan untuk Data Tingkat Panas

Lapisan penembolokan dalam memori dapat diterapkan untuk meningkatkan platform data dengan meningkatkan throughput baca secara signifikan dan meningkatkan waktu respons klien end-to-end untuk skenario data tingkat panas.

Azure menyediakan beberapa layanan dengan kemampuan yang berlaku untuk penembolokan struktur data utama, dengan Azure Cache for Redis diposisikan untuk mengabstraksi dan mengoptimalkan akses baca platform data. Oleh karena itu, bagian ini akan berfokus pada penggunaan Azure Cache for Redis yang optimal dalam skenario di mana performa baca tambahan dan durabilitas akses data diperlukan.

Pertimbangan Desain

  • Lapisan penembolokan memberikan durabilitas akses data tambahan karena bahkan jika pemadaman yang berdampak pada teknologi data yang mendasar, rekam jepret data aplikasi masih dapat diakses melalui lapisan penembolokan.

  • Dalam skenario beban kerja tertentu, penembolokan dalam memori dapat diimplementasikan dalam platform aplikasi itu sendiri.

Azure Cache untuk Redis

  • Cache Redis adalah sistem penyimpanan dalam memori nilai kunci NoSQL sumber terbuka.

  • Tingkat Enterprise dan Enterprise Flash dapat disebarkan dalam konfigurasi aktif-aktif di seluruh Zona Ketersediaan dalam wilayah dan wilayah Azure yang berbeda melalui replikasi geografis.

    • Saat disebarkan di setidaknya tiga wilayah Azure dan tiga Zona Ketersediaan atau lebih di setiap wilayah, dengan replikasi geografis aktif diaktifkan untuk semua instans Cache, Azure Cache for Redis menyediakan SLA sebesar 99,999% untuk konektivitas ke satu titik akhir cache regional.
    • Saat disebarkan di tiga Zona Ketersediaan dalam satu wilayah Azure, SLA konektivitas 99,99% disediakan.

  • Tingkat Enterprise Flash berjalan pada kombinasi RAM dan flash penyimpanan memori non-volatil, dan sementara ini memperkenalkan penalti performa kecil itu juga memungkinkan ukuran cache yang sangat besar, hingga 13 TB dengan pengklusteran.

  • Dengan replikasi geografis, biaya untuk transfer data antar wilayah juga akan berlaku selain biaya langsung yang terkait dengan instans cache.

  • Fitur Updates Terjadwal tidak menyertakan pembaruan Atau pembaruan Azure yang diterapkan ke sistem operasi VM yang mendasar.

  • Akan ada peningkatan pemanfaatan CPU selama operasi peluasan skala saat data dimigrasikan ke instans baru.

Rekomendasi Desain

  • Pertimbangkan lapisan penembolokan yang dioptimalkan untuk skenario data 'panas' untuk meningkatkan throughput baca dan meningkatkan waktu respons.

  • Terapkan kebijakan yang sesuai untuk kedaluwarsa cache dan housekeeping untuk menghindari pertumbuhan data yang melarikan diri.

    • Pertimbangkan item cache yang kedaluwarsa saat data cadangan berubah.

Azure Cache untuk Redis

  • Gunakan SKU Premium atau Enterprise untuk memaksimalkan keandalan dan performa.

    • Untuk skenario dengan volume data yang sangat besar, tingkat Enterprise Flash harus dipertimbangkan.
    • Untuk skenario di mana hanya replikasi geografis pasif yang diperlukan, tingkat Premium juga dapat dipertimbangkan.

  • Sebarkan instans replika menggunakan replikasi geografis dalam konfigurasi aktif di semua wilayah penyebaran yang dipertimbangkan.

  • Pastikan instans replika disebarkan di seluruh Zona Ketersediaan dalam setiap wilayah Azure yang dipertimbangkan.

  • Gunakan Azure Monitor untuk mengevaluasi Azure Cache for Redis.

    • Hitung skor kesehatan untuk komponen cache regional untuk mengamati kesehatan relatif terhadap persyaratan bisnis dan pemanfaatan sumber daya.
    • Amati dan waspada pada metrik utama seperti CPU tinggi, penggunaan memori tinggi, beban server tinggi, dan kunci yang dikeluarkan untuk wawasan kapan harus menskalakan cache.

  • Optimalkan ketahanan koneksi dengan menerapkan logika coba lagi, waktu habis, dan menggunakan implementasi database tunggal dari multiplexer koneksi Redis.

  • Konfigurasikan pembaruan terjadwal untuk menentukan hari dan waktu pembaruan Redis Server diterapkan ke cache.

Skenario Analitis

Semakin umum bagi aplikasi misi penting untuk mempertimbangkan skenario analitis sebagai sarana untuk mendorong nilai tambahan dari aliran data yang dilingkup. Oleh karena itu, skenario analitik aplikasi dan operasional (AIOps) membentuk aspek penting dari platform data yang sangat andal.

Beban kerja analitis dan transaksional memerlukan kemampuan dan pengoptimalan platform data yang berbeda untuk performa yang dapat diterima dalam konteks masing-masing.

Deskripsi Analitis Transaksional
Kasus penggunaan 6 Menganalisis data dalam volume yang sangat besar ("big data") Memproses volume transaksi individu yang sangat besar
Dioptimalkan untuk Membaca kueri dan agregasi atas banyak rekaman Kueri Buat/Baca/Perbarui/Hapus (CRUD) mendekati real-time selama beberapa rekaman
Karakteristik Utama - Mengonsolidasikan dari sumber data rekaman
- Penyimpanan berbasis kolom
- Penyimpanan terdistribusi
- Pemrosesan paralel
- Denormalisasi
- Pembacaan dan penulisan konkurensi rendah
- Optimalkan untuk volume penyimpanan dengan kompresi		 - Sumber data rekaman untuk aplikasi
- Penyimpanan berbasis baris
- Penyimpanan yang bersebelahan
- Pemrosesan simetris
-Dinormalisasi
- Pembacaan dan penulisan konkurensi tinggi, pembaruan indeks
- Optimalkan untuk akses data cepat dengan penyimpanan dalam memori

Azure Synapse menyediakan platform analitik perusahaan yang menyatukan data relasional dan non-relasional dengan teknologi Spark, menggunakan integrasi bawaan dengan layanan Azure seperti Azure Cosmos DB untuk memfasilitasi analitik big data. Oleh karena itu, pertimbangan desain dan rekomendasi dalam bagian ini akan berfokus pada Azure Synapse optimal dan penggunaan Azure Cosmos DB untuk skenario analitik.

Pertimbangan Desain

  • Secara tradisional, skenario analitik skala besar difasilitasi dengan mengekstrak data ke dalam platform data terpisah yang dioptimalkan untuk kueri analitik berikutnya.
    • Alur Ekstraksi, Transformasi, dan Pemuatan (ETL) digunakan untuk mengekstrak data akan menggunakan throughput dan memengaruhi performa beban kerja transaksional.
    • Menjalankan alur ETL jarang untuk mengurangi dampak throughput dan performa akan mengakibatkan data analitik yang kurang mutakhir.
    • Pengembangan alur ETL dan overhead pemeliharaan meningkat karena transformasi data menjadi lebih kompleks.
      • Misalnya, jika data sumber sering diubah atau dihapus, alur ETL harus mempertangungjawabkan perubahan tersebut dalam data target untuk kueri analitik melalui pendekatan aditif/versi, pencadangan dan muat ulang, atau perubahan di tempat pada data analitik. Masing-masing pendekatan ini akan memiliki dampak turunan, seperti pembuatan ulang atau pembaruan indeks.

Azure Cosmos DB

  • Kueri analitik yang berjalan pada data transaksional Azure Cosmos DB biasanya akan dikumpulkan di seluruh partisi melalui volume data yang besar, menggunakan throughput Unit Permintaan (RU) yang signifikan, yang dapat memengaruhi performa beban kerja transaksional di sekitarnya.

  • Azure Cosmos DB Analytical Store menyediakan penyimpanan data berorientasi kolom yang skema dan sepenuhnya terisolasi yang memungkinkan analitik skala besar pada data Azure Cosmos DB dari Azure Synapse tanpa dampak ke beban kerja transaksional Azure Cosmos DB.

    • Saat Kontainer Azure Cosmos DB diaktifkan sebagai Penyimpanan Analitik, penyimpanan kolom baru dibuat secara internal dari data operasional di Kontainer. Penyimpanan kolom ini disimpan secara terpisah dari penyimpanan transaksi berorientasi baris untuk kontainer.
    • Operasi Buat, Perbarui, dan Hapus pada data operasional secara otomatis disinkronkan ke penyimpanan analitik, sehingga tidak diperlukan umpan perubahan atau pemrosesan ETL.
    • Sinkronisasi data dari operasional ke penyimpanan analitik tidak menggunakan Unit Permintaan (RU) throughput yang disediakan pada Kontainer atau Database. Tidak ada dampak performa pada beban kerja transaksional. Analytical Store tidak memerlukan alokasi RU tambahan pada Database atau Kontainer Azure Cosmos DB.
    • Sinkronisasi Otomatis adalah proses di mana perubahan data operasional secara otomatis disinkronkan ke Analytical Store. Latensi Sinkronisasi Otomatis biasanya kurang dari dua (2) menit.
      • Latensi Sinkronisasi Otomatis bisa hingga lima (5) menit untuk Database dengan throughput bersama dan sejumlah besar Kontainer.
      • Segera setelah Sinkronisasi Otomatis selesai, data terbaru dapat dikueri dari Azure Synapse.
    • Penyimpanan Penyimpanan Analitik menggunakan model harga berbasis konsumsi yang membebankan biaya untuk volume data dan jumlah operasi baca dan tulis. Harga penyimpanan analitis terpisah dari harga penyimpanan transaksional.

  • Menggunakan Azure Synapse Link, Azure Cosmos DB Analytical Store dapat dikueri langsung dari Azure Synapse. Ini memungkinkan no-ETL, Hybrid Transactional-Analytical Processing (HTAP) dari Synapse, sehingga data Azure Cosmos DB dapat dikueri bersama dengan beban kerja analitik lainnya dari Synapse mendekati real-time.

  • Azure Cosmos DB Analytical Store tidak dipartisi secara default.

    • Untuk skenario kueri tertentu, performa akan meningkat dengan mempartisi data Analytical Store menggunakan kunci yang sering digunakan dalam predikat kueri.
    • Partisi dipicu oleh pekerjaan di Azure Synapse yang menjalankan buku catatan Spark menggunakan Synapse Link, yang memuat data dari Azure Cosmos DB Analytical Store dan menulisnya ke penyimpanan yang dipartisi Synapse di akun penyimpanan utama ruang kerja Synapse.

  • Azure Synapse Analytics SQL Serverless pools dapat mengkueri Analytical Store melalui tampilan yang diperbarui secara otomatis atau melalui SELECT / OPENROWSET perintah.

  • Azure Synapse kumpulan Spark Analytics dapat mengkueri Analytical Store melalui tabel Spark yang diperbarui secara otomatis atau spark.read perintah .

  • Data juga dapat disalin dari Azure Cosmos DB Analytical Store ke dalam kumpulan Synapse SQL khusus menggunakan Spark, sehingga sumber daya kumpulan SQL Azure Synapse yang disediakan dapat digunakan.

  • Data Azure Cosmos DB Analytical Store dapat dikueri dengan Azure Synapse Spark.

    • Notebook Spark memungkinkan kombinasi dataframe Spark untuk menggabungkan dan mengubah data analitik Azure Cosmos DB dengan himpunan data lain, dan menggunakan fungsionalitas Synapse Spark tingkat lanjut lainnya termasuk menulis data yang diubah ke penyimpanan lain atau melatih model Pembelajaran Mesin AIOps.

Penyimpanan Kolom Analitik Azure Cosmos DB

Azure Synapse

  • Azure Synapse menyatukan kemampuan analitik termasuk pergudangan data SQL, big data Spark, dan Data Explorer untuk analitik log dan rangkaian waktu.

    • Azure Synapse menggunakan layanan tertaut untuk menentukan koneksi ke layanan lain, seperti Azure Storage.
    • Data dapat diserap ke Synapse Analytics melalui aktivitas Salin dari sumber yang didukung. Ini memungkinkan analitik data di Synapse tanpa memengaruhi penyimpanan data sumber, tetapi menambahkan waktu, biaya, dan latensi overhead karena transfer data.
    • Data juga dapat dikueri di tempat di penyimpanan eksternal yang didukung, menghindari overhead penyerapan dan pergerakan data. Azure Storage dengan Data Lake Gen2 adalah penyimpanan yang didukung untuk data yang diekspor Synapse dan Log Analytics dapat dikueri melalui Synapse Spark.

  • Azure Synapse Studio menyatukan tugas penyerapan dan kueri.

    • Data sumber, termasuk data Azure Cosmos DB Analytical Store dan data Ekspor Analitik Log, dikueri dan diproses untuk mendukung kecerdasan bisnis dan kasus penggunaan analitik agregat lainnya.

Analitik Azure Synapse

Rekomendasi Desain

  • Pastikan beban kerja analitis tidak berdampak pada beban kerja aplikasi transaksi untuk mempertahankan performa transaksi.

Analitik Aplikasi

AIOps dan Analitik Operasional

  • Buat ruang kerja Azure Synapse tunggal dengan layanan tertaut dan himpunan data untuk setiap akun Azure Storage sumber tempat data operasional dari sumber daya dikirim.

  • Buat akun Azure Storage khusus dan gunakan sebagai akun penyimpanan utama ruang kerja untuk menyimpan data katalog dan metadata ruang kerja Synapse. Konfigurasikan dengan namespace hierarkis untuk mengaktifkan Azure Data Lake Gen2.

    • Pertahankan pemisahan antara data analitik sumber dan data dan metadata ruang kerja Synapse.
      • Jangan gunakan salah satu akun Azure Storage regional atau global tempat data operasional dikirim.

Langkah selanjutnya

Tinjau pertimbangan untuk pertimbangan jaringan.

Jaringan dan konektivitas