MySQL di Lingkungan Layanan Mikro – Blog Kinerja Basis Data Percona

Database


MySQL di lingkungan layanan mikroArsitektur layanan mikro bukanlah paradigma baru, tetapi baru-baru ini menjadi sangat populer karena dua alasan: komputasi awan dan wadah. Kombinasi ini membantu meningkatkan adopsi dengan mengatasi dua masalah utama dalam infrastruktur apa pun: pengurangan biaya dan manajemen infrastruktur.

Namun, semua keindahan ini menyembunyikan kebenaran gelap:

Bagian tersulit dari layanan mikro adalah lapisan data

Dan ini terutama berlaku untuk database relasional klasik seperti MySQL. Mari cari tahu alasannya.

MySQL dan layanan mikro

Mengikuti dua pilar layanan mikro yang sama (komputasi awan dan wadah), apa yang dapat dilakukan di ruang MySQL? Apa yang dibawa oleh komputasi awan dan kontainer?

Pemrosesan awan

Keajaiban cloud adalah memungkinkan Anda untuk sadar biaya dan memungkinkan Anda untuk dengan mudah meningkatkan/menskalakan ukuran instans Anda. Tidak ada lagi membuang-buang uang di server besar yang sering kurang dimanfaatkan. Apa itu masalah? Itu harus cepat, menskalakan dengan cepat untuk mempersiapkan lalu lintas yang padat dan menurunkan dengan cepat untuk mengurangi biaya saat lalu lintas rendah.

cucian piring

Keajaiban wadah adalah bahwa perangkat keras dapat dipartisi menjadi sumber daya yang diperlukan. Poin penting di sini adalah bahwa container secara tradisional digunakan dalam aplikasi stateless. Piring sekali pakai.

Basis data relasional pada umumnya, dan MySQL pada khususnya, tidak berskala dengan cepat dan bersifat stateful. Namun, itu dapat disesuaikan dengan cloud dan digunakan untuk lapisan data di layanan mikro.

skala kubus

skala kubus

Buku The Art of Scaling oleh Abbott and Fisher menjelaskan model penskalaan 3D yang sangat berguna: Scale Cube. Dalam model ini, penskalaan aplikasi dengan menjalankan klon di belakang penyeimbang beban dikenal sebagai penskalaan sumbu-X. Dua jenis penskalaan lainnya adalah penskalaan sumbu Y dan penskalaan sumbu Z. Arsitektur layanan mikro adalah aplikasi penskalaan sumbu Y: itu Ini mendefinisikan arsitektur yang menyusun aplikasi sebagai satu set layanan bekerja sama yang digabungkan secara longgar.

  • X-Axis: replikasi horizontal dan simulasi layanan dan data (Baca RePLICAS)
  • Sumbu Y: divisi fungsional – (MULTI-ENANT)
  • Z-Axis: layanan dan partisi data di sepanjang batas pelanggan – (SHARDING)

Dalam layanan mikro, setiap layanan memiliki database sendiri untuk mengisolasinya dari layanan lain. Dengan kata lain: transaksi layanan hanya menyertakan database-nya. Data bersifat pribadi dan hanya dapat diakses melalui API layanan mikro.

Secara alami, pendekatan pertama untuk mempartisi data adalah dengan menggunakan model multi-penyewa:

Sebenarnya, sebelum menggunakan multi-tenancy, seseorang dapat menggunakan model tabel-per-layanan di mana setiap layanan memiliki satu set tabel yang hanya boleh diakses oleh layanan itu, tetapi dengan memiliki bagian “lunak” itu, godaan untuk melewati API dan akses langsung tabel layanan lainnya sangat bagus.

Skema per layanan, di mana setiap layanan memiliki skema basis data yang bersifat pribadi untuk layanan tersebut, menarik karena membuat kepemilikan lebih jelas. Sangat mudah untuk membuat pengguna per database dengan kelonggaran khusus untuk membatasi akses ke database.

Namun, pola “basis data bersama” ini memiliki beberapa kelemahan seperti:

  • Perangkat Keras Tunggal: Kerusakan di database Anda akan merusak semua layanan mikro
  • Tugas intensif sumber daya yang terkait dengan database tertentu memengaruhi database lain (pikirkan DDL)
  • Sumber daya bersama: Latensi disk, IOPS, dan bandwidth harus dibagikan, serta sumber daya lain seperti CPU, bandwidth jaringan, dll.

Alternatifnya adalah pergi ke “Database per layanan”.

Basis data per layanan

Jangan bagikan apa pun Pemisahan logis yang lebih bersih Masalah yang terisolasi Layanan digabungkan secara longgar. Faktanya, ini membuka pintu bagi layanan mikro untuk menggunakan basis data apa pun yang paling sesuai dengan kebutuhan mereka, seperti bagan db, basis data berorientasi dokumen, dll. Tetapi seperti semuanya, ia juga memiliki kekurangannya:

  • Yang paling jelas: biaya. Lebih banyak untuk disebarkan
  • Paling penting: transaksi terdistribusi. Seperti yang kami sebutkan sebelumnya, layanan mikro memiliki kemitraan di antara mereka, yang berarti bahwa transaksi menjangkau banyak layanan.

Pendekatan yang sederhana adalah dengan menggunakan implementasi komitmen dua fase. Tetapi solusi ini hanyalah undangan terbuka untuk banyak masalah penguncian. Itu hanya tidak skala. Jadi apa alternatifnya?

  • Melaksanakan transaksi yang melibatkan layanan: Paradigma epik
  • Menerapkan kueri yang melibatkan layanan: Komposisi API atau Pemisahan Tanggung Jawab Kueri Perintah (CQRS)

Saga adalah urutan transaksi lokal. Setiap transaksi lokal memperbarui database dan menerbitkan pesan atau peristiwa yang memulai transaksi lokal berikutnya dalam saga. Jika transaksi lokal gagal karena alasan apa pun, saga mengeksekusi serangkaian transaksi kompensasi yang membatalkan perubahan yang dibuat oleh transaksi sebelumnya. Informasi lebih lanjut tentang Saga di sini: https://microservices.io/patterns/data/saga.html

API komposit hanyalah seorang komposer yang memanggil kueri pada setiap layanan mikro dan kemudian mengkomit hasilnya dalam memori:
https://microservices.io/patterns/data/api-composition.html

CQRS memelihara satu atau lebih tampilan nyata yang berisi data dari beberapa layanan. Ini menghindari kebutuhan untuk bergabung dalam ukuran kueri: https://microservices.io/patterns/data/cqrs.html

Apa kesamaan dari semua alternatif ini? Ini ditangani di tingkat API: terserah pengembang untuk menerapkan dan memeliharanya. Menjaga lapisan data tetap data, bukan informasi.

Bikin mendung

Ada alat untuk membuat MySQL Cloud-Native Anda: penskalaan mudah naik dan turun. berjalan di atas kontainer, banyak kontainer; Kompatibel dengan Kubernetes. Dengan semua manfaat Kubernetes (pemeriksaan kesehatan, saya melihat Anda).

Operator Percona untuk MySQL berdasarkan Percona XtraDB Cluster

Operator Kubernetes adalah jenis pengontrol khusus yang diperkenalkan untuk menyederhanakan penerapan yang kompleks. Operator menyediakan otomatisasi siklus hidup aplikasi penuh dan menggunakan berbasis Kubernetes untuk membangun dan mengelola aplikasi Anda.

Operator Percona untuk MySQL

Dalam posting blog kami “Pengenalan Operator Percona untuk MySQL berbasis Percona XtraDB Cluster” Ikhtisar operator dan manfaatnya tercakup. Namun, perlu diperhatikan apa yang membuatnya menjadi cloud native:

  • Ini menggunakan keunggulan komputasi awan, meningkatkan dan menurunkan
  • Menjalankan wadah kerucut
  • Ini diatur oleh orkestra cloud itu sendiri: Kubernetes

Di bawah tenda adalah Cluster Percona XtraDB yang berjalan di POD. Penskalaan mudah (menambah jumlah node: https://www.percona.com/doc/kubernetes-operator-for-pxc/scaling.html) dan dapat diskalakan dengan memberikan lebih banyak sumber daya ke definisi POD (tanpa itu) memberi kegagalan)

Cobalah https://www.percona.com/doc/kubernetes-operator-for-pxc/index.html Dan lepaskan kekuatan cloud di MySQL.





Source link

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan. Ruas yang wajib ditandai *