Cara Baru Mengelola Basis Data Sumber Terbuka

Belum lama ini, industri database terdiri dari beberapa vendor. Basis data sebagian besar bersifat relasional, dan dijalankan pada mesin tunggal. Ketersediaan tinggi diimplementasikan melalui 'cluster' siaga aktif. Dengan model 'peningkatan skala' vertikal, sebagian besar tentang penyimpanan bersama (SAN atau DRBD) atau replikasi log asinkron untuk menyinkronkan status ke node siaga. Pada tahun 2001, ketika saya mulai bekerja dengan NDB Cluster (yang kemudian menjadi MySQL Cluster), konsep menyimpan seluruh database di memori utama adalah aneh - 'bagaimana jika Anda mematikan server?'. Mendistribusikan database di beberapa server mengkhawatirkan - 'Anda punya potongan data di sana-sini'. Dan seluruh ide database open source untuk beban kerja kritis misi sangat menggelikan.

Maju cepat 15 tahun dan kami sekarang memiliki lusinan vendor database di pasar - kebanyakan open source, model yang berbeda (nilai kunci, dokumen, grafik, ...) dan didistribusikan secara default. Data memori-residen cukup banyak norma untuk mencapai kinerja tinggi dan latency rendah. Tiga dari 5 database terpopuler (menurut peringkat db-engines) adalah open source (MySQL, PostgreSQL, dan MongoDB). Saat ini, Anda lebih cenderung mengelola armada server basis data yang didistribusikan di berbagai pusat data. Anda bahkan mungkin memiliki beberapa database yang dikelola oleh vendor cloud pihak ketiga.

Jadi, seperti apa mengelola database di tahun 2018?

OTOMATIS

Dengan begitu banyak tugas yang harus dikelola dan hanya berjam-jam dalam sehari, orang akan gila jika melakukan hal-hal secara manual.

Otomatisasi adalah cara yang bagus untuk menyelesaikan sesuatu. Ketika kami memiliki beberapa database untuk dikelola, mengoperasikan database akan sangat praktis, dengan beberapa tugas yang ditulis dalam sesuatu seperti bash atau perl - mis., skrip untuk membuat cadangan database, yang lain untuk memindahkan file cadangan ke beberapa lokasi. Failover akan manual, dan kami bahkan akan memperdebatkan apakah itu harus otomatis atau tidak.

Saat ini, otomatisasi sudah tidak asing lagi. Ada sejumlah otomatisasi TI atau sistem manajemen konfigurasi yang dapat dimanfaatkan - Wayang, Koki, Ansible, dan Salt semuanya menawarkan kerangka kerja tujuan umum yang dapat digunakan untuk membangun otomatisasi untuk topologi basis data yang berbeda. Perangkat lunak manajemen cluster yang ditulis khusus untuk mengelola pengaturan basis data termasuk MongoDB Ops Manager dan ClusterControl. Mereka memungkinkan tim operasi untuk mengelola klaster mereka dengan sesuatu yang sudah tersedia secara langsung. Membangun sistem manajemen cluster dari awal menggunakan sistem manajemen konfigurasi bukanlah hal yang mudah. Ini membutuhkan keahlian yang signifikan dalam alat otomatisasi serta pemahaman tentang operasi manajemen seperti penjadwalan dan verifikasi pencadangan, failover otomatis dengan konfigurasi ulang sistem berikutnya, meluncurkan perubahan konfigurasi, patching, peningkatan atau penurunan versi, dll.

Dan tentu saja, ada kebangkitan platform layanan DBaaS, di mana penyebaran, kesehatan, failover, pencadangan, dll., Semuanya dikendalikan oleh perangkat lunak. Penyedia cloud memang sangat ahli dalam hal otomatisasi. Amazon RDS adalah contoh yang bagus dari otomatisasi database dalam skala besar - ini mengotomatiskan penerapan, peningkatan patch, pencadangan, pemulihan titik waktu, penskalaan replika, dan ketersediaan/kegagalan tinggi.

PETS vs SAPI

Pada tahun 90-an dan hingga dotcom boom dan bust, Sun Microsystems dan Oracle menghasilkan banyak uang dengan menjual basis data yang ditingkatkan pada perangkat keras SMTP besar. Masukkan beberapa penyimpanan SAN dan perangkat lunak failover Veritas dan Anda akan mendapatkan cluster failover siaga aktif yang canggih untuk ketersediaan tinggi. Server basis data relatif sedikit jumlahnya, tetapi kuat karena mereka akan tumbuh secara vertikal. Mereka diberi nama (sama seperti Anda menamai hewan peliharaan Anda!), dan dirawat oleh DBA.

Saat ini, database murah dan berjalan dengan baik pada perangkat keras komoditas. Ada banyak dari mereka, dan kami memberi mereka nomor - seperti ternak. Jika satu rusak, kita bisa mendapatkan yang baru.

Ini juga merupakan jenis sapi baru - sapi open source! Tiga dari lima database teratas, menurut db-engines, semuanya open source - mereka perlahan tapi pasti menggerogoti pangsa pasar dari dua vendor berpemilik. Open source adalah standar pusat data baru, tidak hanya untuk sistem operasi tetapi juga untuk database.

Jadi apa artinya ini bagi Anda? Nah, di masa mendatang, Anda cenderung mengelola database open source - atau bahkan beberapa database untuk aplikasi yang menggunakan kumpulan data heterogen. Dalam dunia persistensi poliglot dan layanan mikro, penyimpanan data yang mendasarinya sekarang ditentukan oleh sifat data. Dari sudut pandang arsitektur, database instans tunggal dengan HA berbasis disk memberikan jalan ke kluster yang berpotensi didistribusikan di beberapa pusat data.

Apakah kita membutuhkan DBA?

Peran DBA adalah peran khusus - dibutuhkan pengalaman bertahun-tahun untuk menjadi satu. Di masa lalu, ketika hanya ada beberapa vendor database berpemilik untuk dipilih, Anda akan memiliki DBA khusus dengan serangkaian keterampilan dan pengalaman tertentu. Itu juga diperlukan - database seperti Oracle atau SQL Server memiliki set fitur yang sangat besar, dibangun selama beberapa dekade. Mereka tidak mudah untuk dikelola. Mereka biasanya digunakan sebagai satu-satunya database untuk aplikasi, dan perlu dipantau, data dicadangkan, dan masalah apa pun yang muncul dengan sendirinya harus ditangani. Tugas-tugas inilah yang menjadi fokus DBA di sini.

Namun, dalam dekade terakhir, industri basis data baru telah muncul - dengan lusinan basis data sumber terbuka, serta layanan basis data cloud. Seperti yang kita lihat sebelumnya, tidak jarang sebuah aplikasi menggunakan beberapa penyimpanan data yang berbeda. Tetapi perusahaan jarang memiliki DBA untuk penyimpanan data yang mereka gunakan ini. Di mana Anda menemukan DBA MongoDB atau Cassandra atau dengan pengalaman produksi 5+ tahun? Orang dapat berargumen bahwa generasi baru database NoSQL jauh lebih sederhana daripada pendahulunya yang sumber tertutup, dan oleh karena itu tidak akan menimbulkan kurva pembelajaran yang sama.

Mengelolanya hanyalah tugas lain yang ditambahkan ke daftar tugas tim SysAdmin atau DevOps atau Site Reliability Engineering (SRE). Dan kita melihat hari ini bahwa banyak perusahaan tidak memiliki DBA penuh waktu. Tanggung jawab malah didistribusikan ke seluruh tim, dengan alat otomatisasi yang semakin banyak digunakan untuk menangani tugas rutin sehari-hari. Untuk database yang telah dipindahkan ke cloud, aspek operasional tentang bagaimana data disimpan dialihdayakan sepenuhnya ke penyedia cloud. Jadi, alih-alih bekerja pada cara menyimpan data, tim operasi kini dapat fokus pada penggunaan data.

Siklus Hidup Basis Data

Siklus hidup rata-rata database dulu jauh lebih lama daripada sekarang. Setelah Anda memilih platform database, itu saja. Keputusan akan dibuat antara dua atau tiga database relasional, biasanya oleh DBA atau seseorang yang lebih tinggi dalam organisasi. Perusahaan akan mencari uang untuk membeli lisensi abadi. Setelah keputusan diambil, Anda sekarang harus menjalaninya selama 10+ tahun ke depan. Basis data bersifat monolitik, dan aplikasi biasanya menggunakan satu basis data bersama.

Saat ini, di dunia container, cloud, microservices, dan pipeline CI/CD, tidak jarang pengembang membuat pilihan teknologi - terutama jika itu adalah database open source yang dapat dengan mudah diunduh, atau ditawarkan sebagai layanan, tanpa harus berbicara dengan perwakilan penjualan, atau harus mencari anggaran dari manajemen. Organisasi ditantang untuk menciptakan nilai lebih cepat, sehingga tingkat perubahan pada infrastruktur/aplikasi telah meningkat secara dramatis. Basis data monolitik sekarang dipecah menjadi beberapa basis data kecil, dengan setiap basis data mengelola data domain untuk layanan mikro individu. Dengan berbagai produk database yang tersedia saat ini di ekosistem open source, tim memiliki pilihan dan kebebasan untuk pindah ke penyimpanan data yang lebih baik. Saat layanan ditugaskan dan dinonaktifkan, basis data juga mengikuti - meskipun data itu sendiri mungkin diarsipkan atau dipindahkan ke danau data. Dalam lanskap infrastruktur yang jauh lebih dinamis saat ini, kami menemukan bahwa database kami memiliki umur yang lebih pendek.

PERAN DBA

DBA, biasanya penjaga dan penjaga gerbang database, akan melayani kebutuhan database dari tim aplikasi/infrastruktur yang berbeda dalam organisasi. Setiap perubahan yang memerlukan akses atau perubahan ke database akan memerlukan layanan DBA. Namun, prioritas yang saling bertentangan dan kurangnya ketersediaan DBA dapat menyebabkan proyek akan diblokir/ditunda, dan gesekan yang tak terhindarkan akan menyusul.

Kolaborasi yang mahal dan inovasi yang cepat/waktu yang singkat untuk memasarkan tidak berjalan dengan baik. Seperti yang kita lihat sebelumnya, layanan mikro adalah contoh bagaimana infrastruktur dan layanan aplikasi sekarang dirancang untuk memisahkan sebanyak mungkin. Basis data semakin diotomatisasi, dan kendali basis data beralih ke pengembang atau tim proyek. Bahkan hal-hal seperti perubahan skema tidak seberat dulu. Mereka jauh lebih sulit dalam konteks database pusat untuk aplikasi monolitik. Dengan data yang dibagikan di antara komponen yang berbeda, perubahan skema perlu dikoordinasikan dan direncanakan dengan cermat - biasanya berbulan-bulan sebelumnya. DBA memiliki peran kunci dalam memahami dan melakukan perubahan. Dinamika berbeda saat ini, di mana laju perubahan jauh lebih cepat. Bukan hal yang aneh bagi tim pengembangan untuk mendorong perubahan kode dalam produksi setiap minggu atau setiap hari - atau bahkan beberapa kali sehari! Basis data membutuhkan pembaruan konstan untuk mengikuti perubahan aplikasi, dan ini dilakukan oleh pengembang. Beberapa database yang lebih baru seperti MongoDB bahkan membuatnya sangat sederhana dengan memiliki model tanpa skema. Artinya secara efektif adalah bahwa skema database pindah ke kode aplikasi.

Jadi jika semua tugas inti umum sedang diotomatisasi, apa yang akan terjadi pada peran DBA di masa mendatang? Alih-alih berfokus pada tugas administratif, DBA akan lebih berfungsi sebagai mentor bagi tim lain dalam organisasi. Organisasi perlu memahami data apa yang mereka miliki, dan bagaimana data tersebut dapat digunakan. Bagaimanapun, data paling berharga ketika dibagikan dan digabungkan dengan sumber daya lain, tidak hanya disimpan. Tanpa skema kedengarannya bagus, tetapi kami masih perlu melacak data kami - baik dalam database atau dalam kode. Keamanan adalah sebuah tantangan, dan pelanggaran data terus memburuk. Jadi, jika kita ingin membuat data menjadi hebat lagi, DBA perlu beralih ke peran penasihat/pemungkin horizontal yang mencakup seluruh tim. Dari perspektif kompetensi, DBA modern perlu memahami bagaimana merancang sistem ketersediaan tinggi yang terdistribusi, dan menerapkan sistem otomasi yang efisien untuk menangani tugas-tugas biasa. Saat perusahaan menerapkan infrastruktur di seluruh lingkungan cloud atau bahkan container, memahami cara membangun database yang sangat tersedia dan skalabel pada platform ini akan memastikan kelangsungan hidup DBA.

Ringkasan

Kami sedang duduk di persimpangan yang menarik dalam sejarah industri database, yang telah melalui transformasi besar-besaran dalam 2 dekade terakhir. Tabel di bawah mencoba merangkumnya.

Saya tertarik untuk mendengar pendapat Anda tentang manajemen basis data sumber terbuka dan apakah Anda pernah melihat tren yang sama? Seperti apa perjuangan atau keberhasilan Anda dengan OSDB dalam beberapa tahun terakhir ini? Dan apa yang Anda ramalkan akan terjadi tahun depan?

Kami di Somenines akan terus bekerja keras untuk membantu memfasilitasi pengelolaan dan otomatisasi database open source Anda hingga tahun depan dan seterusnya. Jadi nantikan pembaruannya mulai Januari mendatang.

Tapi sementara itu, beri tahu saya pendapat Anda, dan sampai jumpa di 2019!

Foto oleh SoRad (Shutterstock) &The Simpsons; foto lainnya dibuat oleh pemiliknya masing-masing.