Bagikan melalui

Node dan tabel dalam Azure Cosmos DB untuk PostgreSQL

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

Simpul

Azure Cosmos DB for PostgreSQL memungkinkan server PostgreSQL (disebut simpul) untuk berkoordinasi satu sama lain dalam arsitektur "berbagi tidak ada," di mana setiap simpul beroperasi secara mandiri. 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.

Koordinator dan pekerja

Setiap kluster memiliki simpul koordinator dan beberapa pekerja. Aplikasi mengirimkan kueri mereka ke simpul koordinator, yang menyampaikannya kepada pekerja yang relevan dan mengakumulasi hasilnya.

Azure Cosmos DB for PostgreSQL memungkinkan administrator database untuk mendistribusikan tabel dan/atau skema, menyimpan baris yang berbeda pada node pekerja yang berbeda. Tabel dan/atau skema terdistribusi adalah kunci performa Azure Cosmos DB for PostgreSQL. Gagal mendistribusikan tabel dan/atau skema meninggalkannya sepenuhnya pada simpul koordinator dan tidak dapat memanfaatkan paralelisme lintas mesin.

Untuk setiap kueri pada tabel terdistribusi, koordinator akan merutekannya ke satu simpul pekerja, atau memparalelkannya di beberapa simpul tergantung pada apakah data yang diperlukan berada pada satu simpul atau lebih. Dengan sharding berbasis skema, koordinator merutekan kueri langsung ke node yang menghosting skema. Dalam sharding berbasis skema dan sharding berbasis baris, koordinator memutuskan apa yang harus dilakukan dengan berkonsultasi dengan tabel metadata. Tabel ini melacak nama DNS dan kesehatan simpul pekerja, dan distribusi data di seluruh simpul.

Jenis tabel

Ada lima jenis tabel dalam kluster, masing-masing disimpan secara berbeda pada simpul dan digunakan untuk tujuan yang berbeda.

Jenis 1: Tabel terdistribusi

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

Azure Cosmos DB for PostgreSQL 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

Azure Cosmos DB for PostgreSQL menggunakan sharding algoritma untuk menetapkan baris ke pecahan. Tugas dibuat secara deterministik berdasarkan nilai kolom tabel yang disebut kolom distribusi. Administrator kluster harus menetapkan 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. Permintaan kueri pada pekerja mana pun dapat mengakses informasi referensi secara lokal, tanpa overhead jaringan untuk meminta baris dari simpul lain. Tabel referensi tidak memiliki kolom distribusi karena tidak perlu membedakan pecahan terpisah per baris.

Tabel referensi biasanya berukuran kecil dan digunakan untuk menyimpan data yang relevan dengan kueri yang berjalan pada setiap simpul pekerja. Contohnya adalah nilai yang disebutkan seperti status pesanan atau kategori produk.

Jenis 3: Tabel lokal

Saat Anda menggunakan Azure Cosmos DB for PostgreSQL, simpul koordinator yang Anda sambungkan adalah database PostgreSQL biasa. Anda dapat membuat tabel biasa pada tingkat koordinator dan memilih untuk tidak membaginya menjadi bagian-bagian kecil.

Kandidat yang tepat untuk tabel lokal adalah tabel administratif kecil yang tidak disertakan dalam kueri gabungan. Contohnya adalah users tabel untuk masuk dan autentikasi aplikasi.

Jenis 4: Tabel terkelola lokal

Azure Cosmos DB for PostgreSQL mungkin secara otomatis menambahkan tabel lokal ke metadata jika ada referensi kunci asing antara tabel lokal dan tabel referensi. Selain itu, tabel yang dikelola secara lokal dapat dibuat secara manual dengan menjalankan create_reference_table dalam fungsi citus_add_local_table_to_metadata pada tabel lokal reguler. Tabel yang ada dalam metadata dianggap sebagai tabel terkelola dan dapat dikueri dari simpul apa pun, Citus tahu untuk merutekan ke koordinator untuk mendapatkan data dari tabel terkelola lokal. Tabel tersebut ditampilkan sebagai tabel lokal dalam tampilan citus_tables.

Jenis 5: Tabel skema

Dengan sharding berbasis skema yang diperkenalkan di Citus 12.0, skema terdistribusi secara otomatis dikaitkan dengan grup kolokasi individu. Tabel yang dibuat dalam skema tersebut secara otomatis dikonversi menjadi tabel terdistribusi terkolokasi tanpa menggunakan kunci shard. Tabel tersebut dianggap sebagai tabel skema dan terlihat sebagai skema dalam view citus_tables.

Pecahan

Bagian sebelumnya menjelaskan bagaimana tabel terdistribusi disimpan sebagai serpihan pada node pekerja. Bagian ini membahas selengkapnya tentang detail yang lebih teknis.

Tabel metadata pg_dist_shard pada koordinator berisi baris untuk setiap pecahan dari setiap tabel terdistribusi dalam sistem. Baris ini mencocokkan ID pecahan 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 koordinator ingin menentukan pecahan mana yang menyimpan baris github_events, simpul tersebut akan melakukan hash pada nilai kolom distribusi dalam baris. Kemudian node memeriksa rentang shard mana yang berisi nilai yang telah di-hash. Rentang ditentukan sedemikian rupa sehingga hasil fungsi hash menjadi gabungan tak saling berpotongan.

Penempatan bagian

Misalkan pecahan 102027 dikaitkan dengan baris yang bersangkutan. Baris tersebut dibaca atau ditulis dalam tabel yang disebut github_events_102027 di salah satu unit kerja. Pekerja yang mana? Itu sepenuhnya ditentukan oleh tabel metadata. Pemetaan pecahan pada 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 berjalan di belakang layar untuk menemukan node yang menyimpan shard 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