PolarDB：Arsitektur Teknis IMCI

Tim PolarDB menggunakan mekanisme daftar putih untuk mencapai tujuan kompatibilitas. Mekanisme daftar putih digunakan dengan mempertimbangkan faktor-faktor berikut:

• Keterbatasan sumber daya sistem yang tersedia, terutama sumber daya memori.

  Dalam kebanyakan kasus, indeks kolom tidak dibuat pada semua kolom di semua tabel database. Saat pernyataan query perlu menggunakan kolom yang tidak ada di penyimpanan kolom, pernyataan tersebut tidak dapat dieksekusi pada penyimpanan kolom.

• Performa.

  Tim PolarDB menulis ulang mesin eksekusi SQL berorientasi kolom yang melibatkan semua operator eksekusi fisik dan komputasi ekspresi. Cakupan skenario yang didukung tidak memadai dibandingkan dengan penyimpanan baris asli MySQL. Saat pernyataan SQL yang diterbitkan berisi beberapa fragmen operator atau jenis kolom yang tidak didukung oleh mesin eksekusi IMCI, mesin eksekusi harus dapat mengidentifikasi dan mencegat pernyataan SQL, dan beralih kembali ke penyimpanan baris untuk eksekusi.

Mekanisme daftar putih memeriksa tipe data, operator, dan ekspresi dalam pernyataan SQL dan skenario lainnya, seperti skenario di mana multi-pernyataan tidak didukung.

MySQL telah berevolusi selama beberapa dekade. MySQL mendukung berbagai jenis kolom dan sintaksis SQL yang kaya. Di IMCI, fokus awalnya adalah mengoptimalkan masalah kinerja SQL yang paling umum dalam pernyataan query analitik. Bahkan jika skenario yang berlaku untuk IMCI terbatas, sintaksis SQL yang didukung oleh IMCI lebih kompatibel dengan MySQL daripada sebagian besar sistem OLAP. Saat pernyataan SQL yang diterbitkan tidak dapat dieksekusi pada penyimpanan kolom, pernyataan SQL langsung jatuh kembali ke mesin eksekusi asli MySQL. Dengan cara ini, kompatibilitas 100% dengan MySQL tercapai.

Tujuan konversi rencana adalah untuk mengonversi representasi pohon sintaksis abstrak (AST) dari rencana eksekusi logis asli di MySQL menjadi rencana logis IMCI. Setelah rencana logis IMCI dihasilkan, rencana fisik dihasilkan setelah serangkaian optimasi.

Konversi rencana sederhana dan langsung. Pengguna hanya perlu menelusuri pohon rencana eksekusi dan mengonversi AST yang dioptimalkan oleh MySQL menjadi struktur pohon dengan operator relasi sebagai simpulnya di IMCI. Dalam proses ini, konversi implisit tipe dilakukan untuk memastikan kompatibilitas dengan sistem tipe fleksibel MySQL.

Proses konversi rencana menghasilkan rencana logis yang setara. Rencana logis tidak dapat dieksekusi oleh executor dan harus dikonversi menjadi rencana fisik untuk eksekusi. Optimizer IMCI menggunakan logika sederhana. Selain beberapa optimasi rencana eksekusi dasar, seperti menentukan apakah akan menggunakan Hash Join atau Nested Loop Join, optimizer terutama digunakan untuk mengonversi subquery yang tidak didukung oleh executor IMCI menjadi operasi Join yang setara.

Berdasarkan dua mesin eksekusi untuk penyimpanan baris dan penyimpanan kolom, optimizer memberikan lebih banyak pilihan saat rencana eksekusi dipilih. Optimizer dapat membandingkan biaya rencana eksekusi penyimpanan baris dengan rencana eksekusi penyimpanan kolom dan menggunakan rencana eksekusi yang memiliki biaya lebih rendah.

Selain fitur eksekusi serial berbasis penyimpanan baris asli MySQL, PolarDB juga mendukung fitur query paralel berbasis penyimpanan baris yang dapat sepenuhnya memanfaatkan daya komputasi multi-core. Oleh karena itu, optimizer PolarDB memilih antara eksekusi serial berbasis penyimpanan baris, query paralel berbasis penyimpanan baris, dan IMCI. Dalam fase iterasi saat ini, optimizer PolarDB mematuhi proses eksekusi berikut:

1. Optimizer PolarDB mengurai pernyataan SQL dan menghasilkan rencana logis. Kemudian, optimizer PolarDB memanggil optimizer asli MySQL untuk melakukan optimasi seperti penyesuaian urutan join. Pada saat yang sama, rencana logis yang diperoleh dilewatkan ke modul kompilasi rencana eksekusi IMCI. Modul mencoba menghasilkan rencana eksekusi penyimpanan kolom. Pernyataan SQL mungkin diblokir oleh daftar putih dan jatuh kembali ke penyimpanan baris untuk eksekusi.

2. PolarDB optimizer menghitung biaya eksekusi berorientasi baris berdasarkan rencana eksekusi penyimpanan baris. Jika biaya melebihi ambang batas tertentu, optimizer PolarDB mencoba mendorong pernyataan SQL ke executor IMCI untuk dieksekusi berdasarkan rencana IMCI.

3. Jika executor IMCI tidak dapat mengeksekusi pernyataan SQL, PolarDB akan mencoba mengkompilasi rencana eksekusi query paralel dan menjalankan pernyataan SQL tersebut. Apabila rencana eksekusi query paralel tidak dapat dihasilkan, baik fitur IMCI maupun query paralel tidak dapat mengeksekusi pernyataan SQL, sehingga pernyataan SQL akan jatuh kembali ke penyimpanan baris untuk dieksekusi.

Strategi di atas didasarkan pada penilaian berikut: Dalam hal kinerja eksekusi, eksekusi serial penyimpanan baris lebih rendah dibandingkan dengan eksekusi paralel penyimpanan baris, yang juga lebih rendah dibandingkan dengan IMCI. Dalam hal kompatibilitas SQL, IMCI lebih rendah dibandingkan dengan eksekusi paralel penyimpanan baris, yang lebih rendah dibandingkan dengan eksekusi serial penyimpanan baris. Namun, situasi aktual lebih kompleks. Sebagai contoh, dalam beberapa kasus, join indeks berbasis paralel menggunakan indeks penyimpanan baris memiliki biaya lebih rendah dibandingkan dengan sort merge join berbasis penyimpanan kolom. IMCI dapat dipilih untuk mengeksekusi pernyataan SQL berdasarkan strategi saat ini.

Mesin eksekusi IMCI menggunakan model gunung berapi klasik dan meningkatkan kinerja eksekusi berdasarkan penyimpanan kolom dan eksekusi vektorisasi.

Dalam hal model gunung berapi, dalam aljabar relasional yang sesuai dengan pohon sintaksis yang dihasilkan oleh SQL, setiap operasi diabstraksikan menjadi operator. Mesin eksekusi membangun seluruh SQL menjadi pohon operator. Pohon query memanggil antarmuka Next() dari atas ke bawah, dan data ditarik dari bawah ke atas. Keuntungan dari metode ini adalah model komputasi sederhana dan langsung. Ini dicapai dengan mengabstraksi operator fisik yang berbeda menjadi iterator. Setiap operator hanya memperhatikan logika internalnya sendiri, mengurangi keterkaitan antar operator, dan memudahkan penulisan mesin eksekusi yang secara logis benar.

• Dalam mesin eksekusi IMCI, setiap operator juga menggunakan fungsi iterator untuk mengakses data. Perbedaannya adalah bahwa setiap panggilan ke iterator mengembalikan batch tetapi bukan satu baris data. Oleh karena itu, mesin eksekusi dapat dianggap sebagai model gunung berapi yang menggunakan model vektorisasi.

  

• Kemampuan eksekusi serial dibatasi oleh faktor-faktor seperti efisiensi komputasi single-core, latensi akses memori, dan latensi I/O. Beberapa operator fisik utama seperti Scan, Join, dan Agg dalam executor IMCI mendukung eksekusi paralel. Operator fisik perlu mendukung paralelisme, dan optimizer IMCI juga perlu mendukung pembuatan rencana eksekusi paralel. Saat optimizer menentukan mode akses tabel, optimizer memutuskan apakah akan mengaktifkan eksekusi paralel berdasarkan jumlah data yang akan diakses. Jika optimizer memutuskan untuk mengaktifkan eksekusi paralel, optimizer merujuk pada serangkaian data status untuk menentukan derajat paralelisme (DOP). Data status mencakup CPU, memori, dan sumber daya I/O yang tersedia di sistem, informasi tentang tugas yang dijadwalkan dan antri, statistik, kompleksitas query, dan parameter yang dapat dikonfigurasi oleh pengguna. Berdasarkan data ini, nilai DOP yang direkomendasikan dihitung untuk operator, dan setiap operator secara internal menggunakan nilai DOP yang sama. Pengguna juga dapat menentukan nilai DOP dengan menggunakan petunjuk.

  

Berdasarkan dua ide optimasi sebelumnya, semua operator eksekusi fisik diimplementasikan ulang, termasuk Table Scan, Hash Join, Nested Loop Join, dan Group By. Dalam contoh berikut, Hash Join digunakan untuk menunjukkan percepatan paralelisasi dan vektorisasi executor. Gambar berikut menunjukkan proses eksekusi Hash Join dalam IMCI.

Eksekusi vektorisasi memecahkan masalah efisiensi eksekusi single-core yang rendah, sementara eksekusi paralel mengatasi hambatan komputasi single-core. Kombinasi keduanya membuat kecepatan eksekusi IMCI beberapa kali lebih cepat daripada eksekusi baris tradisional MySQL.

Dalam skenario AP, SQL sering kali mengandung banyak proses komputasi yang melibatkan satu atau lebih nilai, operator, atau fungsi. Ini termasuk dalam kategori komputasi ekspresi. Evaluasi ekspresi adalah tugas yang intensif komputasi, sehingga efisiensi komputasi ekspresi adalah faktor kunci yang memengaruhi kinerja keseluruhan.

Sistem komputasi ekspresi tradisional MySQL menggunakan metode operasi baris-per-baris, yang umumnya disebut implementasi model iterator. Iterator mengabstraksikan seluruh tabel, dan ekspresi diimplementasikan sebagai struktur pohon. Namun, abstraksi ini membawa kerugian performa karena selama iterasi iterator, pengambilan setiap baris data memicu banyak lapisan pemanggilan fungsi. Pengambilan data baris-per-baris membawa terlalu banyak I/O dan tidak ramah terhadap cache. MySQL menggunakan model iterator pohon karena dibatasi oleh metode akses mesin penyimpanan, membuat sulit untuk mengoptimalkan logika komputasi yang kompleks.

Untuk penyimpanan kolom, karena data di setiap kolom disimpan secara terpisah dan berurutan, komputasi ekspresi dalam kolom tertentu dapat dilakukan dalam batch. Untuk setiap ekspresi, unit input dan outputnya adalah batch. Dalam model pemrosesan batch, proses komputasi dapat dipercepat dengan menggunakan instruksi SIMD.

Sistem ekspresi vektorisasi memiliki dua optimasi utama:

• Sistem ekspresi vektorisasi sepenuhnya memanfaatkan keuntungan dari penyimpanan kolom dan mengganti model iterator dengan model pemrosesan batch. Tim PolarDB menggunakan instruksi SIMD untuk menulis ulang implementasi kernel ekspresi untuk tipe data numerik yang paling umum. Misalnya, semua operasi matematika dasar (+, -, ×, /, dan abs) dari semua tipe numerik termasuk INT, DECIMAL, dan DOUBLE diimplementasikan dengan menggunakan instruksi SIMD yang sesuai. Dengan bantuan set instruksi AVX512, performa operasi single-core ditingkatkan beberapa kali lipat.

  

• Implementasi ekspresi mirip dengan PostgreSQL. Dalam tahap kompilasi dan optimasi SQL, ekspresi IMCI disimpan dalam struktur pohon, yang mirip dengan model iterator baris yang ada. Namun, sebelum eksekusi, pohon ekspresi ditelusuri dalam urutan post-order dan diubah menjadi array satu dimensi untuk penyimpanan. Dalam komputasi berikutnya, pengguna hanya perlu menelusuri array satu dimensi untuk menyelesaikan operasi. Komputasi lebih efisien karena menghilangkan proses rekursif dalam model iterator pohon. Selain itu, metode ini memberikan abstraksi ringkas dari proses komputasi dan memisahkan data dari komputasi, yang cocok untuk komputasi paralel.

Dalam arsitektur kerangka kerja mesin penyimpanan plugin MySQL, solusi paling sederhana untuk menambahkan dukungan penyimpanan kolom adalah dengan mengimplementasikan mesin penyimpanan terpisah, seperti penyimpanan kolom Infobright dan MariaDB. PolarDB menggunakan solusi mengimplementasikan penyimpanan kolom sebagai indeks sekunder InnoDB. Ini terutama didasarkan pada pertimbangan berikut:

• InnoDB secara asli mendukung beberapa indeks. Operasi INSERT, UPDATE, dan DELETE berlaku untuk indeks utama dan semua indeks sekunder pada granularitas baris dan menjamin transaksi. Solusi mengimplementasikan penyimpanan kolom sebagai indeks sekunder dapat menggunakan kembali kerangka kerja pemrosesan transaksi ini.

• Penyimpanan kolom yang diimplementasikan sebagai indeks sekunder dapat menggunakan format pengkodean data yang sama dengan indeks penyimpanan baris lainnya. Salinan memori sudah cukup. Pengguna tidak perlu mempertimbangkan informasi seperti set karakter dan collation.

• Indeks sekunder dapat dikelola secara fleksibel. Pengguna dapat menentukan kolom dalam indeks saat pengguna membuat tabel. Pengguna juga dapat menggunakan pernyataan DDL untuk menambah atau menghapus kolom dalam indeks sekunder dalam operasi berikutnya. Misalnya, pengguna dapat menambahkan kolom INT, FLOAT, dan DOUBLE yang perlu dianalisis ke indeks kolom. Bidang TEXT dan BLOB yang umumnya hanya terlibat dalam query titik tetapi memakan banyak ruang dapat disimpan dalam penyimpanan baris.

• Proses pemulihan crash dapat menggunakan kembali modul log transaksi redo InnoDB untuk memastikan kompatibilitas mulus dengan implementasi yang ada. Ini juga memfasilitasi proses replikasi fisik PolarDB. Indeks penyimpanan kolom dapat dihasilkan pada node RO independen atau node standby untuk menyediakan layanan analitik.

• Indeks sekunder memiliki siklus hidup yang sama dengan indeks utama. Pengguna dapat dengan mudah mengelola indeks sekunder.

  

Sebagaimana ditunjukkan pada gambar sebelumnya, semua indeks utama dan sekunder dalam PolarDB diimplementasikan sebagai pohon B+. Indeks kolom adalah indeks menurut definisi, tetapi merupakan indeks virtual yang digunakan untuk menangkap operasi penambahan, penghapusan, dan modifikasi pada kolom yang dicakup oleh indeks.

Untuk tabel sebelumnya, indeks utama berisi lima kolom (C1, C2, C3, C4, dan C5) data, dan indeks sekunder berisi dua kolom (C2 dan C1) data. Dalam indeks sekunder umum, C2 dan C1 dikodekan menjadi satu baris dan disimpan dalam pohon B+. Indeks penyimpanan kolom berisi tiga kolom (C2, C3, dan C4) data. Dalam penyimpanan fisik aktual, ketiga kolom tersebut dipisahkan dan disimpan secara independen. Setiap kolom diubah menjadi format penyimpanan kolom berdasarkan urutan penulisan mereka.

Keuntungan lain dari mengimplementasikan penyimpanan kolom sebagai indeks sekunder adalah bahwa implementasi teknik executor sangat sederhana. Istilah indeks covering sudah ada di MySQL, yang berarti bahwa semua kolom yang diperlukan oleh query disimpan dalam indeks sekunder. Data dalam indeks sekunder ini dapat langsung digunakan untuk memenuhi persyaratan query. Dibandingkan dengan indeks utama, penggunaan indeks sekunder dapat sangat mengurangi jumlah data yang dibaca dan dengan demikian meningkatkan kinerja query. Saat semua kolom yang diperlukan untuk query dicakup oleh indeks kolom, percepatan penyimpanan kolom dapat meningkatkan kinerja query puluhan bahkan ratusan kali lipat.

Setiap kolom dalam indeks kolom disimpan dalam format tidak berurutan dan menggunakan mode penulisan append. Reklamasi ruang dicapai dengan menggunakan penghapusan label dan kompaksi asinkron di latar belakang. Implementasi spesifik memiliki poin-poin kunci berikut:

• Rekaman dalam indeks kolom diorganisasikan berdasarkan grup baris. Setiap grup baris berisi 64.000 baris. Kolom berbeda dalam setiap grup baris dikemas untuk membentuk paket data.

• Setiap grup baris menggunakan mode penulisan append, dan paket data yang termasuk dalam setiap kolom juga menggunakan mode penulisan append. Untuk indeks kolom, hanya grup baris aktif yang bertanggung jawab untuk menerima penulisan baru. Saat grup baris penuh, ia membeku. Semua paket data yang terkandung dalam grup baris dikompresi dan disimpan di disk, dan statistik setiap blok data dicatat untuk memfasilitasi penyaringan.

• Setiap baris baru yang ditulis ke grup baris berorientasi kolom diberi ID baris untuk penempatan. Sistem menghitung posisi untuk semua kolom yang termasuk dalam baris dengan menggunakan ID baris. Pada saat yang sama, sistem memelihara indeks pemetaan dari kunci utama ke ID baris untuk mendukung operasi penghapusan dan modifikasi berikutnya.

• Operasi pembaruan diimplementasikan berdasarkan penghapusan label. Untuk melakukan operasi penghapusan, pengguna dapat secara langsung menentukan bitmap. Untuk melakukan operasi pembaruan, pengguna dapat menghitung posisi asli berdasarkan ID baris, menentukan label penghapusan, dan kemudian menulis data baru ke grup baris aktif.

• Saat jumlah rekaman tidak valid dalam grup baris melebihi ambang batas tertentu, kompaksi asinkron dipicu di latar belakang. Di satu sisi, kompaksi asinkron digunakan untuk mereklamasi ruang. Di sisi lain, kompaksi asinkron dapat membuat penyimpanan data efektif lebih kompak dan meningkatkan efisiensi query analitik.

  

Metode organisasi data ini memenuhi persyaratan pemindaian batch dan penyaringan berdasarkan kolom selama query analitik. Selain itu, dampak pada operasi transaksi TP sangat kecil. Untuk operasi tulis, pengguna hanya perlu menambahkan data ke memori berdasarkan kolom. Untuk operasi penghapusan, pengguna hanya perlu menentukan label penghapusan. Operasi pembaruan melibatkan penghapusan label dan penulisan append. Penyimpanan kolom mendukung pembaruan tingkat transaksi tanpa mengurangi kinerja OLTP.

Operasi baris-ke-kolom dilakukan dalam kasus-kasus berikut:

• Kasus 1: Pernyataan DDL digunakan untuk membuat indeks kolom pada beberapa kolom jika pengguna memiliki persyaratan analitik untuk tabel yang ada. Pengguna perlu memindai data di seluruh tabel untuk membuat indeks kolom.

• Kasus 2: Operasi baris-ke-kolom dilakukan pada kolom yang terlibat dalam operasi transaksi.

Dalam kasus konversi tabel penuh dari baris ke kolom, pengguna dapat memanfaatkan pemindaian paralel untuk memindai kunci utama InnoDB dan mengonversi semua kolom terkait ke format penyimpanan kolom secara bergantian. Proses ini sangat cepat, hanya dibatasi oleh throughput I/O dan sumber daya CPU yang tersedia di server. Operasi ini merupakan proses DDL online dan tidak menghalangi jalannya layanan online.

Setelah indeks kolom dibuat pada tabel, semua transaksi pembaruan secara bersamaan memperbarui data berorientasi baris dan berorientasi kolom untuk memastikan konsistensi transaksional data berorientasi baris dan kolom. Gambar berikut menunjukkan perbedaan saat fitur IMCI dinonaktifkan dan diaktifkan.

• Saat fitur IMCI dinonaktifkan, pembaruan semua baris oleh transaksi dikunci terlebih dahulu. Kemudian, halaman data dimodifikasi. Semua catatan yang terkunci dibuka sekaligus sebelum transaksi dikomit.

• Setelah fitur IMCI diaktifkan, sistem transaksi membuat cache pembaruan untuk penyimpanan kolom. Saat semua halaman data dimodifikasi, operasi pembaruan penyimpanan kolom dicatat. Sebelum transaksi berakhir dan catatan yang terkunci dibuka, cache pembaruan diterapkan ke sistem penyimpanan kolom.

Untuk permintaan OLTP umum, waktu yang dihabiskan untuk memperbarui halaman data memori hanya mencakup sebagian kecil dari proses operasi transaksi. Oleh karena itu, metode ini memiliki dampak yang sangat kecil pada latensi transaksi TP. Untuk transaksi besar yang beroperasi pada sejumlah besar baris, pembaruan ke indeks kolom diterapkan langsung ke penyimpanan kolom secara real-time, tetapi pembaruan tidak terlihat publik sebelum transaksi dikomit. Ini memastikan bahwa latensi komit transaksi besar meningkat dalam rentang waktu yang sangat kecil. Untuk lebih mengurangi dampak pada kinerja TP, pembaruan ke indeks kolom dapat diterapkan secara asinkron ke penyimpanan kolom jika query AP tidak memiliki persyaratan tinggi untuk ketepatan waktu data.

Penyimpanan kolom menyediakan tingkat isolasi transaksi yang sama dengan penyimpanan baris. Untuk setiap operasi tulis, setiap baris dalam grup baris mencatat ID transaksi yang memodifikasi baris tersebut. Untuk setiap operasi penghapusan label dalam bitmap penghapusan, ID transaksi operasi tersebut juga dicatat. Dengan menulis dan menghapus ID transaksi, query AP dapat memperoleh snapshot global yang konsisten dengan cara yang sangat ringan.

Seperti dapat dilihat dari format penyimpanan sebelumnya, semua paket data dalam IMCI tidak berurutan dan menggunakan mode penulisan append. Oleh karena itu, tidak mungkin untuk menyaring data yang tidak memenuhi persyaratan seakurat indeks terurut normal InnoDB. Dalam IMCI, pengguna dapat menggunakan statistik untuk menyaring blok data guna mengurangi harga satuan akses data.

• Saat setiap paket data aktif selesai menulis, sistem melakukan komputasi terlebih dahulu. Kemudian, sistem menghasilkan informasi, termasuk nilai minimum, nilai maksimum, jumlah nilai, jumlah nilai null, dan jumlah total rekaman, dalam paket data. Semua informasi dipelihara di area metadata paket data dan berada di memori. Karena operasi penghapusan data terlibat dalam paket data beku, pembaruan dan pemeliharaan statistik dilakukan di latar belakang.

• Untuk permintaan query, paket data diklasifikasikan menjadi paket data relevan, tidak relevan, dan mungkin relevan berdasarkan kondisi query. Ini mengurangi akses blok data aktual. Untuk beberapa operasi query agregat seperti count dan sum, pengguna dapat melakukan operasi sederhana pada nilai statistik yang telah dihitung sebelumnya. Blok data ini bahkan tidak perlu didekompresi.

Skema indeks kasar berdasarkan statistik tidak terlalu ramah untuk beberapa query yang perlu secara akurat menempati beberapa data. Namun, dalam mesin penyimpanan hibrid baris-kolom, indeks kolom hanya perlu membantu mempercepat query yang melibatkan pemindaian sejumlah besar data. Dalam skenario ini, IMCI memiliki keuntungan signifikan. Untuk query SQL yang hanya mengakses sejumlah kecil data, optimizer biasanya menggunakan model biaya untuk menghitung solusi yang lebih hemat biaya berdasarkan penyimpanan baris.

Solusi penyimpanan hibrid baris-kolom PolarDB mendukung query AP dan TP dalam satu kluster. Namun, banyak layanan memiliki beban OLTP tinggi, dan beban OLAP tiba-tiba dapat mengganggu latensi respons layanan TP. Oleh karena itu, perlu mendukung isolasi beban dalam database HTAP. Dengan arsitektur write-once-read-many PolarDB, pengguna dapat dengan mudah mengisolasi beban AP dan TP. Berdasarkan arsitektur teknis PolarDB, mode penyebaran berikut didukung:

• Mode 1: Solusi penyimpanan hibrid baris-kolom diaktifkan pada node read/write (RW). Mode ini mendukung query AP ringan. Mode ini cocok saat beban TP utamanya digunakan dan permintaan AP relatif sedikit. Pengguna juga dapat menggunakan mode ini jika pengguna ingin menggunakan PolarDB untuk menanyakan laporan dan data berasal dari impor data batch.

• Mode 2: Node RW mendukung beban OLTP, dan node RO tipe AP dimulai untuk mengaktifkan solusi penyimpanan hibrid baris-kolom guna mendukung query. Dalam mode ini, sumber daya CPU dapat diisolasi sepenuhnya, dan semua memori node RO tipe AP dapat dialokasikan ke penyimpanan kolom dan executor. Namun, karena penyimpanan bersama yang sama digunakan, I/O terpengaruh.

• Mode 3: Baik node RW maupun RO mendukung beban OLTP, dan solusi penyimpanan hibrid baris-kolom diaktifkan pada node standby terpisah untuk mendukung query AP. Karena node standby menggunakan kluster penyimpanan bersama independen, mode ini juga dapat mencapai isolasi sumber daya I/O, selain isolasi CPU dan memori yang dicapai dalam Mode 2.

Selain arsitektur penyebaran berbeda yang mendukung tingkat isolasi sumber daya yang berbeda, dalam PolarDB, degree of parallelism otomatis (Auto DOP) didukung dalam beberapa query besar yang perlu dieksekusi secara paralel. Mekanisme ini mempertimbangkan beban sistem saat ini dan sumber daya CPU dan memori yang tersedia, serta membatasi sumber daya yang dapat digunakan oleh query tunggal. Ini mencegah query tunggal mengonsumsi terlalu banyak sumber daya dan memengaruhi pemrosesan permintaan lainnya.