Halo warga Khabrovsk. Kelas pada kelompok pertama kursus dimulai hari ini . Sehubungan dengan itu, kami ingin memberi tahu Anda tentang bagaimana webinar terbuka pada kursus ini berlangsung.
В kita membahas tentang tantangan yang dihadapi database SQL di era cloud dan Kubernetes. Pada saat yang sama, kami melihat bagaimana database SQL beradaptasi dan bermutasi di bawah pengaruh tantangan ini.
Webinar telah dilaksanakan , Manajer Pengiriman Praktik Google Cloud di EPAM Systems.
Saat pohon masih kecil...
Pertama, mari kita ingat bagaimana pilihan DBMS dimulai pada akhir abad yang lalu. Namun hal ini tidak akan sulit, karena pemilihan DBMS pada masa itu dimulai dan diakhiri Peramal.
Pada akhir tahun 90an dan awal tahun 2an, pada dasarnya tidak ada pilihan dalam hal database skala industri. Ya, ada IBM DBXNUMX, Sybase dan beberapa database lain yang datang dan pergi, tetapi secara umum mereka tidak begitu terlihat dengan latar belakang Oracle. Oleh karena itu, keterampilan para insinyur pada masa itu entah bagaimana terikat pada satu-satunya pilihan yang ada.
Oracle DBA harus mampu:
- instal Oracle Server dari kit distribusi;
- konfigurasikan Oracle Server:
- init.ora;
- pendengar.ora;
- membuat:
- ruang tabel;
- skema;
- pengguna;
— melakukan pencadangan dan pemulihan;
— melakukan pemantauan;
— menangani permintaan suboptimal.
Pada saat yang sama, tidak ada persyaratan khusus dari Oracle DBA:
- dapat memilih DBMS atau teknologi lain yang optimal untuk menyimpan dan memproses data;
- menyediakan ketersediaan tinggi dan skalabilitas horizontal (hal ini tidak selalu menjadi masalah DBA);
- pengetahuan yang baik tentang bidang studi, infrastruktur, arsitektur aplikasi, OS;
- memuat dan membongkar data, memigrasikan data antar DBMS yang berbeda.
Secara umum, jika kita berbicara tentang pilihan pada masa itu, itu mirip dengan pilihan di toko Soviet di akhir tahun 80an:
Waktu kita
Sejak saat itu, tentu saja pepohonan telah tumbuh, dunia telah berubah, dan menjadi seperti ini:
Pasar DBMS juga telah berubah, seperti terlihat jelas dari laporan terbaru dari Gartner:
Dan di sini perlu dicatat bahwa awan, yang popularitasnya semakin meningkat, telah menempati ceruk pasarnya. Jika kita membaca laporan Gartner yang sama, kita akan melihat kesimpulan berikut:
- Banyak pelanggan yang sedang memindahkan aplikasi ke cloud.
- Teknologi baru pertama kali muncul di cloud dan bukan fakta bahwa teknologi tersebut akan berpindah ke infrastruktur non-cloud.
- Model penetapan harga bayar sesuai pemakaian sudah menjadi hal yang lumrah. Semua orang ingin membayar hanya untuk apa yang mereka gunakan, dan ini bahkan bukan tren, tapi hanya pernyataan fakta.
Apa sekarang?
Hari ini kita semua berada di awan. Dan pertanyaan-pertanyaan yang muncul bagi kita adalah pertanyaan-pertanyaan pilihan. Dan ini sangat besar, meskipun kita hanya berbicara tentang pilihan teknologi DBMS dalam format Lokal. Kami juga telah mengelola layanan dan SaaS. Dengan demikian, pilihannya semakin sulit setiap tahunnya.
Selain pertanyaan pilihan, ada juga faktor pembatas:
- harga. Banyak teknologi yang masih memerlukan biaya;
- keterampilan. Jika kita berbicara tentang perangkat lunak bebas, maka muncul pertanyaan tentang keterampilan, karena perangkat lunak bebas memerlukan kompetensi yang memadai dari orang yang menyebarkan dan mengoperasikannya;
- fungsional. Tidak semua layanan yang tersedia di cloud dan dibangun, katakanlah, bahkan di Postgres yang sama, memiliki fitur yang sama dengan Postgres Lokal. Ini merupakan faktor penting yang perlu diketahui dan dipahami. Selain itu, faktor ini menjadi lebih penting daripada pengetahuan tentang beberapa kemampuan tersembunyi dari DBMS tunggal.
Apa yang diharapkan dari DA/DE saat ini:
- pemahaman yang baik tentang bidang studi dan arsitektur aplikasi;
- kemampuan untuk memilih teknologi DBMS yang sesuai dengan benar, dengan mempertimbangkan tugas yang ada;
- kemampuan memilih metode optimal penerapan teknologi yang dipilih dalam konteks keterbatasan yang ada;
- kemampuan untuk melakukan transfer dan migrasi data;
- kemampuan untuk menerapkan dan mengoperasikan solusi yang dipilih.
Contoh di bawah ini berdasarkan GCP menunjukkan bagaimana pilihan teknologi tertentu untuk bekerja dengan data bekerja tergantung pada strukturnya:
Harap dicatat bahwa PostgreSQL tidak disertakan dalam skema, dan ini karena tersembunyi di bawah terminologi Awan SQL. Dan saat kita masuk ke Cloud SQL, kita perlu membuat pilihan lagi:
Perlu dicatat bahwa pilihan ini tidak selalu jelas, sehingga pengembang aplikasi sering kali dipandu oleh intuisi.
Total:
- Semakin jauh Anda melangkah, semakin mendesak pertanyaan tentang pilihan. Dan meskipun Anda hanya melihat GCP, layanan terkelola, dan SaaS, beberapa penyebutan RDBMS hanya muncul pada langkah ke-4 (dan ada Spanner di dekatnya). Ditambah lagi pilihan PostgreSQL muncul pada langkah ke 5, dan disebelahnya juga ada MySQL dan SQL Server yaitu ada banyak segalanya, tetapi Anda harus memilih.
- Kita tidak boleh melupakan pembatasan di tengah godaan. Pada dasarnya semua orang menginginkan Kunci Pas, namun harganya mahal. Hasilnya, permintaan tipikal terlihat seperti ini: “Tolong jadikan kami Spanner, tetapi dengan harga Cloud SQL, Anda profesional!”
Tapi apa yang harus dilakukan?
Tanpa mengklaim sebagai kebenaran hakiki, katakanlah hal berikut:
Kita perlu mengubah pendekatan kita dalam belajar:
- tidak ada gunanya mengajarkan cara DBA diajarkan sebelumnya;
- pengetahuan tentang satu produk saja tidak lagi cukup;
- tetapi mengetahui lusinan pada level satu adalah hal yang mustahil.
Anda perlu mengetahui tidak hanya dan bukan berapa harga produknya, tetapi:
- kasus penggunaan penerapannya;
- metode penerapan yang berbeda;
- kelebihan dan kekurangan masing-masing metode;
- produk serupa dan alternatif untuk membuat pilihan yang tepat dan optimal dan tidak selalu berpihak pada produk yang sudah dikenal.
Anda juga harus mampu melakukan migrasi data dan memahami prinsip dasar integrasi dengan ETL.
kasus nyata
Di masa lalu, backend untuk aplikasi seluler perlu dibuat. Pada saat pengerjaannya dimulai, backend telah dikembangkan dan siap untuk diimplementasikan, dan tim pengembangan menghabiskan waktu sekitar dua tahun untuk proyek ini. Tugas-tugas berikut telah ditetapkan:
- membangun CI/CD;
- meninjau arsitektur;
- menjalankan semuanya.
Aplikasinya sendiri adalah layanan mikro, dan kode Python/Django dikembangkan dari awal dan langsung di GCP. Adapun target audiensnya, diasumsikan akan ada dua wilayah - AS dan UE, dan lalu lintas didistribusikan melalui Global Load balancer. Semua Beban Kerja dan beban kerja komputasi dijalankan di Google Kubernetes Engine.
Adapun datanya ada 3 struktur:
- Penyimpanan awan;
- Penyimpanan data;
- Cloud SQL (PostgreSQL).
Mungkin ada yang bertanya-tanya mengapa Cloud SQL dipilih? Sejujurnya, pertanyaan seperti itu telah menyebabkan jeda yang canggung dalam beberapa tahun terakhir - ada perasaan bahwa orang-orang menjadi malu dengan database relasional, namun mereka terus menggunakannya secara aktif ;-).
Dalam kasus kami, Cloud SQL dipilih karena alasan berikut:
- Seperti disebutkan, aplikasi ini dikembangkan menggunakan Django, dan memiliki model untuk memetakan data persisten dari database SQL ke objek Python (Django ORM).
- Kerangka kerja itu sendiri mendukung daftar DBMS yang cukup terbatas:
- PostgreSQL;
- MariaDB;
- MySQL;
- Peramal;
- SQLite.
Oleh karena itu, PostgreSQL dipilih dari daftar ini secara intuitif (sebenarnya bukan Oracle yang memilih).
Apa yang hilang:
- aplikasi hanya diterapkan di 2 wilayah, dan wilayah ketiga muncul di rencana (Asia);
- Basis datanya berlokasi di wilayah Amerika Utara (Iowa);
- di pihak pelanggan ada kekhawatiran tentang kemungkinan tersebut keterlambatan akses dari Eropa dan Asia dan interupsi dalam pelayanan jika terjadi downtime DBMS.
Terlepas dari kenyataan bahwa Django sendiri dapat bekerja dengan beberapa database secara paralel dan membaginya menjadi membaca dan menulis, tidak banyak penulisan dalam aplikasi (lebih dari 90% adalah membaca). Dan secara umum, dan secara umum, jika memungkinkan replika baca pangkalan utama di Eropa dan Asia, ini akan menjadi solusi kompromi. Nah, apa rumitnya?
Kesulitannya adalah pelanggan tidak mau menyerah menggunakan layanan terkelola dan Cloud SQL. Dan kemampuan Cloud SQL saat ini terbatas. Cloud SQL mendukung Ketersediaan tinggi (HA) dan Replika Baca (RR), namun RR yang sama hanya didukung di satu wilayah. Setelah membuat database di wilayah Amerika, Anda tidak dapat membuat replika baca di wilayah Eropa menggunakan Cloud SQL, meskipun Postgres sendiri tidak mencegah Anda melakukan hal ini. Korespondensi dengan karyawan Google tidak membuahkan hasil dan berakhir dengan janji-janji seperti “kami mengetahui masalahnya dan sedang mengatasinya, suatu hari nanti masalah tersebut akan teratasi.”
Jika kita mencantumkan secara singkat kemampuan Cloud SQL, maka akan terlihat seperti ini:
1. Ketersediaan tinggi (HA):
- dalam satu wilayah;
- melalui replikasi disk;
- Mesin PostgreSQL tidak digunakan;
- kontrol otomatis dan manual dimungkinkan - failover/failback;
- Saat berpindah, DBMS tidak tersedia selama beberapa menit.
2. Baca Replika (RR):
- dalam satu wilayah;
- siaga panas;
- Replikasi streaming PostgreSQL.
Selain itu, seperti biasa, ketika memilih suatu teknologi Anda selalu dihadapkan pada beberapa hal pembatasan:
- pelanggan tidak ingin membuat entitas dan menggunakan IaaS, kecuali melalui GKE;
- pelanggan tidak ingin menerapkan layanan mandiri PostgreSQL/MySQL;
- Secara umum, Google Spanner akan cukup cocok jika bukan karena harganya, namun Django ORM tidak dapat bekerja dengannya, tapi itu bagus.
Mempertimbangkan situasinya, pelanggan menerima pertanyaan lanjutan: “Bisakah Anda melakukan hal serupa sehingga seperti Google Spanner, tetapi juga berfungsi dengan Django ORM?”
Opsi solusi No.0
Hal pertama yang terlintas dalam pikiran:
- tetap berada dalam CloudSQL;
- tidak akan terjadi replikasi bawaan antar wilayah dalam bentuk apapun;
- coba lampirkan replika ke Cloud SQL by PostgreSQL yang sudah ada;
- luncurkan instance PostgreSQL di suatu tempat dan entah bagaimana, tapi setidaknya jangan sentuh master.
Sayangnya, ternyata hal ini tidak dapat dilakukan, karena tidak ada akses ke host (ada di proyek yang berbeda sama sekali) - pg_hba dan seterusnya, dan juga tidak ada akses di bawah superuser.
Opsi solusi No.1
Setelah refleksi lebih lanjut dan mempertimbangkan keadaan sebelumnya, alur pemikiran agak berubah:
- Kami masih mencoba untuk tetap menggunakan CloudSQL, namun kami beralih ke MySQL, karena Cloud SQL by MySQL memiliki master eksternal, yang:
— adalah proksi untuk MySQL eksternal;
- tampak seperti contoh MySQL;
- diciptakan untuk memigrasikan data dari cloud lain atau Lokal.
Karena pengaturan replikasi MySQL tidak memerlukan akses ke host, pada prinsipnya semuanya berfungsi, tetapi sangat tidak stabil dan merepotkan. Dan ketika kami melangkah lebih jauh, itu menjadi sangat menakutkan, karena kami menggunakan seluruh struktur dengan terraform, dan tiba-tiba ternyata master eksternal tidak didukung oleh terraform. Ya, Google memiliki CLI, tetapi untuk beberapa alasan semuanya berfungsi di sini sesekali - terkadang dibuat, terkadang tidak dibuat. Mungkin karena CLI diciptakan untuk migrasi data eksternal, dan bukan untuk replika.
Sebenarnya, pada titik ini menjadi jelas bahwa Cloud SQL sama sekali tidak cocok. Seperti yang mereka katakan, kami melakukan semua yang kami bisa.
Opsi solusi No.2
Karena tidak mungkin untuk tetap berada dalam kerangka Cloud SQL, kami mencoba merumuskan persyaratan untuk solusi kompromi. Persyaratannya ternyata sebagai berikut:
- bekerja di Kubernetes, penggunaan sumber daya dan kemampuan Kubernetes (DCS, ...) dan GCP (LB, ...) secara maksimal;
- kurangnya pemberat dari banyak hal yang tidak perlu di cloud seperti proksi HA;
- kemampuan untuk menjalankan PostgreSQL atau MySQL di wilayah HA utama; di wilayah lain - HA dari RR wilayah utama ditambah salinannya (untuk keandalan);
- multi master (saya tidak ingin menghubunginya, tapi itu tidak terlalu penting)
.
Akibat tuntutan tersebut, halDBMS yang sesuai dan opsi pengikatan:
- MySQL Galera;
- KecoaDB;
- Alat PostgreSQL
:
- pgpool-II;
— Patroni.
MySQL Galera
Teknologi MySQL Galera dikembangkan oleh Codership dan merupakan plugin untuk InnoDB. Keunikan:
- multi-master;
- replikasi sinkron;
- membaca dari node mana pun;
- merekam ke node mana pun;
- mekanisme HA bawaan;
- Ada bagan Helm dari Bitnami.
KecoaDB
Menurut uraiannya, hal ini benar-benar mengejutkan dan merupakan proyek sumber terbuka yang ditulis dalam Go. Peserta utamanya adalah Cockroach Labs (didirikan oleh orang-orang dari Google). DBMS relasional ini awalnya dirancang untuk didistribusikan (dengan penskalaan horizontal di luar kotak) dan toleran terhadap kesalahan. Penulisnya dari perusahaan menguraikan tujuan “menggabungkan kekayaan fungsionalitas SQL dengan aksesibilitas horizontal yang familier dengan solusi NoSQL.”
Bonus yang bagus adalah dukungan untuk protokol koneksi pasca-gress.
pgpool
Ini adalah tambahan untuk PostgreSQL, pada kenyataannya, sebuah entitas baru yang mengambil alih semua koneksi dan memprosesnya. Ia memiliki penyeimbang beban dan parser sendiri, yang dilisensikan di bawah lisensi BSD. Ini memberikan banyak peluang, namun terlihat agak menakutkan, karena kehadiran entitas baru dapat menjadi sumber beberapa petualangan tambahan.
Patroni
Ini adalah hal terakhir yang saya lihat, dan ternyata, tidak sia-sia. Patroni adalah utilitas sumber terbuka, yang pada dasarnya adalah daemon Python yang memungkinkan Anda memelihara kluster PostgreSQL secara otomatis dengan berbagai jenis replikasi dan peralihan peran otomatis. Hal tersebut ternyata sangat menarik, karena terintegrasi dengan baik dengan cuber dan tidak memperkenalkan entitas baru.
Apa yang kamu pilih pada akhirnya?
Pilihannya tidak mudah:
- KecoaDB - api, tapi gelap;
- MySQL Galera - juga lumayan, digunakan di banyak tempat, tapi MySQL;
- pgpool — banyak entitas yang tidak perlu, integrasi biasa-biasa saja dengan cloud dan K8;
- Patroni - integrasi yang sangat baik dengan K8, tidak ada entitas yang tidak perlu, terintegrasi dengan baik dengan GCP LB.
Jadi, pilihan jatuh pada Patroni.
Temuan
Saatnya untuk menyimpulkan secara singkat. Ya, dunia infrastruktur TI telah berubah secara signifikan, dan ini hanyalah permulaan. Dan jika sebelumnya awan hanyalah jenis infrastruktur lain, kini semuanya berbeda. Selain itu, inovasi di cloud terus bermunculan, akan muncul, dan mungkin hanya akan muncul di cloud, dan baru kemudian, melalui upaya para startup, inovasi tersebut akan ditransfer ke Lokal.
Sedangkan untuk SQL, SQL akan hidup. Ini berarti Anda perlu mengetahui PostgreSQL dan MySQL dan dapat bekerja dengannya, namun yang lebih penting adalah dapat menggunakannya dengan benar.
Sumber: www.habr.com