Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
BERLAKU UNTUK: Azure Database for PostgreSQL - Server Fleksibel
Kluster Elastis di Server Fleksibel Azure Database for PostgreSQL adalah penawaran terkelola ekstensi Citus sumber terbuka ke PostgreSQL yang memungkinkan sharding horizontal PostgreSQL.
Meskipun Citus hanyalah ekstensi, Citus menghubungkan beberapa instans PostgreSQL. Ketika Server Fleksibel Azure Database for PostgreSQL disebarkan dengan Citus, Azure Database for PostgreSQL menangani manajemen dan konfigurasi beberapa instans PostgreSQL sebagai satu sumber daya. Ini juga secara otomatis mengatur simpul dan membuatnya diketahui oleh ekstensi Citus.
Kluster Elastis di Server Fleksibel menawarkan dua model sharding: sharding berbasis baris dan sharding berbasis skema. Periksa dokumentasi sumber terbuka tentang model sharding, jika Anda ingin mempelajari lebih lanjut.
Sistem
Kluster Elastis terdiri dari satu atau beberapa simpul Azure Database for PostgreSQL Flexible Server. Instans ini secara otomatis dikenal satu sama lain, dan saling terhubung untuk membentuk kluster Citus. Simpul harus memiliki tingkat komputasi dan penyimpanan yang sama, dan dapat diskalakan secara seragam ke tingkat yang lebih tinggi atau lebih rendah.
Kluster Elastis menggunakan instans Server Fleksibel (disebut node) untuk berkoordinasi satu sama lain dalam arsitektur "shared nothing". Simpul dalam kluster secara kolektif menyimpan lebih banyak data dan menggunakan lebih banyak inti CPU daripada yang dimungkinkan pada satu server. Arsitektur ini juga memungkinkan database untuk menskalakan, dengan menambahkan lebih banyak simpul ke kluster.
Menyambungkan ke kluster Anda menggunakan port 5432 akan mendaratkan Anda pada simpul koordinator yang ditunjuk. Kluster Elastis juga memungkinkan Anda memuat koneksi keseimbangan di seluruh kluster, menggunakan metode hash lima tuple, jika Anda terhubung menggunakan port 7432. Menggunakan 7432 Anda masih dapat mendarat di simpul yang saat ini ditetapkan sebagai koordinator. Untuk operasi di seluruh kluster tertentu, seperti mendistribusikan tabel, Anda mungkin diharuskan untuk terhubung melalui port 5432. Kami sangat menyarankan Anda untuk selalu terhubung pada port 5432, ketika Anda berencana untuk melakukan peningkatan skema aplikasi dan perubahan serupa.
Tidak seperti Cosmos DB for PostgreSQL, alamat node tidak diekspos secara eksternal. Jika Anda melihat tabel metadata Citus seperti pg_dist_node
, maka Anda mungkin melihat semua simpul memiliki alamat IP yang sama seperti dalam contoh 10.7.0.254
tetapi nomor port yang berbeda.
select nodeid, nodename, nodeport from pg_dist_node;
nodeid | nodename | nodeport
--------+------------+----------
1 | 10.7.0.254 | 7000
2 | 10.7.0.254 | 7001
(2 rows)
Dalam infrastruktur Azure, simpul ini hidup di komputer virtual yang berbeda meskipun tampaknya merupakan port yang berbeda pada komputer yang sama.
Untuk mempelajari lebih lanjut tentang Citus, Anda dapat merujuk ke dokumentasi proyek sumber terbuka resmi.
Secara default, tabel dan skema yang dibuat dengan Citus tidak didistribusikan secara otomatis di antara kluster. Anda perlu memutuskan model sharding, dan memutuskan untuk mendistribusikan skema atau memutuskan untuk mendistribusikan data tabel Anda dengan sharding berbasis baris.
Untuk setiap kueri pada tabel terdistribusi, simpul yang dikueri merutekannya ke satu simpul atau menyejajarkannya di beberapa simpul. Keputusan tergantung pada apakah data yang diperlukan hidup pada satu node atau di beberapa. Dengan sharding berbasis skema, koordinator merutekan kueri langsung ke node yang menghosting skema. Dalam keduanya, sharding berbasis skema dan sharding berbasis baris, simpul memutuskan apa yang harus dilakukan dengan berkonsultasi dengan tabel metadata. Tabel ini melacak lokasi dan kesehatan simpul, dan distribusi data di seluruh simpul.
Setelah data didistribusikan menggunakan salah satu model sharding, Anda dapat terhubung ke salah satu simpul untuk melakukan operasi DML (Bahasa Modifikasi Data) (SELECT, UPDATE, INSERT, DELETE). Semua simpul berisi metadata yang diperlukan untuk menemukan data yang diperlukan untuk kueri dan dapat memperolehnya untuk menjawab kueri.
Operasi DDL (Bahasa Definisi Data) dan operasi luas kluster saat ini terbatas pada simpul yang memegang peran koordinator. Pastikan Anda melakukan operasi DDL dan seluruh kluster dengan menyambungkan ke port 5432, alih-alih menggunakan port 7432.
Anda dapat menskalakan Kluster Elastis dengan menambahkan simpul baru dan menyeimbangkan ulang data di dalamnya. Penyeimbangan ulang adalah operasi online dan tidak memblokir beban kerja yang sedang berjalan.
Pecahan
Bagian sebelumnya menjelaskan bagaimana tabel terdistribusi disimpan sebagai pecahan pada simpul pekerja. Bagian ini membahas detail teknis selengkapnya tentang pecahan ini.
Tabel pg_dist_shard
metadata berisi baris untuk setiap pecahan setiap tabel terdistribusi dalam sistem. Baris cocok dengan pengidentifikasi shard (shardid
) dengan rentang bilangan bulat dalam ruang hash (shardminvalue
, shardmaxvalue
).
SELECT * from pg_dist_shard;
logicalrelid | shardid | shardstorage | shardminvalue | shardmaxvalue
---------------+---------+--------------+---------------+---------------
github_events | 102026 | t | 268435456 | 402653183
github_events | 102027 | t | 402653184 | 536870911
github_events | 102028 | t | 536870912 | 671088639
github_events | 102029 | t | 671088640 | 805306367
(4 rows)
Jika simpul ingin menentukan shard mana yang menyimpan baris github_events
, simpul tersebut akan menghapus nilai kolom distribusi dalam baris. Kemudian node memeriksa rentang pecahan mana yang berisi nilai yang didigest. Rentang ditentukan sehingga gambar fungsi hash menjadi kesatuan uraian.
Penempatan pecahan
Misalkan pecahan 102027 dikaitkan dengan baris yang bersangkutan. Baris tersebut dibaca atau ditulis dalam tabel yang disebut github_events_102027
di salah satu pekerja. Dengan informasi yang disimpan dalam tabel metadata, ekstensi menentukan apa pekerja tertentu tersebut. Pemetaan pecahan pada pekerja dikenal sebagai penempatan pecahan.
Simpul menulis ulang kueri menjadi fragmen yang merujuk ke tabel tertentu seperti github_events_102027
dan menjalankan fragmen tersebut pada pekerja yang sesuai. Berikut adalah contoh kueri yang dijalankan di belakang layar untuk menemukan simpul yang memegang shard dengan pengidentifikasi 102027.
SELECT
shardid,
node.nodename,
node.nodeport
FROM pg_dist_placement placement
JOIN pg_dist_node node
ON placement.groupid = node.groupid
AND node.noderole = 'primary'::noderole
WHERE shardid = 102027;
┌─────────┬───────────┬──────────┐
│ shardid │ nodename │ nodeport │
├─────────┼───────────┼──────────┤
│ 102027 │ localhost │ 5433 │
└─────────┴───────────┴──────────┘
Konten terkait
- Model sharding pada Kluster Elastis di Azure Database for PostgreSQL - Server Fleksibel.
- Jenis tabel pada Kluster Elastis di Azure Database for PostgreSQL - Server Fleksibel.
- Tanya jawab umum tentang Kluster Elastis dengan batasan Azure Database for PostgreSQL.