Pilih jumlah shard di Azure Cosmos DB for PostgreSQL

Penting

Azure Cosmos DB for PostgreSQL tidak lagi didukung untuk proyek baru. Jangan gunakan layanan ini untuk proyek baru. Sebagai gantinya, gunakan salah satu dari dua layanan ini:

• Gunakan Azure Cosmos DB for NoSQL untuk solusi database terdistribusi yang dirancang untuk skenario skala tinggi dengan perjanjian tingkat layanan ketersediaan (SLA) 99,999%, skala otomatis instan, dan failover otomatis di beberapa wilayah.

• Gunakan fitur Elastic Clusters dari Azure Database For PostgreSQL untuk PostgreSQL yang dipecah menggunakan ekstensi Citus sumber terbuka.

Memilih jumlah shard untuk setiap tabel terdistribusi adalah keseimbangan antara fleksibilitas memiliki lebih banyak pecahan, dan overhead untuk perencanaan dan eksekusi kueri di seluruh tabel tersebut. Jika Anda memutuskan untuk mengubah jumlah shard tabel setelah mendistribusikan, Anda dapat menggunakan fungsi alter_distributed_table .

Kasus penggunaan multi-tenant SaaS

Pilihan optimal bervariasi tergantung pada pola akses Anda untuk data. Misalnya, dalam skenario penggunaan Database SaaS Multi-Penyewa, sebaiknya pilih antara 32 - 128 shard. Untuk beban kerja yang lebih kecil katakanlah <100 GB, Anda dapat memulai dengan 32 pecahan dan untuk beban kerja yang lebih besar, Anda dapat memilih 64 atau 128. Pilihan ini memberi Anda kelonggaran untuk menskalakan dari 32 hingga 128 mesin pekerja.

Kasus penggunaan analitik waktu nyata

Dalam kasus penggunaan Analitik Real Time, jumlah shard harus terkait dengan jumlah total inti pada pekerja. Untuk memastikan paralelisme maksimum, Anda harus membuat pecahan yang cukup pada setiap simpul sehingga setidaknya ada satu shard per inti CPU. Kami biasanya merekomendasikan untuk membuat sejumlah besar pecahan awal, misalnya, 2x atau 4x jumlah inti CPU saat ini. Memiliki lebih banyak pecahan memungkinkan penskalaan di masa mendatang jika Anda menambahkan lebih banyak pekerja dan inti CPU.

Perlu diingat bahwa, untuk setiap kueri, Azure Cosmos DB for PostgreSQL membuka satu koneksi database per shard, dan bahwa koneksi ini terbatas. Berhati-hatilah untuk menjaga jumlah shard tetap kecil sehingga kueri terdistribusi tidak akan sering harus menunggu koneksi jaringan. Letakkan cara lain, koneksi yang diperlukan, (max concurrent queries * shard count), seharusnya tidak melebihi total koneksi yang mungkin dalam sistem, (number of workers * max_connections per worker).

Langkah berikutnya

• Pelajari selengkapnya tentang opsi performa kluster.
• Menskalakan kluster ke atas atau ke luar
• Seimbangkan kembali pecahan