Saya suka teknologi tanpa server. Saya bermain-main dan membuat banyak aplikasi tanpa server yang berbeda untuk bereksperimen dengan teknologi keren lainnya. Dalam kelompok besar teknologi yang saya gunakan/eksperimen, PlanetScale adalah database yang terutama saya gunakan untuk proyek sampingan pribadi saya, karena tidak ada opsi "baik" lainnya yang didukung oleh Prisma ORM .

PlanetScale adalah platform tanpa server MySQL yang hanya menjual Vitess, sistem pengelompokan basis data untuk penskalaan horizontal MySQL. Mereka tidak menulis database mereka sendiri - mungkin berkontribusi padanya, tetapi mereka tidak menulisnya. Dari dokumentasi Vitess:

Vitess dibuat pada 2010 untuk mengatasi tantangan skalabilitas MySQL yang dihadapi tim di YouTube.

Dalam artikel ini, kita akan bergerak menuju pemahaman struktur database sharded warisan non-ACID ini, mengapa mereka tidak dapat mendukung sesuatu yang penting seperti integritas referensial, dan mengapa kita harus menghindari menggunakannya dalam aplikasi kita. Artikel ini lebih tentang teknologi Vitess, meskipun saya telah menyertakan PlanetScale dalam judul karena, seperti yang saya sebutkan di atas, itu hanya menjual Vitess (dengan beberapa perkakas) sebagai layanan dan mereka telah mendapatkan daya tarik di bulan-bulan berikutnya sebagai database tanpa server yang "dapat diandalkan".

Latar Belakang

Pertanyaan awal saya adalah mengapa dikatakan bahwa tidak mungkin untuk menskalakan database PlanetScale dengan integritas referensial seperti dalam dokumentasi mereka yang menyatakan bahwa:

Cara FOREIGN KEY kendala diimplementasikan di MySQL (atau, lebih tepatnya, di mesin penyimpanan InnoDB) mengganggu operasi DDL Online. Pelajari lebih lanjut di entri blog Vitess ini.

Terbatas untuk satu lingkup server MySQL, FOREIGN KEY batasan tidak mungkin dipertahankan setelah data Anda bertambah dan dibagi ke beberapa server basis data. Ini biasanya terjadi ketika Anda memperkenalkan partisi/sharding fungsional dan/atau sharding horizontal.

Ini membuat saya berpikir:lakukan FOREIGN KEY kendala mempengaruhi skalabilitas secara umum? dan jika demikian, bagaimana?

Saya pikir penting untuk menyadari bahwa penggabungan tabel SQL cukup mahal, tetapi setahu saya itu tidak banyak dipengaruhi oleh integritas referensial? Sekarang, jika kita melakukan sesuatu seperti analisis data, jelas kita tidak memerlukan integritas referensial karena kita hanya ingin membuang data kita ke dalam satu tabel, tetapi PlanetScale dan Vitess membanggakan digunakan oleh aplikasi web besar seperti YouTube.

Ini membuat saya bingung mengapa mereka menjatuhkan FOREIGN KEY kendala karena database seperti CockroachDB dan Spanner masih mempertahankan integritas referensial serta dapat diskalakan.

Apa itu integritas referensial, dan mengapa itu penting?

Mari kita mulai dengan dasar-dasarnya, jika Anda baru. Saya kira kebanyakan orang yang membaca posting ini memiliki gagasan yang adil tentang apa yang mereka bicarakan, tetapi saya akan menjelaskannya sebagai formalitas. Dengan kata sederhana, FOREIGN KEY kendala adalah kunci database yang dapat kita gunakan untuk membuat hubungan antara dua tabel yang berbeda dengan referensi kolom, atau satu set kolom. Integritas referensial hanya mengacu pada keadaan database di mana semua nilai dari semua kunci valid.

Mengapa penting?

Sekarang setelah kita memiliki sedikit gambaran tentang apa itu, mari kita lompat ke bagian kedua:mengapa mereka penting?

Integritas referensial penting karena mencegah Anda memasukkan kesalahan baru ke dalam database Anda. Ini adalah fitur yang sering disediakan oleh database relasional yang mencegah pengguna atau aplikasi memasukkan data yang tidak konsisten ke dalam database. Ini mengarah pada peningkatan kualitas data, pengembangan yang lebih cepat, bug yang jauh lebih sedikit, dan konsistensi di seluruh aplikasi Anda.

Mengapa Vitess tidak memilikinya?

Jadi, untuk memahami mengapa Vitess tidak dapat mendukung integritas referensial, kita harus mempelajari arsitektur database. Vitess adalah database SQL non-ACID sharded, bukan database SQL ACID terdistribusi yang sebenarnya.

Sekarang, Anda pasti bertanya-tanya apa istilah-istilah itu. Biarkan saya menguraikannya untuk Anda:ACID adalah akronim dari Atomicity, Consistency, Isolation, dan Durability.

Di sini, atomisitas mengacu pada tindakan yang menyelesaikan atau gagal sepenuhnya - tidak ada penyelesaian sebagian dari suatu transaksi. Konsistensi mengacu pada transaksi meninggalkan database dalam keadaan yang valid. Isolasi berarti bahwa dua transaksi dijalankan tanpa gangguan satu sama lain, dan daya tahan berarti perubahan transaksi disimpan.

Sebuah shard adalah partisi horizontal data dalam database, dan setiap shard disimpan pada instance server database terpisah untuk menyebarkan beban. Jadi ketika kita merujuk ke database yang di-sharding, kita sedang membicarakan sesuatu seperti ini. Sekarang seperti yang saya katakan sebelumnya, Vitess adalah database SQL non-ACID sharded, yang pada dasarnya berarti TIDAK menjamin properti ACID dari transaksi.

Mengapa menjatuhkannya?

Nah, masalahnya dimulai ketika Anda memiliki database MySQL dengan skema yang terdefinisi dengan baik, dan layanan Anda menjadi populer dengan masalah terlalu banyak pembacaan yang mengenai database. Apa yang kebanyakan orang lakukan di sini adalah mereka mulai menyimpan kueri yang sering dieksekusi, tetapi pembacaan tidak lagi bersifat ACIDic.

Seiring dengan terlalu banyak membaca, memiliki jumlah penulisan yang berlebihan ke database Anda adalah masalah serius yang mungkin dihadapi banyak orang. Katakanlah kita siap untuk membakar kantong kita - kita dapat menskalakan secara vertikal, menambahkan lebih banyak RAM, prosesor 16-inti, dan memuat solid-state drive yang sangat cepat.

Kami tentu saja masih memiliki masalah penggabungan tabel SQL yang semakin kompleks, jadi Anda mulai melakukan denormalisasi untuk menghindari penggabungan antar tabel.

Saya memberikan ceramah di Prisma Meetup beberapa waktu lalu, di mana saya menjelaskan dasar-dasar merancang database relasional. Topik yang saya bahas di sini adalah denormalisasi, jika Anda tertarik, pastikan untuk memeriksanya.

Tetapi denormalisasi pada dasarnya adalah proses di mana Anda menambahkan data yang berlebihan ke tabel di database Anda, yang meningkatkan kinerja dengan biaya ruang disk karena Anda tidak lagi menggunakan daya CPU untuk bergabung. Meskipun denormalisasi meningkatkan kecepatan membaca, penting untuk disadari bahwa denormalisasi memang membuat penulisan lebih lambat.

Namun demikian, terlepas dari semua ini, database kami masih lambat, jadi kami memindahkan perhitungan database ke klien, misalnya membuat UUID atau menetapkan tanggal.

Bahkan setelah semua ini, kueri akan tetap lambat - jadi kami menyimpan hasil dari data yang paling banyak ditanyakan dalam proses yang dikenal sebagai materialisasi basis data. Sekarang membaca mungkin lebih cepat, tetapi menulis semakin lambat dari hari ke hari. Satu-satunya situasi logis sekarang adalah menghapus indeks sekunder.

Jadi pada titik ini, database kami telah

Tidak ada properti ACID karena cache
Tidak ada skema yang dinormalisasi
Tidak ada pemicu
Tidak ada perhitungan basis data
Tidak ada indeks sekunder

Ini membuka jalan bagi basis data Vitess dan NoSQL, karena perusahaan mengalami masalah dengan penskalaan basis data mereka. Cara itu dirancang, mereka tidak dapat mempertahankan konsistensi data, sebuah properti ACID, ketika transaksi mencakup beberapa pecahan yang berbeda. Integritas referensial adalah tentang konsistensi ketika data terbentang di beberapa pecahan, oleh karena itu masuk akal jika mereka tidak dapat mendukungnya dengan baik.

Kita bisa masuk jauh ke dalam struktur database NoSQL tanpa FOREIGN KEY kendala dan masalah yang akan kita hadapi dalam mengadopsi model itu, tapi itulah topik untuk posting lain.

Bukan hanya Vitess, ini sudah menjadi praktik standar untuk basis data sharded untuk menghindari integritas referensial karena tidak ada pilihan lain. Dalam hal model ACID, dokumentasi mereka menyatakan bahwa mereka menjamin atomitas tetapi bukan isolasi, dan bahkan mengatakan:

Menjamin Isolasi ACID sangat kontroversial dan memiliki biaya tinggi. Menyediakannya secara default akan membuat Vitess tidak praktis untuk kasus penggunaan yang paling umum.

Mari kita bahas secara singkat apa itu Isolasi ACID. Ada empat level untuk itu (menurut standar SQL-92), termasuk serialisability, read commited, read uncommited, dan readable repeatable. Dengan demikian, ada lebih banyak tingkat isolasi, seperti isolasi Snapshot yang bukan merupakan standar SQL meskipun digunakan oleh beberapa database seperti Firebase atau MongoDB. Jika Anda lebih tertarik dengan ini, saya sarankan membaca posting ini. Singkatnya, saya tidak akan membahas apa arti/arti setiap tingkat isolasi, tetapi jika Anda ingin membaca lebih lanjut tentang itu, lihat halaman ini dari Dokumentasi MySQL.

Isolasi ACID mengacu pada transaksi database menjadi ACIDic, yang penting karena menjamin bahwa operasi berperilaku seperti yang diharapkan pengembang. Saya tidak yakin apa artinya ketika mereka mengatakan "Menjamin Isolasi ACID sangat kontroversial dan memiliki biaya tinggi", tetapi jika itu berarti menjamin Isolasi ACID memiliki biaya tinggi untuk produk apa pun , mereka salah. Beberapa database yang sesuai dengan ACID terdistribusi memiliki tingkat isolasi tertinggi (transaksi serial) sementara tetap berkinerja dengan kecepatan baca/tulis yang cepat. Namun, dalam konteks Vitess, mereka tidak salah karena di beberapa transaksi pecahan tidak dapat memenuhi tingkat isolasi apa pun.

Kesimpulan

Dengan semua ini, Anda pasti bertanya-tanya:mengapa ada orang yang ingin menggunakan PlanetScale atau Vitess? Yah, aku bertanya-tanya sama. Dengan banyak perusahaan dan situs web, alasannya adalah karena mereka memilih kembali Vitess ketika tidak ada pilihan yang lebih baik. Jika Anda pergi ke awal artikel, perhatikan bagaimana itu dibuat pada tahun 2010. Sekarang kita dapat menikmati database terukur yang sesuai dengan ACID dengan integritas referensial, akan menjadi kepentingan terbaik kita untuk beralih ke database baru ini, dan saya sudah mulai melakukannya! Teknologi berubah dengan cepat, dan menjaga kecepatan database Anda adalah komponen penting dari aplikasi apa pun.