Pilih kolom distribusi di Azure Cosmos DB for PostgreSQL

BERLAKU UNTUK: Azure Cosmos DB for PostgreSQL (didukung oleh ekstensi database Citus ke PostgreSQL)

Memilih kolom distribusi setiap tabel adalah salah satu keputusan pemodelan yang paling penting yang Anda akan buat. Azure Cosmos DB for PostgreSQL menyimpan baris dalam pecahan berdasarkan nilai kolom distribusi baris.

Pilihan yang benar mengelompokkan data terkait bersama-sama pada simpul fisik yang sama, yang membuat kueri menjadi cepat dan menambahkan dukungan untuk semua fitur SQL. Pilihan yang salah membuat sistem berjalan lambat.

Tips umum

Berikut adalah empat kriteria untuk memilih kolom distribusi yang ideal untuk tabel terdistribusi Anda.

1. Pilih kolom yang merupakan bagian utama dalam beban kerja aplikasi.

   Anda mungkin menganggap kolom ini sebagai "hati", "bagian tengah", atau "dimensi alami" untuk mempartisi data.

   Contoh:

   • device_id dalam beban kerja IoT
   • security_id untuk aplikasi keuangan yang melacak sekuritas
   • user_id dalam analitik pengguna
   • tenant_id untuk aplikasi SaaS multi-penyewa

2. Pilih kolom dengan kardinalitas yang layak, dan distribusi statistik yang merata.

   Kolom harus memiliki banyak nilai, dan didistribusikan secara menyeluruh dan merata di antara semua pecahan.

   Contoh:

   • Kardinalitas lebih dari 1000
   • Jangan memilih kolom yang memiliki nilai yang sama pada sebagian besar baris (kemiringan data)
   • Dalam beban kerja SaaS, memiliki satu penyewa yang jauh lebih besar dari yang lain dapat menyebabkan kemiringan data. Untuk situasi ini, Anda dapat menggunakan isolasi penyewa untuk membuat pecahan khusus guna menangani penyewa.

3. Pilih kolom yang menguntungkan kueri Anda yang ada.

   Untuk beban kerja transaksional atau operasional (di mana sebagian besar kueri hanya membutuhkan beberapa milidetik), pilih kolom yang muncul sebagai filter dalam klausa WHERE untuk setidaknya 80% kueri. Misalnya, kolom device_id di SELECT * FROM events WHERE device_id=1.

   Untuk beban kerja analitis (di mana sebagian besar kueri membutuhkan waktu 1-2 detik), pilih kolom yang memungkinkan kueri diparalelkan di seluruh node pekerja. Misalnya, kolom yang sering muncul dalam klausa GROUP BY, atau mengkueri beberapa nilai sekaligus.

4. Pilih kolom yang ada di sebagian besar tabel besar.

   Tabel yang lebih dari 50 GB harus didistribusikan. Memilih kolom distribusi yang sama untuk semuanya memungkinkan Anda menemukan data bersama untuk kolom tersebut pada node pekerja. Co-location membuatnya efisien untuk menjalankan JOIN dan rollup, serta menerapkan kunci asing.

   Tabel lain (lebih kecil) dapat berupa tabel lokal atau referensi. Jika tabel yang lebih kecil perlu JOIN dengan tabel terdistribusi, buat tabel referensi.

Contoh kasus penggunaan

Kami telah melihat kriteria umum untuk memilih kolom distribusi. Sekarang mari kita lihat bagaimana penerapannya pada kasus penggunaan umum.

Aplikasi multipenyewa

Arsitektur multi-penyewa menggunakan bentuk pemodelan database hierarkis untuk mendistribusikan kueri di seluruh simpul dalam kluster. Bagian atas hierarki data dikenal sebagai ID penyewa dan perlu disimpan dalam kolom pada setiap tabel.

Azure Cosmos DB for PostgreSQL memeriksa kueri untuk melihat ID penyewa mana yang mereka libatkan dan menemukan pecahan tabel yang cocok. Ini merutekan kueri ke satu simpul pekerja yang berisi shard. Menjalankan kueri dengan semua data yang relevan ditempatkan pada simpul yang sama disebut kolokasi.

Diagram berikut ini mengilustrasikan kolokasi dalam model data multipenyewa. Diagram ini berisi dua tabel, Akun dan Campaigns, masing-masing didistribusikan oleh account_id . Kotak berbayang mewakili shard. Shard hijau disimpan bersama pada satu simpul pekerja, dan shard biru disimpan di simpul pekerja lain. Perhatikan bagaimana kueri gabungan antara Akun dan Campaigns memiliki semua data yang diperlukan bersama-sama pada satu simpul saat kedua tabel dibatasi ke id_akun yang sama.

Untuk menerapkan desain ini dalam skema Anda sendiri, identifikasi apa yang merupakan penyewa dalam aplikasi Anda. Instans umum termasuk perusahaan, akun, organisasi, atau pelanggan. Nama kolom akan seperti company_id atau customer_id. Periksa setiap kueri Anda dan tanyakan pada diri Anda, apakah akan berhasil jika memiliki lebih banyak klausa WHERE untuk membatasi semua tabel yang terlibat ke baris dengan ID penyewa yang sama? Kueri dalam model multipenyewa dicakup ke penyewa. Misalnya, kueri tentang penjualan atau inventaris tercakup dalam toko tertentu.

Praktik terbaik

• Distribusikan tabel menurut kolom tenant_id yang umum. Misalnya, dalam aplikasi SaaS yang mana penyewa adalah perusahaan, tenant_id kemungkinan adalah company_id.
• Konversi tabel lintas penyewa kecil menjadi tabel referensi. Saat beberapa penyewa berbagi tabel informasi kecil, distribusikan sebagai tabel referensi.
• Batasi filter semua kueri aplikasi menurut tenant_id. Setiap kueri harus meminta informasi untuk satu penyewa sekaligus.

Baca tutorial multipenyewa untuk contoh cara membangun aplikasi semacam ini.

Aplikasi real time

Arsitektur multipenyewa memperkenalkan struktur hierarki dan menggunakan kolokasi data untuk merutekan kueri per penyewa. Sebaliknya, arsitektur real-time bergantung pada properti distribusi tertentu dari data mereka untuk mencapai pemrosesan yang sangat paralel.

Kami menggunakan "ID entitas" sebagai istilah untuk kolom distribusi dalam model real-time. Entitas umum adalah pengguna, host, atau perangkat.

Kueri real-time biasanya meminta agregat numerik yang dikelompokkan menurut tanggal atau kategori. Azure Cosmos DB for PostgreSQL mengirimkan kueri ini ke setiap shard untuk hasil parsial dan menyusun jawaban akhir pada simpul koordinator. Kueri berjalan paling cepat saat sebanyak mungkin simpul berkontribusi, dan saat tidak ada satu simpul pun yang harus melakukan jumlah pekerjaan yang tidak proporsional.

Praktik terbaik

• Pilih kolom dengan kardinalitas tinggi sebagai kolom distribusi. Sebagai perbandingan, bidang Status pada tabel pesanan dengan nilai Baru, Berbayar, dan Dikirim adalah pilihan kolom distribusi yang buruk. Ini hanya mengasumsikan beberapa nilai, yang membatasi jumlah shard yang dapat menyimpan data, dan jumlah simpul yang dapat memprosesnya. Di antara kolom dengan kardinalitas tinggi, ada baiknya juga memilih kolom-kolom yang sering digunakan dalam klausa kelompok demi atau sebagai kunci gabungan.
• Pilih kolom dengan distribusi merata. Jika Anda mendistribusikan tabel pada kolom yang condong ke nilai umum tertentu, data dalam tabel cenderung terakumulasi dalam shard tertentu. Simpul yang menahan shard tersebut akhirnya melakukan lebih banyak pekerjaan daripada simpul lainnya.
• Distribusikan tabel fakta dan dimensi pada kolom umumnya. Tabel fakta Anda hanya dapat memiliki satu kunci distribusi. Tabel yang bergabung pada kunci lain tidak akan dikolokasi dengan tabel fakta. Pilih satu dimensi untuk dikolokasi berdasarkan seberapa sering digabungkan dan ukuran baris gabungan.
• Ubah beberapa tabel dimensi menjadi tabel referensi. Jika tabel dimensi tidak dapat dikolokasi dengan tabel fakta, Anda dapat meningkatkan kinerja kueri dengan mendistribusikan salinan tabel dimensi ke semua node dalam bentuk tabel referensi.

Baca tutorial dasbor real-time untuk contoh cara membangun aplikasi semacam ini.

Data rangkaian waktu

Dalam beban kerja rangkaian waktu, aplikasi meminta informasi terbaru saat mereka mengarsipkan informasi lama.

Kesalahan paling umum dalam pemodelan informasi rangkaian waktu di Azure Cosmos DB for PostgreSQL adalah menggunakan tanda waktu itu sendiri sebagai kolom distribusi. Distribusi hash berdasarkan waktu mendistribusikan waktu yang tampaknya acak ke dalam shard yang berbeda daripada menjaga rentang waktu bersama dalam shard. Kueri yang melibatkan rentang waktu umumnya referensi waktu, misalnya, data terbaru. Jenis distribusi hash ini mengarah ke overhead jaringan.

Praktik terbaik

• Jangan pilih tanda waktu sebagai kolom distribusi. Pilih kolom distribusi yang berbeda. Di aplikasi multipenyewa, gunakan ID penyewa, atau dalam aplikasi real-time gunakan ID entitas.
• Gunakan partisi tabel PostgreSQL untuk waktu sebagai gantinya. Gunakan partisi tabel untuk memecah tabel besar data yang diurutkan waktu menjadi beberapa tabel yang diwariskan dengan setiap tabel yang berisi rentang waktu yang berbeda. Mendistribusikan tabel yang dipartisi Postgres membuat pecahan untuk tabel yang diwariskan.

Langkah berikutnya

• Pelajari bagaimana kolokasi antara data terdistribusi membantu kueri berjalan cepat.
• Temukan kolom distribusi tabel terdistribusi, dan kueri diagnostik berguna lainnya.