Bagikan melalui

Cara beradaptasi dengan Azure Cosmos DB untuk Apache Cassandra jika Anda berasal dari Apache Cassandra

  • Artikel

BERLAKU UNTUK: Cassandra

Azure Cosmos DB for Apache Cassandra menyediakan kompatibilitas protokol kawat dengan SDK dan alat Cassandra yang ada. Anda dapat menjalankan aplikasi yang dirancang untuk terhubung ke Apache Cassandra dengan menggunakan API untuk Cassandra dengan perubahan minimal.

Saat Anda menggunakan API untuk Cassandra, penting untuk mengetahui perbedaan antara Apache Cassandra dan Azure Cosmos DB. Jika Anda terbiasa dengan Apache Cassandra asli, artikel ini dapat membantu Anda mulai menggunakan Azure Cosmos DB untuk Apache Cassandra.

Dukungan fitur

API untuk Cassandra mendukung sejumlah besar fitur Apache Cassandra. Beberapa fitur tidak didukung atau memiliki batasan. Sebelum bermigrasi, pastikan bahwa fitur Azure Cosmos DB for Apache Cassandra yang Anda butuhkan didukung.

Replikasi

Saat Anda merencanakan replikasi, penting untuk melihat migrasi dan konsistensi.

Meskipun Anda dapat berkomunikasi dengan API untuk Cassandra melalui protokol kawat v4 protokol biner Cassandra Query Language (CQL), Azure Cosmos DB menerapkan protokol replikasi internalnya sendiri. Anda tidak dapat menggunakan protokol gosip Cassandra untuk migrasi atau replikasi langsung. Untuk informasi selengkapnya, lihat Migrasi langsung dari Apache Cassandra ke API untuk Cassandra dengan menggunakan penulisan ganda.

Untuk informasi tentang migrasi offline, lihat Memigrasikan data dari Cassandra ke akun Azure Cosmos DB for Apache Cassandra dengan menggunakan Azure Databricks.

Meskipun pendekatan kepada konsistensi replikasi di Apache Cassandra dan Azure Cosmos DB serupa, penting untuk memahami bagaimana mereka berbeda. Dokumen pemetaan membandingkan pendekatan Apache Cassandra dan Azure Cosmos DB untuk konsistensi replikasi. Namun, kami sangat menyarankan Agar Anda secara khusus meninjau pengaturan konsistensi Azure Cosmos DB atau tonton panduan video singkat untuk memahami pengaturan konsistensi di platform Azure Cosmos DB.

Saat Anda menggunakan API untuk Cassandra, Anda tidak perlu membuat perubahan kode yang substansial pada aplikasi yang ada yang menjalankan Apache Cassandra. Kami merekomendasikan beberapa pendekatan dan pengaturan konfigurasi untuk API untuk Cassandra di Azure Cosmos DB. Tinjau API posting blog untuk rekomendasi Cassandra untuk Java.

Sampel kode

API untuk Cassandra dirancang untuk bekerja dengan kode aplikasi Anda yang ada. Jika mengalami kesalahan terkait konektivitas, gunakan contoh mulai cepat sebagai titik awal untuk menemukan perubahan penyiapan minor yang mungkin perlu Anda lakukan dalam kode yang sudah ada.

Kami juga memiliki sampel yang lebih mendalam untuk driver Java v3 dan Java v4. Sampel kode ini menerapkan ekstensi kustom, yang sebagai gantinya menerapkan konfigurasi klien yang disarankan.

Anda juga dapat menggunakan sampel untuk Java Spring Boot (driver v3) dan Java Spring Boot (driver v4).

Penyimpanan

API untuk Cassandra didukung oleh Azure Cosmos DB, yang merupakan mesin database NoSQL berorientasi dokumen. Azure Cosmos DB mempertahankan metadata, yang mungkin mengakibatkan perubahan jumlah penyimpanan fisik yang diperlukan untuk beban kerja tertentu.

Perbedaan dalam persyaratan penyimpanan antara Apache Cassandra asli dan Azure Cosmos DB paling terlihat dalam ukuran baris kecil. Dalam beberapa kasus, perbedaannya mungkin offset karena Azure Cosmos DB tidak mengimplementasikan pemadatan atau penanda. Faktor ini sangat bergantung pada beban kerja. Jika tidak yakin tentang persyaratan penyimpanan, kami menyarankan agar Anda membuat bukti konsep terlebih dahulu.

Penyebaran multiwilayah

Apache Cassandra asli adalah sistem multi-master secara default. Apache Cassandra tidak memiliki opsi untuk master tunggal dengan replikasi multi-wilayah untuk baca saja. Konsep failover tingkat aplikasi ke wilayah lain untuk menulis berlebihan di Apache Cassandra. Semua simpul terpisah, dan tidak ada titik kegagalan tunggal. Namun, Azure Cosmos DB menyediakan kemampuan siap pakai untuk mengonfigurasi wilayah master tunggal atau multi-master untuk penulisan.

Keuntungan memiliki satu wilayah master untuk menulis adalah menghindari skenario konflik lintas wilayah. Hal ini memberi Anda opsi untuk mempertahankan konsistensi yang kuat di beberapa wilayah sekaligus mempertahankan ketersediaan yang tinggi.

Catatan

Konsistensi yang kuat di seluruh wilayah dan Tujuan Titik Pemulihan (RPO) dari nol tidak mungkin dilakukan bagi Apache Cassandra asli karena semua node mampu melayani penulisan. Azure Cosmos DB dapat dikonfigurasi untuk konsistensi yang kuat di seluruh wilayah dalam konfigurasi wilayah tulis tunggal. Namun, seperti Apache Cassandra asli, Anda tidak dapat mengonfigurasi akun Azure Cosmos DB yang dikonfigurasi dengan beberapa wilayah penulisan untuk konsistensi yang kuat. Sistem distribusi tidak dapat menyediakan RPO dari nol dan Tujuan Waktu Pemulihan (RTO) nol.

Untuk informasi selengkapnya, lihat Kebijakan penyeimbangan beban di API kami untuk rekomendasi Cassandra untuk blog Java. Selain itu, lihat Skenario failover dalam sampel kode resmi kami untuk driver Cassandra Java v4.

Unit permintaan

Salah satu perbedaan utama antara menjalankan klaster Apache Cassandra asli dan menyediakan akun Azure Cosmos DB, adalah cara penyediaan kapasitas database. Dalam database tradisional, kapasitas dinyatakan dalam inti CPU, RAM, dan IOP. Azure Cosmos DB adalah database multi-penyewa platform-sebagai-layanan. Kapasitas dinyatakan dengan menggunakan metrik tunggal yang dinormalisasi yang dikenal sebagai unit permintaan. Setiap permintaan yang dikirim ke database memiliki biaya unit permintaan (biaya RU). Setiap permintaan dapat dibuat profilnya guna menentukan biayanya.

Manfaat menggunakan unit permintaan sebagai metrik adalah kapasitas basis data dapat ditentukan secara deterministik untuk kinerja dan efisiensi yang sangat dapat diprediksi. Setelah anda membuat profil biaya setiap permintaan, Anda dapat menggunakan unit permintaan untuk langsung mengaitkan jumlah permintaan yang dikirim ke database dengan kapasitas yang perlu Anda provisikan. Tantangan dari cara provisi kapasitas ini adalah Anda perlu memiliki pemahaman yang kuat tentang karakteristik throughput beban kerja Anda.

Kami sangat merekomendasikan agar Anda memprofilkan permintaan Anda. Gunakan informasi tersebut untuk membantu Anda memperkirakan jumlah unit permintaan yang perlu Anda provisikan. Berikut adalah beberapa artikel yang mungkin membantu Anda memperkirakan:

Model penyediaan kapasitas

Dalam penyediaan database tradisional, kapasitas tetap disediakan di depan untuk menangani throughput yang diantisipasi. Azure Cosmos DB menawarkan model berbasis kapasitas yang dikenal sebagai throughput yang ditetapkan. Sebagai layanan multi-penyewa, Azure Cosmos DB juga menawarkan model berbasis konsumsi dalam mode skala otomatis dan mode tanpa server. Sejauh mana beban kerja mungkin akan diuntungkan dari salah satu model penyediaan berbasis konsumsi ini bergantung pada prediksi throughput untuk beban kerja.

Secara umum, beban kerja berstatus tetap dengan throughput yang dapat diprediksi paling diuntungkan dari throughput yang disediakan. Beban kerja yang memiliki periode dormancy yang besar diuntungkan dengan mode tanpa server. Beban kerja, yang memiliki tingkat throughput minimal yang berkelanjutan, tetapi dengan lonjakan yang tidak terduga, akan paling diuntungkan dari penskalaan otomatis. Kami menyarankan Anda meninjau artikel berikut ini untuk memahami model kapasitas terbaik untuk kebutuhan throughput:

Partisi

Pemartisian di Azure Cosmos DB mirip dengan pemartisian di Apache Cassandra. Salah satu perbedaan utamanya adalah Azure Cosmos DB lebih dioptimalkan untuk skala horizontal. Di Azure Cosmos DB, batas ditempatkan pada jumlah kapasitas throughput vertikal yang tersedia dalam partisi fisik apa pun. Dampak dari pengoptimalan ini paling terlihat jika model data yang ada memiliki condong throughput yang signifikan.

Lakukan langkah-langkah untuk memastikan bahwa desain kunci partisi Anda menghasilkan distribusi permintaan yang relatif seragam. Untuk informasi selengkapnya tentang cara kerja dan batasan partisi logis dan fisik pada kapasitas throughput per partisi, lihat Pemartisian di Azure Cosmos DB untuk Apache Cassandra.

Penskalaan

Di Apache Cassandra asli, peningkatan kapasitas dan skala melibatkan penambahan node baru ke kluster dan memastikan mereka ditambahkan dengan benar ke cincin Cassandra. Di Azure Cosmos DB, menambahkan node transparan dan otomatis. Penskalaan adalah fungsi dari jumlah unit permintaan yang disediakan untuk keyspace atau tabel Anda. Skala di komputer fisik terjadi ketika penyimpanan fisik atau throughput yang diperlukan mencapai batas yang diperbolehkan untuk partisi logis atau fisik. Untuk informasi selengkapnya, lihat Pemartisian di Azure Cosmos DB untuk Apache Cassandra.

Pembatasan tarif

Tantangan penyediaan unit permintaan, terutama jika Anda menggunakan throughput terprovisi, adalah tarif yang dibatasi. Azure Cosmos DB akan mengembalikan kesalahan pembatasan tarif jika klien menggunakan lebih banyak sumber daya dibandingkan jumlah yang telah Anda provisikan. API untuk Cassandra di Azure Cosmos DB menerjemahkan pengecualian ini ke kesalahan yang kelebihan beban pada protokol asli Cassandra. Untuk informasi tentang cara menghindari pembatasan tarif dalam aplikasi Anda, lihat Mencegah kesalahan pembatasan tarif untuk operasi Azure Cosmos DB for Apache Cassandra.

Konektor Apache Spark

Banyak pengguna Apache Cassandra menggunakan konektor Apache Spark Cassandra untuk membuat kueri data mereka guna kebutuhan analitik dan pergerakan data. Anda dapat terhubung ke API untuk Cassandra dengan cara yang sama dan dengan menggunakan konektor yang sama. Sebelum Anda terhubung ke API untuk Cassandra, tinjau Sambungkan ke Azure Cosmos DB untuk Apache Cassandra dari Spark. Khususnya, lihat bagian Optimalkan konfigurasi throughput konektor Spark.

Pemecahan Masalah Umum

Untuk solusi masalah umum, lihat Memecahkan masalah umum di Azure Cosmos DB for Apache Cassandra.

Langkah berikutnya