Hello, penduduk Khabrovsk. Kelas dalam kumpulan pertama kursus bermula hari ini . Dalam hal ini, kami ingin memberitahu anda tentang bagaimana webinar terbuka pada kursus ini berlangsung.
Π kami bercakap tentang cabaran pangkalan data SQL yang dihadapi dalam era awan dan Kubernetes. Pada masa yang sama, kami melihat bagaimana pangkalan data SQL menyesuaikan dan bermutasi di bawah pengaruh cabaran ini.
Webinar telah diadakan , Pengurus Penyampaian Amalan Awan Google di Sistem EPAM.
Semasa pokok-pokok masih kecil...
Pertama, mari kita ingat bagaimana pilihan DBMS bermula pada akhir abad yang lalu. Walau bagaimanapun, ini tidak sukar, kerana pilihan DBMS pada masa itu bermula dan berakhir Oracle.
Pada penghujung 90-an dan awal 2-an, pada dasarnya tiada pilihan dalam hal pangkalan data boleh skala industri. Ya, terdapat IBM DBXNUMX, Sybase dan beberapa pangkalan data lain yang datang dan pergi, tetapi secara umum mereka tidak begitu ketara dengan latar belakang Oracle. Oleh itu, kemahiran jurutera pada masa itu entah bagaimana terikat dengan satu-satunya pilihan yang ada.
Oracle DBA harus dapat:
- pasang Pelayan Oracle daripada kit pengedaran;
- konfigurasikan Pelayan Oracle:
- init.ora;
- pendengar.ora;
- cipta:
- ruang meja;
- skim;
- pengguna;
β lakukan sandaran dan pemulihan;
β menjalankan pemantauan;
β berurusan dengan permintaan yang tidak optimum.
Pada masa yang sama, tiada keperluan khas daripada Oracle DBA:
- boleh memilih DBMS atau teknologi lain yang optimum untuk menyimpan dan memproses data;
- menyediakan ketersediaan tinggi dan kebolehskalaan mendatar (ini tidak selalu menjadi isu DBA);
- pengetahuan yang baik tentang bidang subjek, infrastruktur, seni bina aplikasi, OS;
- memuat dan memunggah data, pindahkan data antara DBMS yang berbeza.
Secara umum, jika kita bercakap tentang pilihan pada zaman itu, ia menyerupai pilihan di kedai Soviet pada akhir 80-an:
Masa kami
Sejak itu, tentu saja, pokok-pokok telah tumbuh, dunia telah berubah, dan ia menjadi seperti ini:
Pasaran DBMS juga telah berubah, seperti yang dapat dilihat dengan jelas daripada laporan terkini daripada Gartner:
Dan di sini harus diperhatikan bahawa awan, yang popularitinya semakin meningkat, telah menduduki niche mereka. Jika kita membaca laporan Gartner yang sama, kita akan melihat kesimpulan berikut:
- Ramai pelanggan sedang dalam laluan untuk memindahkan aplikasi ke awan.
- Teknologi baharu mula-mula muncul dalam awan dan bukan fakta bahawa mereka akan berpindah ke infrastruktur bukan awan.
- Model penentuan harga bayar semasa anda telah menjadi perkara biasa. Semua orang mahu membayar hanya untuk apa yang mereka gunakan, dan ini bukanlah satu trend, tetapi hanya satu kenyataan fakta.
Apa sekarang?
Hari ini kita semua berada di awan. Dan persoalan yang timbul untuk kita adalah persoalan pilihan. Dan ia adalah besar, walaupun kita hanya bercakap tentang pilihan teknologi DBMS dalam format Di premis. Kami juga mempunyai perkhidmatan terurus dan SaaS. Oleh itu, pilihan hanya menjadi lebih sukar setiap tahun.
Bersama-sama dengan soalan pilihan, ada juga faktor pembatas:
- harga. Banyak teknologi masih memerlukan wang;
- kemahiran. Jika kita bercakap tentang perisian percuma, maka persoalan kemahiran timbul, kerana perisian percuma memerlukan kecekapan yang mencukupi daripada orang yang menggunakan dan mengendalikannya;
- berfungsi. Tidak semua perkhidmatan yang tersedia dalam awan dan dibina, katakan, walaupun pada Postgres yang sama, mempunyai ciri yang sama seperti Postgres On-premises. Ini adalah faktor penting yang perlu diketahui dan difahami. Selain itu, faktor ini menjadi lebih penting daripada pengetahuan tentang beberapa keupayaan tersembunyi DBMS tunggal.
Apa yang diharapkan daripada DA/DE sekarang:
- pemahaman yang baik tentang bidang subjek dan seni bina aplikasi;
- keupayaan untuk memilih teknologi DBMS yang sesuai dengan betul, dengan mengambil kira tugas di tangan;
- keupayaan untuk memilih kaedah yang optimum untuk melaksanakan teknologi yang dipilih dalam konteks batasan sedia ada;
- keupayaan untuk melakukan pemindahan data dan migrasi;
- keupayaan untuk melaksanakan dan mengendalikan penyelesaian terpilih.
Contoh di bawah berdasarkan GCP menunjukkan cara pilihan satu atau teknologi lain untuk bekerja dengan data berfungsi bergantung pada strukturnya:
Sila ambil perhatian bahawa PostgreSQL tidak termasuk dalam skema, dan ini kerana ia tersembunyi di bawah terminologi Cloud SQL. Dan apabila kita sampai ke Cloud SQL, kita perlu membuat pilihan sekali lagi:
Perlu diingatkan bahawa pilihan ini tidak selalu jelas, jadi pembangun aplikasi sering dipandu oleh intuisi.
Jumlah:
- Semakin jauh anda pergi, semakin mendesak persoalan pilihan. Dan walaupun anda hanya melihat GCP, perkhidmatan terurus dan SaaS, maka beberapa sebutan tentang RDBMS hanya muncul pada langkah ke-4 (dan Spanner terletak berdekatan). Tambahan pula, pilihan PostgreSQL muncul pada langkah ke-5, dan di sebelahnya juga terdapat MySQL dan SQL Server, iaitu terdapat banyak segala-galanya, tetapi anda perlu memilih.
- Kita tidak boleh melupakan sekatan terhadap latar belakang godaan. Pada asasnya semua orang mahu Spanner, tetapi ia mahal. Akibatnya, permintaan biasa kelihatan seperti ini: "Sila jadikan kami Spanner tetapi untuk harga Cloud SQL, anda adalah profesional!"
Apa yang patut kita buat?
Tanpa mendakwa sebagai kebenaran muktamad, katakan yang berikut:
Kita perlu mengubah pendekatan pembelajaran kita:
- tidak ada gunanya mengajar cara DBA diajar sebelum ini;
- pengetahuan tentang satu produk tidak lagi mencukupi;
- tetapi mengetahui berpuluh-puluh pada tahap satu adalah mustahil.
Anda perlu tahu bukan sahaja dan bukan berapa banyak produk itu, tetapi:
- kes penggunaan aplikasinya;
- kaedah penyebaran yang berbeza;
- kelebihan dan kekurangan setiap kaedah;
- produk yang serupa dan alternatif untuk membuat pilihan yang termaklum dan optimum dan tidak selalu memihak kepada produk yang biasa.
Anda juga perlu dapat memindahkan data dan memahami prinsip asas penyepaduan dengan ETL.
Kes sebenar
Pada masa lalu baru-baru ini, adalah perlu untuk membuat bahagian belakang untuk aplikasi mudah alih. Pada masa kerja bermula padanya, bahagian belakang telah dibangunkan dan sedia untuk dilaksanakan, dan pasukan pembangunan menghabiskan kira-kira dua tahun untuk projek ini. Tugas berikut telah ditetapkan:
- membina CI/CD;
- mengkaji seni bina;
- meletakkan semuanya dalam operasi.
Aplikasi itu sendiri ialah perkhidmatan mikro, dan kod Python/Django telah dibangunkan dari awal dan terus dalam GCP. Bagi khalayak sasaran, diandaikan terdapat dua wilayah - AS dan EU, dan trafik diagihkan melalui pengimbang Beban Global. Semua Beban Kerja dan beban kerja pengiraan dijalankan pada Enjin Google Kubernetes.
Bagi data, terdapat 3 struktur:
- Storan Awan;
- Simpanan data;
- Cloud SQL (PostgreSQL).
Seseorang mungkin tertanya-tanya mengapa Cloud SQL dipilih? Sejujurnya, soalan sedemikian telah menyebabkan beberapa jenis jeda yang janggal dalam beberapa tahun kebelakangan ini - terdapat perasaan bahawa orang telah menjadi malu tentang pangkalan data hubungan, tetapi mereka terus menggunakannya secara aktif ;-).
Bagi kes kami, Cloud SQL telah dipilih atas sebab berikut:
- Seperti yang dinyatakan, aplikasi itu dibangunkan menggunakan Django, dan ia mempunyai model untuk memetakan data berterusan daripada pangkalan data SQL ke objek Python (Django ORM).
- Rangka kerja itu sendiri menyokong senarai DBMS yang agak terhad:
- PostgreSQL;
- MariaDB;
- MySQL;
- peramal;
- SQLite.
Sehubungan itu, PostgreSQL dipilih daripada senarai ini secara intuitif (sebenarnya, bukan Oracle untuk dipilih).
Apa yang hilang:
- aplikasi itu digunakan hanya di 2 wilayah, dan yang ketiga muncul dalam rancangan (Asia);
- Pangkalan data terletak di wilayah Amerika Utara (Iowa);
- di pihak pelanggan terdapat kebimbangan tentang kemungkinan kelewatan akses dari Eropah dan Asia dan gangguan dalam perkhidmatan dalam kes masa henti DBMS.
Walaupun fakta bahawa Django sendiri boleh bekerja dengan beberapa pangkalan data secara selari dan membahagikannya kepada membaca dan menulis, tidak terdapat banyak penulisan dalam aplikasi (lebih daripada 90% membaca). Dan secara umum, dan secara umum, jika mungkin untuk dilakukan replika baca pangkalan utama di Eropah dan Asia, ini akan menjadi penyelesaian kompromi. Nah, apa yang rumit mengenainya?
Kesukarannya ialah pelanggan tidak mahu berputus asa menggunakan perkhidmatan terurus dan Cloud SQL. Dan keupayaan Cloud SQL adalah terhad pada masa ini. Cloud SQL menyokong ketersediaan Tinggi (HA) dan Replika Baca (RR), tetapi RR yang sama hanya disokong di satu rantau. Setelah mencipta pangkalan data di rantau Amerika, anda tidak boleh membuat replika baca di rantau Eropah menggunakan Cloud SQL, walaupun Postgres sendiri tidak menghalang anda daripada melakukan ini. Surat-menyurat dengan pekerja Google tidak menjurus ke mana-mana dan berakhir dengan janji-janji dalam gaya "kami tahu masalah itu dan sedang menyelesaikannya, suatu hari nanti isu itu akan diselesaikan."
Jika kami menyenaraikan keupayaan Cloud SQL secara ringkas, ia akan kelihatan seperti ini:
1. Ketersediaan tinggi (HA):
- dalam satu wilayah;
- melalui replikasi cakera;
- Enjin PostgreSQL tidak digunakan;
- kawalan automatik dan manual mungkin - failover/failback;
- Apabila menukar, DBMS tidak tersedia untuk beberapa minit.
2. Baca Replika (RR):
- dalam satu wilayah;
- siap sedia panas;
- Replikasi penstriman PostgreSQL.
Di samping itu, seperti biasa, apabila memilih teknologi anda sentiasa berhadapan dengan beberapa sekatan:
- pelanggan tidak mahu mencipta entiti dan menggunakan IaaS, kecuali melalui GKE;
- pelanggan tidak mahu menggunakan perkhidmatan diri PostgreSQL/MySQL;
- Secara amnya, Google Spanner agak sesuai jika bukan kerana harganya, namun, Django ORM tidak dapat berfungsi dengannya, tetapi ia adalah perkara yang baik.
Memandangkan keadaan itu, pelanggan menerima soalan susulan: "Bolehkah anda melakukan sesuatu yang serupa supaya ia seperti Google Spanner, tetapi juga berfungsi dengan Django ORM?"
Pilihan penyelesaian No. 0
Perkara pertama yang terlintas di fikiran:
- kekal dalam CloudSQL;
- tidak akan ada replikasi terbina dalam antara wilayah dalam sebarang bentuk;
- cuba lampirkan replika pada Cloud SQL sedia ada oleh PostgreSQL;
- lancarkan contoh PostgreSQL di suatu tempat dan entah bagaimana, tetapi sekurang-kurangnya jangan sentuh master.
Malangnya, ternyata ini tidak boleh dilakukan, kerana tidak ada akses kepada hos (ia berada dalam projek yang berbeza sama sekali) - pg_hba dan sebagainya, dan juga tidak ada akses di bawah superuser.
Pilihan penyelesaian No. 1
Selepas refleksi lebih lanjut dan mengambil kira keadaan sebelumnya, aliran pemikiran berubah sedikit:
- Kami masih cuba untuk kekal dalam CloudSQL, tetapi kami beralih kepada MySQL, kerana Cloud SQL oleh MySQL mempunyai induk luaran, yang:
β ialah proksi untuk MySQL luaran;
- kelihatan seperti contoh MySQL;
- dicipta untuk memindahkan data daripada awan lain atau Di premis.
Memandangkan menyediakan replikasi MySQL tidak memerlukan akses kepada hos, pada dasarnya semuanya berfungsi, tetapi ia sangat tidak stabil dan menyusahkan. Dan apabila kami pergi lebih jauh, ia menjadi benar-benar menakutkan, kerana kami menggunakan keseluruhan struktur dengan terraform, dan tiba-tiba ternyata tuan luar tidak disokong oleh terraform. Ya, Google mempunyai CLI, tetapi atas sebab tertentu semuanya berfungsi di sini dari semasa ke semasa - kadangkala ia dicipta, kadangkala ia tidak dicipta. Mungkin kerana CLI dicipta untuk pemindahan data luaran, dan bukan untuk replika.
Sebenarnya, pada ketika ini menjadi jelas bahawa Cloud SQL tidak sesuai sama sekali. Seperti yang mereka katakan, kami melakukan segala yang kami mampu.
Pilihan penyelesaian No. 2
Memandangkan tidak mungkin untuk kekal dalam rangka kerja Cloud SQL, kami cuba merumuskan keperluan untuk penyelesaian kompromi. Syaratnya ternyata seperti berikut:
- bekerja dalam Kubernetes, penggunaan maksimum sumber dan keupayaan Kubernetes (DCS, ...) dan GCP (LB, ...);
- kekurangan balast daripada sekumpulan perkara yang tidak perlu dalam awan seperti proksi HA;
- keupayaan untuk menjalankan PostgreSQL atau MySQL di rantau HA utama; di kawasan lain - HA dari RR wilayah utama ditambah salinannya (untuk kebolehpercayaan);
- multi master (saya tidak mahu menghubunginya, tetapi ia tidak begitu penting)
.
Hasil daripada tuntutan ini, hlmDBMS yang sesuai dan pilihan pengikatan:
- MySQL Galera;
- CockroachDB;
- Alat PostgreSQL
:
- pgpool-II;
- Penaung.
MySQL Galera
Teknologi MySQL Galera dibangunkan oleh Codership dan merupakan pemalam untuk InnoDB. Keanehan:
- berbilang tuan;
- replikasi segerak;
- membaca dari mana-mana nod;
- rakaman ke mana-mana nod;
- mekanisme HA terbina dalam;
- Terdapat carta Helm daripada Bitnami.
LipasDB
Menurut keterangan, perkara itu benar-benar bom dan merupakan projek sumber terbuka yang ditulis dalam Go. Peserta utama ialah Cockroach Labs (diasaskan oleh orang dari Google). DBMS hubungan ini pada asalnya direka bentuk untuk diedarkan (dengan penskalaan mendatar di luar kotak) dan bertolak ansur dengan kesalahan. Pengarangnya daripada syarikat itu menggariskan matlamat untuk "menggabungkan kekayaan fungsi SQL dengan kebolehcapaian mendatar yang biasa dengan penyelesaian NoSQL."
Bonus yang bagus ialah sokongan untuk protokol sambungan pasca-gress.
pgpool
Ini adalah tambahan kepada PostgreSQL, sebenarnya, entiti baharu yang mengambil alih semua sambungan dan memprosesnya. Ia mempunyai pengimbang beban dan penghurai sendiri, dilesenkan di bawah lesen BSD. Ia menyediakan banyak peluang, tetapi kelihatan agak menakutkan, kerana kehadiran entiti baharu boleh menjadi punca beberapa pengembaraan tambahan.
Patroni
Ini adalah perkara terakhir yang saya lihat, dan, ternyata, tidak sia-sia. Patroni ialah utiliti sumber terbuka, yang pada asasnya adalah daemon Python yang membolehkan anda mengekalkan kelompok PostgreSQL secara automatik dengan pelbagai jenis replikasi dan penukaran peranan automatik. Perkara itu ternyata sangat menarik, kerana ia berintegrasi dengan baik dengan cuber dan tidak memperkenalkan sebarang entiti baru.
Apa yang anda pilih pada akhirnya?
Pilihannya tidak mudah:
- LipasDB - api, tetapi gelap;
- MySQL Galera - juga tidak buruk, ia digunakan di banyak tempat, tetapi MySQL;
- pgpool β banyak entiti yang tidak perlu, integrasi begitu-begitu dengan awan dan K8;
- Patroni - penyepaduan yang sangat baik dengan K8, tiada entiti yang tidak perlu, disepadukan dengan baik dengan GCP LB.
Oleh itu, pilihan jatuh pada Patroni.
Penemuan
Sudah tiba masanya untuk merumuskan secara ringkas. Ya, dunia infrastruktur IT telah berubah dengan ketara, dan ini hanyalah permulaan. Dan jika sebelum ini awan hanyalah satu lagi jenis infrastruktur, kini semuanya berbeza. Lebih-lebih lagi, inovasi dalam awan sentiasa muncul, ia akan muncul dan, mungkin, ia akan muncul hanya di awan dan hanya kemudian, dengan usaha pemula, ia akan dipindahkan ke On-premises.
Bagi SQL, SQL akan hidup. Ini bermakna anda perlu mengetahui PostgreSQL dan MySQL dan boleh bekerja dengan mereka, tetapi yang lebih penting ialah dapat menggunakannya dengan betul.
Sumber: www.habr.com