Ada banyak artikel online yang menjelaskan pola skalabilitas basis data, tetapi sebagian besar adalah artikel yang tersebar — hanya teknik yang didefinisikan secara sembarangan tanpa banyak konteks. Saya menemukan bahwa mereka tidak didefinisikan secara langkah demi langkah, dan tidak membahas kapan harus memilih opsi penskalaan mana, opsi penskalaan mana yang layak dalam praktik, dan mengapa.
Oleh karena itu, saya berencana untuk membahas beberapa teknik secara rinci di artikel mendatang. Untuk memulai, saya merasa lebih baik jika saya membahas teknik langkah demi langkah dengan beberapa konteks dengan cara saya sendiri. Artikel ini adalah artikel tingkat tinggi — Saya tidak akan membahas teknik penskalaan secara detail di sini, tetapi akan memberikan gambaran umum. Jadi mari kita mulai.
Studi kasus
Asumsikan Anda telah membangun startup yang menawarkan berbagi perjalanan dengan biaya murah. Awalnya ketika Anda memulai, Anda menargetkan sebuah kota dan hampir tidak memiliki puluhan pelanggan setelah iklan awal Anda.
Anda menyimpan semua pelanggan, perjalanan, lokasi, data pemesanan, dan riwayat perjalanan pelanggan dalam database yang sama atau kemungkinan besar dalam satu mesin fisik. Tidak ada caching mewah atau saluran data besar untuk menyelesaikan masalah karena aplikasi Anda masih sangat baru. Ini sempurna untuk kasus penggunaan Anda saat ini karena hanya ada sedikit pelanggan dan sistem Anda hampir tidak memesan 1 perjalanan dalam 5 menit, misalnya.
Namun seiring berjalannya waktu, lebih banyak orang mulai mendaftar di sistem Anda karena Anda adalah layanan termurah di pasar dan berkat promosi dan iklan Anda. Anda mulai memesan, katakanlah, 10 pemesanan per menit, dan perlahan-lahan jumlahnya meningkat menjadi 20, 30 pemesanan per menit.
Pada titik waktu ini, Anda menyadari bahwa sistem mulai berkinerja buruk:latensi API telah meningkat banyak, dan beberapa transaksi menemui jalan buntu atau kelaparan dan akhirnya gagal. Aplikasi Anda membutuhkan lebih banyak waktu untuk merespons, menyebabkan ketidakpuasan pelanggan. Apa yang dapat Anda lakukan untuk menyelesaikan masalah?
Pola 1 - Pengoptimalan Kueri &implementasi Kumpulan Koneksi:
Solusi pertama yang muncul adalah bahwa cache sering menggunakan data non-dinamis seperti riwayat pemesanan, riwayat pembayaran, profil pengguna, dan sebagainya. Tetapi setelah cache lapisan aplikasi ini, Anda tidak dapat memecahkan masalah latensi API yang mengekspos data dinamis seperti lokasi pengemudi saat ini atau taksi terdekat untuk pelanggan tertentu atau biaya perjalanan saat ini pada saat tertentu setelah perjalanan dimulai.
Anda mengidentifikasi bahwa database Anda mungkin sangat dinormalisasi, jadi Anda memperkenalkan beberapa kolom yang berlebihan (kolom ini sering muncul di WHERE atau JOIN ON klausa dalam kueri) dalam tabel yang sangat sering digunakan demi denormalisasi. Ini mengurangi kueri bergabung, memecah kueri besar menjadi beberapa kueri yang lebih kecil, dan menambahkan hasilnya di lapisan aplikasi.
Optimalisasi paralel lain yang dapat Anda lakukan adalah mengutak-atik koneksi database. Pustaka klien basis data dan pustaka eksternal tersedia di hampir semua bahasa pemrograman. Anda bisa menggunakan pustaka kumpulan koneksi untuk menyimpan koneksi database atau bisa mengonfigurasi ukuran kumpulan koneksi di sistem manajemen database itu sendiri.
Membuat koneksi jaringan apa pun mahal karena memerlukan komunikasi bolak-balik antara klien &server. Penyatuan koneksi dapat membantu Anda mengoptimalkan jumlah koneksi. Pustaka kumpulan koneksi dapat membantu Anda melakukan koneksi multipleks — beberapa utas aplikasi dapat menggunakan koneksi database yang sama. Saya akan melihat apakah saya dapat menjelaskan penyatuan koneksi secara rinci dalam artikel terpisah nanti.
Ukur latensi API Anda &temukan kemungkinan pengurangan latensi 20–50% atau lebih. Ini adalah pengoptimalan yang bagus untuk saat ini.
Anda sekarang telah meningkatkan skala bisnis Anda ke satu kota lagi, lebih banyak pelanggan mendaftar, Anda perlahan mulai melakukan 80–100 pemesanan per menit. Sistem Anda tidak dapat menangani skala ini. Sekali lagi Anda melihat latensi API telah meningkat, lapisan basis data telah menyerah, tetapi kali ini, tidak ada pengoptimalan kueri yang memberi Anda peningkatan kinerja yang signifikan. Anda memeriksa metrik sistem, Anda menemukan ruang disk hampir penuh, CPU sibuk 80% dari waktu, RAM terisi dengan sangat cepat.
Pola 2 - Penskalaan atau Peningkatan Vertikal:
Setelah memeriksa semua metrik sistem, Anda tahu bahwa tidak ada solusi mudah selain memutakhirkan perangkat keras sistem. Anda meningkatkan ukuran RAM sebanyak 2 kali, meningkatkan ruang disk, katakanlah, 3 kali atau lebih. Ini disebut penskalaan vertikal atau peningkatan sistem Anda. Anda memberi tahu tim infrastruktur atau tim pengembang atau agen pusat data pihak ketiga untuk meningkatkan mesin Anda.
Tetapi bagaimana Anda menyiapkan mesin untuk penskalaan vertikal?
Anda mengalokasikan mesin yang lebih besar. Salah satu pendekatannya adalah tidak memigrasikan data secara manual dari mesin lama, melainkan mengatur mesin baru sebagai replica ke mesin yang ada (primary )-membuat primary replica sementara konfigurasi. Biarkan replikasi terjadi secara alami. Setelah replikasi selesai, promosikan mesin baru ke mesin utama &buat mesin lama offline. Karena mesin yang lebih besar diharapkan untuk melayani semua permintaan, semua baca / tulis akan terjadi pada mesin ini.
Dingin. Sistem Anda aktif &berjalan kembali dengan peningkatan kinerja.
Bisnis Anda berjalan dengan sangat baik &Anda memutuskan untuk memperluas ke 3 kota lagi — Anda sekarang beroperasi di total 5 kota. Lalu lintas 3x kali lipat dari sebelumnya, Anda diharapkan melakukan sekitar 300 pemesanan per menit. Bahkan sebelum mencapai pemesanan target ini, Anda kembali mengalami krisis kinerja, ukuran indeks basis data meningkat pesat di memori, perlu pemeliharaan konstan, pemindaian tabel dengan indeks semakin lambat dari sebelumnya. Anda menghitung biaya peningkatan mesin lebih lanjut tetapi tidak yakin dengan biayanya. Apa yang kamu lakukan sekarang?
Pola 3 - Pemisahan Tanggung Jawab Kueri Perintah (CQRS):
Anda mengidentifikasi bahwa mesin besar tidak dapat menangani semua read/write permintaan. Juga dalam kebanyakan kasus, setiap perusahaan membutuhkan kemampuan transaksional pada write tapi tidak di read operasi. Anda juga baik-baik saja dengan sedikit read yang tidak konsisten atau tertunda operasi &bisnis Anda juga tidak memiliki masalah dengan itu. Anda melihat peluang di mana mungkin merupakan opsi yang baik untuk memisahkan read &write operasi mesin fisik bijaksana. Ini akan menciptakan ruang lingkup untuk masing-masing mesin untuk menangani lebih banyak read/write operasi.
Sekarang Anda mengambil dua mesin besar lagi &mengaturnya sebagai replica ke mesin saat ini. Replikasi database akan menangani pendistribusian data dari primary mesin ke replica mesin. Anda menavigasi semua kueri yang telah dibaca (Kueri (Q ) di CQRS ) ke replika — replica apa saja dapat melayani permintaan baca apa pun, Anda menavigasi semua kueri tulis (Perintah (C ) di CQRS ) ke primary . Mungkin ada sedikit jeda dalam replikasi, tetapi menurut kasus penggunaan bisnis Anda, itu baik-baik saja.
Sebagian besar perusahaan rintisan skala menengah yang melayani beberapa ratus ribu permintaan setiap hari dapat bertahan dengan penyiapan replika utama asalkan mereka mengarsipkan data lama secara berkala.
Sekarang Anda menskalakan ke 2 kota lagi, Anda melihat bahwa primary . Anda tidak dapat menangani semua write permintaan. Banyak write permintaan mengalami latensi. Selain itu, jeda antara primary &replica terkadang berdampak pada pelanggan &pengemudi ex — ketika perjalanan berakhir, pelanggan berhasil membayar pengemudi, tetapi pengemudi tidak dapat melihat pembayaran karena aktivitas pelanggan adalah write permintaan yang masuk ke primary , sedangkan aktivitas pengemudi adalah read permintaan yang masuk ke salah satu replika. Sistem Anda secara keseluruhan sangat lambat sehingga pengemudi tidak dapat melihat pembayaran setidaknya selama setengah menit — membuat frustrasi pengemudi &pelanggan. Bagaimana cara mengatasinya?
Pola 4 - Replikasi Multi Primer
Anda menskalakan dengan sangat baik dengan primary-replica konfigurasi, tetapi sekarang Anda membutuhkan lebih banyak kinerja tulis. Anda mungkin siap untuk sedikit berkompromi dengan read meminta kinerja. Mengapa tidak mendistribusikan permintaan tulis ke replica juga?
Dalam multi-primary konfigurasi, semua mesin dapat bekerja sebagai primary &replica . Anda dapat memikirkan multi-primary seperti lingkaran mesin, ucapkan A->B->C->D->A . B dapat mereplikasi data dari A , C dapat mereplikasi data dari B , D dapat mereplikasi data dari C , A dapat mereplikasi data dari D . Anda dapat menulis data ke node mana pun, saat membaca data, Anda dapat menyiarkan kueri ke semua node, siapa pun yang membalas akan mengembalikannya. Semua node akan memiliki skema database yang sama, kumpulan tabel yang sama, indeks dll. Jadi, Anda harus memastikan tidak ada tabrakan di id di seluruh node dalam tabel yang sama, jika tidak selama penyiaran, beberapa node akan mengembalikan data yang berbeda untuk id yang sama .
Umumnya lebih baik menggunakan UUID atau GUID untuk identitas Satu lagi kelemahan dari teknik ini adalah — read kueri mungkin tidak efisien karena melibatkan kueri penyiaran &mendapatkan hasil yang benar — pada dasarnya pendekatan pengumpulan sebar.
Sekarang Anda menskalakan ke 5 kota lagi &sistem Anda sakit lagi. Anda diharapkan untuk menangani sekitar 50 permintaan per detik. Anda sangat membutuhkan untuk menangani sejumlah besar permintaan bersamaan. Bagaimana Anda mencapainya?
Pola 5 - Partisi:
Anda tahu bahwa location database adalah sesuatu yang semakin tinggi write &read lalu lintas. Mungkin write:read rasionya adalah 7:3 . Ini memberi banyak tekanan pada database yang ada. location tabel berisi beberapa data primer seperti longitude , latitude , timestamp , driver id , trip id dll. Tidak ada hubungannya dengan perjalanan pengguna, data pengguna, data pembayaran, dll. Bagaimana dengan memisahkan location tabel dalam skema database terpisah? Bagaimana dengan meletakkan database itu di mesin terpisah dengan primary-replica yang tepat atau multi-primary konfigurasi?
Ini disebut partisi data berdasarkan fungsionalitas. Basis data yang berbeda dapat meng-host data yang dikategorikan berdasarkan fungsionalitas yang berbeda, jika diperlukan hasilnya dapat dikumpulkan di lapisan ujung belakang. Dengan menggunakan teknik ini, Anda dapat fokus pada penskalaan fungsi-fungsi tersebut dengan baik yang menuntut read/write tinggi permintaan. Meskipun bagian belakang atau lapisan aplikasi harus mengambil tanggung jawab untuk menggabungkan hasil bila diperlukan yang mengakibatkan lebih banyak perubahan kode mungkin.
Sekarang bayangkan Anda telah memperluas bisnis Anda ke total 20 kota di negara Anda &berencana untuk segera memperluas ke Australia. Permintaan aplikasi Anda yang meningkat membutuhkan respons yang lebih cepat &lebih cepat. Tak satu pun dari metode di atas dapat membantu Anda secara ekstrim sekarang. Anda harus menskalakan sistem Anda sedemikian rupa sehingga memperluas ke negara/wilayah lain tidak selalu mengharuskan Anda untuk sering melakukan perubahan teknik atau arsitektur. Bagaimana Anda melakukannya?
Pola 6 - Penskalaan Horizontal:
Anda melakukan banyak googling, banyak membaca tentang bagaimana perusahaan lain telah memecahkan masalah — dan sampai pada kesimpulan bahwa Anda perlu menskalakan secara horizontal. Anda mengalokasikan katakanlah 50 mesin — semuanya memiliki skema database yang sama yang pada gilirannya berisi kumpulan tabel yang sama. Semua mesin hanya menyimpan sebagian data.
Karena semua database berisi kumpulan tabel yang sama, Anda dapat mendesain sistem sedemikian rupa sehingga lokasi data ada di sana, yaitu; semua data terkait mendarat di mesin yang sama. Setiap mesin dapat memiliki replikanya sendiri, replika dapat digunakan dalam pemulihan kegagalan. Setiap database disebut shard . Mesin fisik dapat memiliki satu atau beberapa shards — terserah desain Anda seperti yang Anda inginkan. Anda perlu memutuskan sharding key sedemikian rupa sehingga satu sharding key selalu mengacu pada mesin yang sama. Jadi, Anda dapat membayangkan banyak mesin yang semuanya menyimpan data terkait dalam kumpulan tabel yang sama, read/write permintaan untuk baris yang sama atau kumpulan lahan sumber daya yang sama di mesin database yang sama.
Sharding secara umum sulit - setidaknya insinyur dari perusahaan yang berbeda mengatakan itu. Tetapi ketika Anda melayani jutaan atau miliaran permintaan, Anda harus membuat keputusan yang sulit.
Saya akan membahas sharding lebih detail di postingan saya selanjutnya, jadi tahan godaan untuk membahas lebih lanjut di postingan ini.
Sekarang karena Anda memiliki sharding, Anda yakin bahwa Anda dapat menskalakan ke banyak negara. Bisnis Anda telah berkembang pesat sehingga investor mendorong Anda untuk mengembangkan bisnis di seluruh benua. Anda lagi melihat beberapa masalah di sini. Latensi API lagi. Layanan Anda di-host di AS &orang-orang dari Vietnam mengalami perjalanan buku waktu yang sulit. Mengapa? Apa yang Anda lakukan?
Pola 7 - Partisi Bijaksana Pusat Data:
Bisnis Anda berkembang di Amerika, Asia Selatan &di beberapa negara di Eropa. Anda melakukan jutaan pemesanan setiap hari dengan miliaran permintaan mengenai server Anda. Selamat - ini adalah momen puncak untuk bisnis Anda.
Tetapi karena permintaan dari aplikasi harus melakukan perjalanan melintasi benua melalui ratusan atau ribuan server di internet, latensi muncul. Bagaimana dengan mendistribusikan lalu lintas di seluruh pusat data? Anda dapat menyiapkan pusat data di Singapura yang menangani semua permintaan dari Asia Selatan, pusat data di Jerman dapat menangani semua permintaan dari negara-negara Eropa, dan pusat data California dapat menangani semua permintaan AS.
Anda juga mengaktifkan replikasi pusat data lintas yang membantu pemulihan bencana. Jadi jika pusat data California melakukan replikasi ke pusat data Singapura, jika pusat data California mogok karena masalah listrik atau bencana alam, semua permintaan AS dapat jatuh kembali ke pusat data Singapura dan seterusnya.
Teknik penskalaan ini berguna ketika Anda memiliki jutaan pelanggan untuk dilayani di seluruh negara dan Anda tidak dapat mengakomodasi kehilangan data apa pun, Anda harus selalu menjaga ketersediaan sistem.
Ini adalah beberapa teknik langkah demi langkah umum untuk penskalaan basis data. Meskipun sebagian besar engineer tidak mendapatkan kesempatan yang cukup untuk menerapkan teknik ini, tetapi secara keseluruhan lebih baik untuk mendapatkan gambaran yang lebih luas tentang sistem tersebut yang di masa depan dapat membantu Anda untuk melakukan perancangan sistem &arsitektur yang lebih baik.
Dalam artikel saya selanjutnya, saya akan mencoba membahas beberapa konsep secara detail. Jangan ragu untuk memberikan umpan balik yang sesuai untuk postingan ini jika ada.
Artikel ini awalnya diterbitkan di akun media penulis:https://medium.com/@kousiknath/understanding-database-scaling-patterns-ac24e5223522
