Data Management：Perbandingan solusi perubahan skema tanpa kunci

Item

Desain Berbasis Pemicu

Desain Tanpa Pemicu

Overhead Database

Pemicu adalah prosedur tersimpan. Seiring perkembangan bisnis, lebih banyak operasi DML diperlukan, meningkatkan overhead yang dihasilkan oleh penggunaan pemicu, terutama pada jam sibuk.

Tidak ada overhead berbasis pemicu yang dihasilkan.

Alat tanpa pemicu bertindak sebagai server replikasi yang membaca log biner database utama dan sekunder serta menerapkan peristiwa tabel asli ke tabel sementara. Proses ini tidak terkait dengan perubahan pada tabel asli dan tidak memerlukan prosedur tersimpan dalam database.

Persaingan Kunci

Pemicu mengelompokkan operasi yang dilakukan pada tabel asli dan tabel sementara dalam transaksi yang sama. Dalam hal ini, operasi konkuren pada kedua tabel mungkin memperoleh kunci pada objek yang sama, memperparah persaingan kunci. Selain itu, alat berbasis pemicu harus menyalin data dan mengubah data secara bersamaan, yang lebih memperparah persaingan kunci.

Proses penulisan data ke tabel sementara dipisahkan dari proses penulisan data ke tabel asli, mencegah persaingan kunci.

Selain itu, untuk mencegah dan mengurangi persaingan kunci secara logis, DMS menyalin dan memperbarui data di tabel sementara pada periode waktu yang berbeda. Ini memengaruhi efisiensi dalam mengubah tabel tetapi secara signifikan mengurangi beban database.

Penanganan Pengecualian

Dalam desain berbasis pemicu, pemicu harus terus berjalan dan tidak dapat dihentikan. Meskipun pada jam sibuk, pengecualian, atau latensi dalam sinkronisasi antara database utama dan sekunder, pemicu tidak dapat dibatalkan kapan saja selama perubahan skema. Pembatalan paksa mengganggu perubahan skema atau menyebabkan kehilangan data, memengaruhi akurasi data di Tabel A_gst.

Fitur pemisahan memungkinkan Anda untuk menjeda atau memperlambat thread yang digunakan untuk mendapatkan log biner kapan saja. Selama jam sibuk atau ketika latensi dalam sinkronisasi antara database utama dan sekunder besar, throttling dapat diaktifkan untuk aplikasi yang sedang berjalan, membantu mencegah masalah lebih lanjut.

Verifikasi Keandalan

Untuk memverifikasi solusi, Anda mungkin ingin mengetahui durasi tugas. Jika solusi berbasis pemicu mengeksekusi pernyataan SQL untuk mereplikasi data, Anda dapat membuat dan menggunakan pemicu untuk mensimulasikan replikasi data pada database sekunder.

Namun, ketika data direplikasi berdasarkan baris, tidak diperlukan pemicu pada database sekunder karena pemicu hanya berjalan pada database utama, dan database sekunder langsung menerapkan perubahan. Selain itu, meskipun pernyataan SQL dieksekusi untuk mereplikasi data, Anda tidak dapat mensimulasikan proses replikasi konkuren pada database utama karena MySQL menggunakan satu thread untuk memainkan kembali proses replikasi. Oleh karena itu, masalah konkurensi dan penguncian tidak dapat diverifikasi atau diuji.

Tidak ada perbedaan antara operasi berbasis log biner dan operasi online pada database utama dan sekunder. Selain itu, saat Anda mensimulasikan proses perubahan data di database sekunder, tabel asli dan tabel sementara tidak dipertukarkan. Dengan cara ini, Anda dapat terus memverifikasi keandalan dengan memeriksa data di tabel asli dan tabel sementara.

Kompleksitas Kode

Dalam desain berbasis pemicu, sebagian besar tugas dilakukan oleh database, dan pemicu bertanggung jawab atas sinkronisasi. Oleh karena itu, alat memainkan peran yang relatif kecil.

Desain tanpa pemicu menggunakan log biner untuk menyinkronkan data. Metode ini fleksibel tetapi kompleks.

Alat tanpa pemicu harus didaftarkan sebagai server replikasi, memperoleh peristiwa tabel asli, mengonversi peristiwa menjadi pernyataan SQL, dan kemudian mengeksekusi pernyataan SQL untuk menerapkan peristiwa ke tabel sementara. Kode alat tanpa pemicu mencakup metode penanganan untuk pengecualian seperti kegagalan koneksi, latensi replikasi, ketidakcocokan tipe data, beban yang tidak sesuai pada aplikasi, dan pengecualian yang tidak terkendali. Oleh karena itu, alat tanpa pemicu memiliki basis kode yang lebih besar dan logika yang lebih kompleks untuk kontrol konkurensi.

Trafik Jaringan

Dalam desain berbasis pemicu, data diproses di dalam database.

Desain tanpa pemicu memerlukan alat untuk menangkap perubahan pada tabel sumber dan menerapkan perubahan yang direkam ke tabel tujuan berdasarkan log biner. Ini menghasilkan trafik antar host dan menempati proses MySQL.

Selain itu, untuk memastikan logika kode yang kuat dan stabil, kode harus dikembangkan secara ketat, dan tes yang melimpah harus dilakukan. Meskipun tantangan sebelumnya, desain tanpa pemicu memberikan manfaat substansial. Misalnya, Anda dapat menentukan kapan akan menukar nama tabel sementara dan asli, mengelola proses replikasi data, dan menerapkan throttling.

Item

Fitur perubahan skema tanpa kunci di DMS

gh-ost

Salinan data historis

Pembatasan salinan

Y: manual atau otomatis

Y: manual

Verifikasi konsistensi data

Y

N

Toleransi kesalahan

Y

Y: didukung sebagian

Pemrosesan salinan adaptif

Y

N

Pemutaran ulang perubahan tambahan

Pembatasan pemutaran ulang

Y: manual atau otomatis

Y: manual

Pemutaran ulang multi-threading

Y

N

Verifikasi konsistensi data

Y

N

Toleransi kesalahan

Y

Y: didukung sebagian

Pemrosesan pemutaran ulang adaptif

Y

N

Langganan database sekunder

N

Y

Pergantian tabel

Keatomikan pergantian

Y

Y

Penghapusan tertunda replika tabel

Y

N

Pengaturan pergantian jendela

Y

Y

Mekanisme perlindungan kunci

Y

N

Fungsionalitas

Perubahan database sekunder

N

Y

Integrasi mulus dengan Data Transmission Service (DTS)

Y

N

Pengaturan perubahan kebijakan berdasarkan pengenalan algoritma DDL

Y

N

Engine RocksDB

Y

N

Engine TokuDB

Y

N

Engine InnoDB

Y

Y

Perubahan kolom virtual

Y

N

Perubahan kolom JSON

Y

Y

Indeks bernilai banyak dan indeks fungsi

Y

-

Optimasi ruang tabel

Y

N

Penghapusan tertunda replika tabel

Y

N

Instalasi dan penyebaran

Y: bebas instalasi

Y: instalasi pada server database

O&M tervisualisasi

Y

N

Kemajuan eksekusi tervisualisasi

Y

N