- Yelp melakukan migrasi dari PostgreSQL ke MySQL untuk meningkatkan pemeliharaan.
- Proses migrasi ini menghadapi tantangan kompleksitas dan risiko kehilangan data.
- Yelp perlu mempertimbangkan solusi basis data yang lebih modern dan scalable.
pibitek.biz -Layanan Reservasi Yelp (Yelp_res) merupakan layanan yang mengelola pemesanan tempat di Yelp. Layanan ini diakuisisi bersama dengan Seatme pada tahun 2013 dan merupakan layanan dan aplikasi web Django. Yelp_res mengelola backend dan logika pemesanan untuk Yelp Guest Manager, aplikasi iPad untuk restoran, dan menangani alur pelanggan dan mitra yang membuat reservasi. Selain itu, layanan ini juga menyediakan UI web dan API backend untuk aplikasi Reservasi Yelp, yang telah digantikan oleh Yelp Guest Manager tetapi masih digunakan oleh banyak pelanggan restoran Yelp.
2 – Serangan Siber Hantam Globe Life, Data Ribuan Pelanggan Dicuri 2 – Serangan Siber Hantam Globe Life, Data Ribuan Pelanggan Dicuri
3 – Kenaikan Manfaat Jaminan Sosial di Tahun 2025 3 – Kenaikan Manfaat Jaminan Sosial di Tahun 2025
Layanan Reservasi Yelp dibangun dengan arsitektur yang berpusat pada basis data dan menggunakan paradigma sinkronisasi basis data, metode di mana klien memelihara basis data lokal dengan salinan data yang relevan dengan mereka untuk melakukan sinkronisasi data dengan klien warisan. Layanan ini juga bergantung pada trigger basis data untuk menegakkan beberapa logika bisnis. Basis data yang digunakan adalah PostgreSQL, yang tidak digunakan di tempat lain di Yelp, yang berarti bahwa hanya sedikit karyawan lama yang mengetahui PostgreSQL dengan baik untuk melakukan respons terhadap gangguan.
Hal ini menyebabkan masalah dalam pemeliharaan, visibilitas, dan waktu respons gangguan. Tim yang bekerja pada produk Restoran bukan tim infrastruktur, dan tim infrastruktur Yelp secara keseluruhan (jelas) fokus pada infrastruktur standar Yelp. Akibatnya, ketika terjadi masalah dengan PostgreSQL, sering kali terjadi perebutan untuk menemukan orang yang memiliki keahlian yang relevan. Oleh karena itu, Yelp memutuskan untuk mengganti basis data PostgreSQL dengan basis data MySQL standar Yelp. Karena restoran bergantung pada produk Yelp untuk menjalankan bisnis mereka, sistem ini tidak dapat dimatikan untuk pemeliharaan, dan kehilangan data tidak dapat diterima, karena hal tersebut akan menyebabkan reservasi yang dibuat menghilang.
Hal ini menyebabkan banyaknya kompleksitas dalam proyek ini, karena beralih secara bertahap antara dua penyimpanan data secara bersamaan menghadirkan tantangan baru. Banyak dokumentasi yang tersedia mengenai topik ini menggunakan contoh sederhana atau mengasumsikan penghentian, migrasi, dan restart yang bersih, sehingga ini merupakan wilayah yang belum dieksplorasi (oleh karena itu postingan blog ini!). Django memiliki dukungan MySQL. Sebagai bukti konsep pada pertengahan tahun 2022, Yelp beralih ke basis data MySQL di basis data pengembangan (yang lokal dan diatur sesuai kebutuhan) dan memperbarui kode migrasi.
Yelp berhasil mencapai titik di mana layanan tersebut dapat dijalankan, mengonfigurasi basis data dengan benar di MySQL, dan merespons beberapa permintaan dengan sukses. Meskipun bagian ini pada akhirnya menjadi bagian yang mudah, hal ini membantu membuktikan bahwa migrasi layak dilakukan. PostgreSQL memiliki banyak fungsionalitas yang tidak didukung di MySQL. Yelp juga menggunakan beberapa fitur yang, meskipun didukung oleh MySQL, tidak didukung oleh tim infrastruktur Yelp. Salah satu contohnya adalah PostgreSQL memiliki dukungan asli untuk kolom array.
Yelp menggunakan kolom array ini untuk menyimpan jadwal untuk setiap meja di restoran dalam basis data sebagai array bilangan bulat. Yelp menerapkan kembali perilaku ini untuk mengemas data ini ke dalam string, yang bekerja dengan bersih karena panjang array dan setiap elemennya konstan. Serangkaian perubahan yang lebih rumit diperlukan untuk menghilangkan trigger basis data. Trigger secara umum didukung oleh MySQL, tetapi tidak didukung oleh infrastruktur MySQL Yelp. Kode Yelp menggunakan trigger untuk menyebarkan data (memicu ketika tabel basis data tertentu diubah) dan untuk menegakkan batasan seputar pencegahan pemesanan ganda meja.
Untuk penyebaran data, sistem lama Yelp bergantung pada perubahan basis data untuk tabel tertentu yang diterbitkan sebagai acara Advanced Message Queuing Protocol (AMQP) ke rabbitmq, yang kemudian dikonsumsi oleh beberapa klien yang berlangganan perubahan yang relevan dengan mereka. Hal ini didukung oleh ekstensi basis data khusus PostgreSQL yang terintegrasi dengan manajemen transaksi PostgreSQL, memastikan klien tidak pernah menerima pesan hingga transaksi yang sesuai dilakukan. Dalam sistem baru, Yelp menambahkan logika ke fungsi save() model Django untuk menambahkan trigger setelah komitmen untuk menerbitkan ke topik AMQP baru, dan memfaktorkan kembali kode untuk menghilangkan operasi "massal", yang menulis ke basis data tanpa memanggil save().
Artinya, pengamat yang ada dapat mendengarkan topik AMQP baru ini meskipun memperbarui tabel MySQL. Yelp juga memperkenalkan pengelompokan transaksi dengan menghasilkan pengidentifikasi unik universal (UUID) untuk setiap transaksi di awal blok transaksi. Pengidentifikasi ini ditulis bersama dengan data perubahan untuk mengelompokkan perubahan berdasarkan transaksi. Kemudian, Yelp memantau topik yang ada dan topik baru dan memastikan bahwa data tersebut cocok sebelum beralih ke penggunaan topik baru.
Untuk mencegah pemesanan ganda, Yelp menggunakan sistem yang disebut "Atomic Block Holds". Sistem ini menggunakan trigger basis data untuk memunculkan pengecualian dan mencegah penulisan jika blok (blok adalah reservasi, atau apa pun yang berarti meja tidak dapat dipesan pada waktu tertentu) pada meja akan tumpang tindih dengan blok yang ada. Untuk mereplikasi perilaku ini tanpa trigger, Yelp membuat tabel baru yang disebut TableTimeSlotBlock yang berisi baris yang dikunci pada ID meja dan slot waktu 15 menit untuk setiap periode terblokir yang ada.
Kemudian, kode aplikasi memeriksa konflik dan mengunci baris (bahkan jika belum ada) dengan melakukan kueri SELECT FOR UPDATE. Yelp menempatkan logika ini lebih awal dalam kode daripada trigger basis data yang ada, sehingga dengan memeriksa log, Yelp dapat memastikan bahwa trigger yang ada tidak lagi digunakan, yang berarti bahwa solusi baru tersebut setidaknya sama ketat dengan status quo. Untuk bermigrasi ke sistem ini, Yelp juga harus membuat baris di tabel baru ini untuk semua reservasi mendatang, dan karena setiap "blok" yang ada mencakup beberapa slot waktu, yang berarti menambahkan jutaan catatan ke tabel baru.
Ini adalah bagian yang menakutkan. Yelp ingin dapat merilis basis data baru secara bertahap dan dapat kembali ke PostgreSQL jika diperlukan. Ini berarti bahwa Yelp perlu menjaga kedua basis data tetap sinkron untuk beberapa waktu. Django memiliki dukungan multi-basis data, tetapi itu dimaksudkan untuk menulis/membaca hal yang berbeda ke basis data yang berbeda, bukan untuk menjaga data tetap sinkron di beberapa basis data. Untuk mencapai hal ini untuk penulisan, Yelp melakukan hal berikut: 1. Setiap permintaan ditulis ke kedua basis data, dimulai dengan basis data PostgreSQL.
Jika penulisan ke basis data MySQL berhasil, penulisan ke basis data PostgreSQL dilanjutkan. Jika penulisan ke basis data MySQL gagal, penulisan ke basis data PostgreSQL juga dibatalkan. Untuk membaca, Yelp melakukan hal berikut: 1. Semua permintaan membaca diarahkan ke basis data PostgreSQL. Jika membaca dari basis data MySQL berhasil, hasilnya digunakan untuk melayani permintaan. Jika membaca dari basis data MySQL gagal, permintaan kemudian diarahkan ke basis data PostgreSQL. Selama rilis, pertama-tama Yelp mempertahankan bacaan pada PostgreSQL, untuk menjaga perilaku identik dengan status quo sambil juga menulis ke MySQL.
Ini memungkinkan Yelp untuk memeriksa silang basis data dan memperbaiki inkonsistensi dan bug sesuai keinginan tanpa memengaruhi pelanggan. Kemudian, Yelp secara bertahap beralih permintaan untuk membaca dari MySQL, kemudian beralih logika penulisan untuk menulis ke MySQL terlebih dahulu, dan akhirnya (beberapa bulan kemudian) mematikan penulisan PostgreSQL sepenuhnya dan membersihkan sebagian besar kode yang telah dibuat. Proses rilis berjalan relatif lancar selama beberapa bulan, dengan beberapa kejutan yang akan dijelaskan di bawah ini.
Ini adalah proyek besar yang memakan waktu lebih dari satu tahun untuk diimplementasikan. Demi singkatnya, Yelp berfokus pada sebagian kecil dari pekerjaan yang dilakukan Restoran, tetapi semuanya penting untuk keberhasilan proyek ini. Terima kasih khusus kepada tim Database Reliability Engineering dan Production Engineering, dan semua orang dari Restoran yang bekerja pada proyek ini, khususnya Boris Madzar, Carol Fu, dan Daniel Groppe. Yelp mengerjakan banyak proyek keren. Jika tertarik, silakan melamar! Sungguh sebuah kesalahan besar yang dilakukan Yelp untuk mengganti PostgreSQL dengan MySQL.
Tidak hanya hal ini menunjukkan kurangnya profesionalitas dan perencanaan yang matang, tetapi juga menyiratkan bahwa Yelp tidak menghargai investasi yang telah dilakukan pada PostgreSQL. Migrasi yang dilakukan secara terburu-buru dan tidak tepat ini berpotensi menimbulkan masalah baru dan memperburuk kinerja layanan Reservasi Yelp. Lebih buruk lagi, migrasi ini berpotensi menimbulkan risiko keamanan data yang sangat tinggi dan dapat menyebabkan hilangnya data pelanggan yang berharga. Meskipun migrasi ini berhasil dilakukan, tetapi ini hanyalah sebuah langkah awal.
Yelp perlu mempertimbangkan kembali strategi basis data mereka dan memastikan bahwa mereka memilih solusi yang optimal dan scalable untuk kebutuhan mereka. Yelp perlu menyadari bahwa pilihan mereka untuk beralih ke MySQL bukanlah solusi jangka panjang yang ideal. Ke depannya, Yelp perlu mempertimbangkan solusi basis data yang lebih modern dan canggih yang dapat mendukung pertumbuhan dan perkembangan bisnis mereka di masa depan.
