Simpul dan tabel di Azure Database for PostgreSQL - Hyperscale (Citus)

  • Artikel
  • 3 menit untuk membaca

BERLAKU UNTUK: Azure Database for PostgreSQL - Hyperscale (Citus)

Simpul

Jenis hosting Hyperscale (Citus) memungkinkan Azure Database for PostgreSQL server (disebut simpul) untuk berkoordinasi satu sama lain dalam arsitektur "tidak berbagi apa-apa". Simpul dalam grup server secara kolektif menyimpan lebih banyak data dan menggunakan lebih banyak core CPU daripada yang dimungkinkan pada satu server. Arsitektur juga memungkinkan database untuk menskalakan dengan menambahkan lebih banyak simpul ke grup server.

Koordinator dan pekerja

Setiap grup server memiliki simpul koordinator dan beberapa pekerja. Aplikasi mengirimkan kueri mereka ke simpul koordinator, yang menyampaikannya kepada pekerja yang relevan dan mengakumulasi hasilnya. Aplikasi tidak dapat tersambung langsung ke pekerja.

Hyperscale (Citus) memungkinkan administrator database untuk mendistribusikan tabel, menyimpan baris yang berbeda pada simpul pekerja yang berbeda. Tabel terdistribusi adalah kunci performa Hyperscale (Citus). Gagal mendistribusikan tabel akan membuat tabel sepenuhnya berada pada simpul koordinator dan tidak dapat mengambil keuntungan dari paralelisme lintas mesin.

Untuk setiap kueri pada tabel terdistribusi, koordinator merutekannya ke satu simpul pekerja, atau menyejajarkannya di beberapa simpul tergantung pada apakah data yang diperlukan ada pada satu simpul atau lebih. Koordinator memutuskan apa yang harus dilakukan dengan mengkonsultasikan tabel metadata. Tabel ini melacak nama DNS dan kesehatan simpul pekerja, dan distribusi data di seluruh simpul.

Jenis tabel

Ada tiga jenis tabel dalam grup server Hyperscale (Citus), masing-masing disimpan secara berbeda pada simpul dan digunakan untuk tujuan berbeda.

Jenis 1: Tabel terdistribusi

Jenis pertama, dan yang paling umum, adalah tabel terdistribusi. Tabel ini terlihat seperti tabel normal untuk pernyataan SQL, tetapi secara horizontal dipartisi di seluruh simpul pekerja. Ini artinya bahwa baris tabel disimpan pada simpul yang berbeda, dalam tabel fragmen yang disebut pecahan.

Hyperscale (Citus) tidak hanya menjalankan pernyataan SQL tetapi DDL di seluruh kluster. Mengubah skema kaskade tabel terdistribusi untuk memperbarui semua pecahan tabel di seluruh pekerja.

Kolom distribusi

Hyperscale (Citus) menggunakan sharding algoritmik untuk menetapkan baris ke pecahan. Tugas dibuat secara deterministik berdasarkan nilai kolom tabel yang disebut kolom distribusi. Administrator kluster harus menunjuk kolom ini saat mendistribusikan tabel. Membuat pilihan yang tepat sangat penting untuk performa dan fungsionalitas.

Jenis 2: Tabel referensi

Tabel referensi adalah jenis tabel terdistribusi yang seluruh isinya terkonsentrasi ke dalam satu pecahan. Pecahan direplikasi pada setiap pekerja. Kueri pada pekerja mana pun dapat mengakses informasi referensi secara lokal, tanpa overhead jaringan dari baris yang meminta dari simpul lain. Tabel referensi tidak memiliki kolom distribusi karena tidak perlu membedakan pecahan terpisah per baris.

Tabel referensi biasanya kecil dan digunakan untuk menyimpan data yang relevan dengan kueri yang berjalan pada simpul pekerja mana pun. Misalnya nilai enumerasi seperti status pesanan atau kategori produk.

Jenis 3: Tabel lokal

Ketika Anda menggunakan Hyperscale (Citus), simpul koordinator yang Anda sambungkan adalah database PostgreSQL biasa. Anda dapat membuat tabel biasa pada koordinator dan memilih untuk tidak memecahnya.

Kandidat yang baik untuk tabel lokal adalah tabel administratif kecil yang tidak ikut dalam kueri gabungan. Misalnya tabel pengguna untuk masuk dan autentikasi aplikasi.

Pecahan

Bagian sebelumnya menjelaskan bagaimana tabel terdistribusi disimpan sebagai pecahan pada simpul pekerja. Bagian ini membahas detail teknis lebih lanjut.

Tabel metadata pg_dist_shard pada koordinator berisi baris untuk setiap pecahan dari setiap tabel terdistribusi dalam sistem. Baris ini cocok dengan ID pecahan dengan rentang bilangan bulat dalam ruang terpecah (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 koordinator ingin menentukan pecahan mana yang memegang baris github_events, itu memecah nilai kolom distribusi dalam baris. Kemudian node memeriksa rentang pecahan mana yang berisi nilai hash. Rentang didefinisikan sehingga gambar fungsi hash adalah menggabungkan pecahan.

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. Pekerja yang mana? Itu sepenuhnya ditentukan oleh tabel metadata. Pemetaan pecahan kepada pekerja dikenal sebagai penempatan pecahan.

Simpul koordinator menulis ulang kueri ke dalam 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 menyimpan pecahan ID 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 │
└─────────┴───────────┴──────────┘

Langkah berikutnya