Penskalaan MySQL – masalah bagus

Database


Penskalaan MySQLSaat Anda mengembangkan aplikasi, Anda mengharapkan kesuksesan, dan kesuksesan sering kali disertai dengan masalah pengembangan. Masalah ini terutama terlihat di area penyimpanan data, di mana skalabilitas stateful tidak semudah bagian aplikasi stateless.

Ada beberapa langkah untuk mendekati skalabilitas basis data:

  1. Konfigurasi kueri dan pengoptimalan langkah ini dapat banyak membantu, dan saya merekomendasikan buku terbaru Daniel Nicher MySQL Performance: Best Practices and Techniques yang membahas hal ini.
  2. Jika #1 selesai dan Anda masih mendorong batas database Anda, langkah selanjutnya adalah meningkatkan perangkat keras: menambahkan memori tambahan, meningkatkan kapasitas penyimpanan (SSD konvensional, lapisan penyimpanan NVMe, dll.) atau menambah ukuran cloud (Inilah yang saya sebut “optimasi kartu kredit”). Ini biasanya akan membantu, tetapi hanya sampai batas tertentu. Dan hanya ada begitu banyak memori atau penyimpanan yang dapat Anda masukkan ke dalam server sebelum menjadi mahal terlalu cepat, apalagi batasan fisik dari apa yang dapat Anda masukkan ke dalam satu server.
  3. Langkah 3 adalah mendistribusikan beban kerja melalui beberapa server untuk memenuhi batas server tunggal. Ketika beban kerja membaca intensif, ini biasanya dapat diselesaikan dengan sumber MySQL biasa->replikasi replikasi, namun, itu menjadi sangat rumit jika Anda perlu menskalakan penulisan.

Saya ingin memberikan kutipan dari blog Teknik Likuiditas Square yang menggambarkan pengalaman mereka (Cash Sharding | Blog Pojok Squareup (squareup.com)):

Uang tunai sedang booming dan berjuang untuk tetap terjaga selama lalu lintas puncak. Kami menjalankan buku pedoman klasik untuk penskalaan: penyimpanan, mentransfer data historis, membaca duplikat, membeli perangkat keras yang mahal. Tapi itu tidak cukup. Masing-masing hal ini memberi kami waktu, tetapi kami juga berkembang pesat dan membutuhkan solusi yang memungkinkan kami tumbuh tanpa batas. Kami memiliki satu item terakhir yang tersisa di buku pedoman.

Sebelum membahas solusi yang digunakan Square Cash, saya harus menyebutkan solusi tradisional untuk berbagi (inilah cara kami mendistribusikan beban kerja MySQL ke beberapa bagian yang lebih kecil – disebut server) – partisi tingkat aplikasi – Pada dasarnya, aplikasi memutuskan server mana yang akan dipilih. Gunakan untuk menjalankan kueri. Namun, ada kebutuhan konstan untuk memisahkan logika berbagi dari aplikasi, sehingga pengembang fokus pada menciptakan hasil bisnis berulang kali daripada memecahkan masalah distribusi beban kerja database. Jadi ada kebutuhan untuk memindahkan logika “distribusi beban kerja” dari level aplikasi ke middleware atau bahkan ke level database.

Sudah ada middleware yang tersedia yang membantu mengatasi masalah ini (dan inilah yang digunakan Square Cash): Vitess (Vitess | sistem pengelompokan basis data untuk penskalaan horizontal MySQL)

Vitess adalah perangkat lunak open source yang bekerja seperti proxy dan membantu mendistribusikan beban kerja MySQL di beberapa server (untuk detail lebih lanjut tentang arsitektur Vitess, saya akan merujuk ke presentasi Sugu Sougoumarane: 2019-sugu-highload.pdf ( vitess.io) dan pengantar kami : Memperkenalkan Vitess di Kubernetes untuk MySQL – Bagian I dari III – Percona Database Performance Blog).

Awalnya, Vitess dikembangkan untuk skala YouTube, meskipun saya telah mendengar desas-desus baru-baru ini bahwa Google memindahkan YouTube ke backend lain. Kemudian, itu digunakan tidak hanya oleh Square Cash tetapi juga oleh perusahaan seperti Slack, Pinterest, GitHub dan HubSpot. Semuanya berusaha untuk memecahkan masalah skalabilitas MySQL.

Saya menulis posting blog ini untuk mengumpulkan komentar Anda:

  • Apakah Anda mencoba dan memiliki pengalaman dengan solusi minifikasi dan dapat membagikannya?
  • Ingin mempelajari lebih lanjut tentang scaling-out dari Percona, seperti memulai, memulai, dan panduan umum?
  • Apakah Anda ingin mendukung produk Percona?

Silakan berbagi pemikiran Anda dengan kami dalam jajak pendapat ini.





Source link

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan.