All Products
Search
Document Center

PolarDB:Distribusi transparan

Last Updated:Aug 13, 2026

Topik ini menjelaskan apa itu distribusi transparan di PolarDB-X dan cara kerjanya.

Informasi latar belakang

Saat aplikasi yang berjalan di atas database MySQL stand-alone konvensional mengalami bottleneck sumber daya atau kinerja, pengguna sering melakukan upgrade ke database terdistribusi sebagai solusi yang terbukti efektif untuk memenuhi kebutuhan bisnis mereka.

Namun setelah upgrade tersebut, pengguna umumnya menghadapi tantangan berikut dalam penggunaan database terdistribusi:

  • Bagaimana data didistribusikan di seluruh database?

  • Tabel mana yang perlu dipartisi secara horizontal? Bagaimana tabel tersebut dipartisi dan kunci partisi apa yang harus digunakan? Berapa jumlah partisi yang tepat untuk suatu tabel?

  • Node data mana yang menyimpan data saya? Bagaimana menangani ketidakseimbangan sumber daya?

Untuk mengatasi masalah-masalah ini, pengguna perlu memahami cara kerja database terdistribusi serta skenario penggunaannya. Pemanfaatan database terdistribusi secara optimal tidaklah mudah.

Guna mempermudah penggunaan dan migrasi dari database stand-alone ke database terdistribusi, Alibaba Cloud menyediakan fitur distribusi transparan in-kernel di PolarDB-X 2.0.

Catatan

Fitur ini hanya mendukung database dalam mode AUTO.

Apa itu distribusi transparan?

Fitur distribusi transparan pada PolarDB-X 2.0 menyediakan kebijakan partisi default dan kebijakan distribusi data default kepada pengguna, sehingga memungkinkan mereka menghubungkan aplikasi ke database terdistribusi guna meningkatkan kinerja tanpa perlu memodifikasi aplikasi tersebut.

Kemampuan inti distribusi transparan pada dasarnya membantu pengguna menentukan skema partisi untuk suatu tabel dan distribusi datanya di seluruh node data (DNs) PolarDB-X.

Bagi pengguna yang bermigrasi dari database MySQL stand-alone konvensional ke database terdistribusi PolarDB-X, pernyataan SQL untuk membuat tabel bisnis terbagi menjadi dua kategori:

  • Kategori satu: Pernyataan SQL tidak secara eksplisit menggunakan sintaks partisi MySQL. Tabel yang dibuat dengan pernyataan SQL ini disebut tabel MySQL non-partisi.

  • Kategori dua: Pernyataan SQL secara eksplisit menggunakan sintaks partisi MySQL, misalnya pernyataan SQL yang mengandung Partition By Hash(id). Tabel yang dibuat dengan pernyataan SQL ini disebut tabel MySQL partisi.

Jika pengguna membuat tabel menggunakan pernyataan kategori dua, mereka dianggap telah memilih skema partisi untuk bisnisnya karena pernyataan tersebut secara eksplisit menggunakan sintaks partisi MySQL. Tabel-tabel ini juga dianggap sebagai tabel partisi manual oleh PolarDB-X. Partisi dalam tabel-tabel ini didistribusikan secara merata ke DNs untuk mencapai beban seimbang.

Tabel yang dibuat dari pernyataan kategori satu jumlahnya sangat banyak dan menjadi fokus utama distribusi transparan PolarDB-X, yang bertujuan membantu pengguna memilih skema partisi dan skema distribusi data.

Fitur distribusi transparan PolarDB-X menyediakan tiga skema partisi dan distribusi data untuk tabel yang dibuat dari pernyataan kategori satu:

  • Tabel non-partisi: Dalam skema ini, tabel MySQL tetap non-partisi di PolarDB-X, yang menetapkan DNs tetap untuk tabel-tabel tersebut. Dengan demikian, pengguna dapat menggunakannya sebagaimana tabel MySQL stand-alone konvensional.

  • Tabel sharded: Dalam skema ini, tabel MySQL tetap non-partisi di PolarDB-X, namun secara otomatis di-shard dan didistribusikan ke DNs.

  • Tabel partisi: Dalam skema ini, tabel MySQL non-partisi secara otomatis dipartisi oleh PolarDB-X.

    • Tabel primary dipartisi secara horizontal berdasarkan HASH pada primary key.

    • Indeks global digunakan secara default, dan partisi horizontal dilakukan berdasarkan kolom indeks.

Oleh karena itu, fitur distribusi transparan beroperasi dalam tiga mode berdasarkan skema partisi dan distribusi data tabel:

  • Sharding tabel

  • Partisi otomatis

  • Partisi manual (default)

Mode kerja distribusi transparan

Anda dapat memilih mode kerja yang sesuai dengan kebutuhan bisnis Anda berdasarkan skema partisi atau distribusi data yang diinginkan saat menghubungkan aplikasi ke database terdistribusi, terutama saat pertama kali menghubungkan aplikasi ke database semacam itu.

Tabel berikut menjelaskan mode kerja serta kelebihan dan kekurangannya.

Mode kerja

Deskripsi

Kelebihan dan kekurangan

Sharding tabel

Untuk semua tabel dalam database logis:

  • Jika tabel logis tidak secara eksplisit menggunakan sintaks partisi MySQL, tabel tersebut tidak dipartisi dan didistribusikan secara acak ke DNs PolarDB-X untuk load balancing.

  • Jika tabel logis secara eksplisit menggunakan sintaks partisi MySQL, tabel tersebut dipartisi dan setiap partisi didistribusikan secara merata ke DNs.

Kelebihan:

  • Mudah digunakan tanpa modifikasi aplikasi.

  • Kompatibilitas SQL terbaik.

  • Kedekatan maksimal dengan MySQL dalam hal kinerja kueri SQL.

Kekurangan:

  • Beban tidak seimbang di antara DNs karena frekuensi akses tabel dan jumlah baris yang dipindai berbeda-beda.

Partisi otomatis

Jika tabel dalam database logis tidak secara eksplisit menggunakan sintaks partisi MySQL:

  • Tabel-tabel tersebut secara otomatis dipartisi secara horizontal berdasarkan primary key-nya.

  • Indeks global digunakan secara otomatis, dan partisi horizontal dilakukan berdasarkan kolom indeks.

Kelebihan:

  • Mudah digunakan dengan modifikasi aplikasi yang hampir nol.

  • Skalabilitas horizontal.

Kekurangan:

  • Throughput write menurun karena perlu memelihara beberapa indeks global.

  • Beban tidak seimbang di antara DNs dan skalabilitas buruk akibat hot spot indeks global yang bervariasi.

Partisi manual (default)

Untuk semua tabel dalam database logis:

  • Jika tabel logis tidak secara eksplisit menggunakan sintaks partisi MySQL, tabel tersebut dianggap sebagai tabel non-partisi dan ditugaskan ke DN yang sama.

  • Jika tabel logis secara eksplisit menggunakan sintaks partisi MySQL, tabel tersebut dipartisi dan setiap partisi didistribusikan secara merata ke DNs.

Kelebihan:

  • Dapat disesuaikan dengan berbagai skenario bisnis.

  • Memberikan kinerja optimal, load balancing, dan skalabilitas linear.

Kekurangan:

  • Lebih sulit dipahami dan digunakan.

  • Memerlukan modifikasi aplikasi.

Catatan

Ketiga mode kerja tersebut dapat dikombinasikan. Misalnya, Anda dapat menggabungkan partisi manual dengan sharding tabel atau partisi otomatis untuk memenuhi berbagai kebutuhan.

Untuk informasi lebih lanjut mengenai skenario yang cocok untuk masing-masing mode, lihat Best Practices.