Jasa Managed Database & Optimasi Basis Data

Masalah basis data yang paling sering kami temukan

Keluhan performa basis data hampir selalu berakar pada daftar pendek yang sama, dan sebagian besarnya bisa diperbaiki tanpa menambah perangkat keras:

• Konfigurasi bawaan yang tidak pernah disesuaikan dengan besarnya memori server.
• Indeks yang kurang, berlebihan, atau tidak lagi cocok dengan pola kueri saat ini.
• Kueri yang memindai seluruh tabel karena filter tidak bisa memanfaatkan indeks.
• Koneksi yang menumpuk tanpa connection pooling, membuat basis data kehabisan slot.
• Backup yang berjalan tetapi tidak pernah diuji pemulihannya.
• Tidak ada replika, sehingga kegagalan satu server berarti layanan berhenti total.

Basis data yang kami kelola

Kami menangani basis data relasional maupun non-relasional, baik yang dipasang sendiri di server Anda maupun yang memakai layanan terkelola dari penyedia cloud seperti Amazon RDS atau Cloud SQL.

• MySQL dan MariaDB — tuning InnoDB, replikasi, dan backup konsisten memakai XtraBackup.
• PostgreSQL — autovacuum, streaming replication, failover otomatis, dan pemulihan titik waktu.
• MongoDB — replica set, sharding, indeks, dan strategi backup untuk data dokumen.
• Microsoft SQL Server — always on availability group, maintenance plan, dan tuning indeks.
• Oracle Database — perawatan instance, tablespace, dan backup memakai RMAN.
• Redis — konfigurasi persistensi, eviction policy, serta pemakaiannya sebagai cache maupun antrean.

Strategi backup dan pemulihan yang benar-benar teruji

Backup basis data punya syarat yang lebih ketat daripada backup berkas biasa: ia harus konsisten. Menyalin berkas data saat basis data sedang menulis hampir pasti menghasilkan cadangan yang tidak bisa dipakai.

Karena itu kami memakai perkakas yang memahami internal masing-masing basis data, menyimpan cadangan di lokasi terpisah dari server aslinya, dan yang terpenting: menjalankan uji pemulihan berkala ke lingkungan terpisah. Anda menerima catatan hasil uji itu, bukan sekadar janji bahwa backup berjalan.

Replikasi dan ketersediaan tinggi

Replikasi memberi dua manfaat sekaligus: salinan data yang selalu segar untuk keadaan darurat, dan kemampuan mengarahkan kueri baca ke replika sehingga beban server utama berkurang.

Kami merancang topologi replikasi sesuai kebutuhan — mulai dari satu replika untuk cadangan, sampai konfigurasi dengan failover otomatis di mana replika langsung mengambil alih ketika server utama tidak merespons. Setiap konfigurasi disertai prosedur tertulis tentang apa yang harus dilakukan ketika failover benar-benar terjadi.

Jasa DBA outsourcing tanpa merekrut sendiri

Database administrator berpengalaman termasuk peran yang paling sulit direkrut, dan pada banyak perusahaan bebannya belum sepadan dengan satu posisi purnawaktu. Model jasa DBA outsourcing menjembatani itu: Anda mendapat perhatian ahli saat dibutuhkan, tanpa membayar kapasitas yang menganggur.

Dalam praktiknya, pekerjaan seorang database administrator Indonesia yang menangani beberapa klien punya keuntungan tambahan: pola masalah yang muncul di satu tempat sering sudah pernah ditemui di tempat lain. Waktu penelusuran jadi jauh lebih pendek dibanding menghadapinya untuk pertama kali.

Yang tetap menjadi wewenang tim Anda adalah skema dan kueri. Kami memberi masukan bila ada perubahan yang berpotensi memberatkan, tetapi keputusan desain data ada pada orang yang memahami bisnisnya.

Optimasi database lambat: urutan penelusurannya

Pekerjaan optimasi database lambat hampir selalu mengikuti urutan yang sama. Pertama, pastikan masalahnya benar di basis data — bukan di aplikasi yang membuka koneksi berlebihan atau di jaringan. Kedua, kumpulkan data kueri lambat selama beberapa hari agar yang diperbaiki adalah pola nyata, bukan kejadian tunggal.

Ketiga, urutkan berdasarkan total waktu yang dihabiskan, bukan durasi sekali jalan. Kueri 150 milidetik yang dipanggil sepuluh ribu kali per jam membebani jauh lebih besar daripada kueri lima detik yang dijalankan sekali sehari.

Keempat, baca rencana eksekusinya. Sebagian besar perbaikan berhenti di sini: satu indeks gabungan yang cocok dengan pola filter dan pengurutan. Perubahan perangkat keras baru dipertimbangkan setelah tiga langkah sebelumnya tidak lagi memberi ruang perbaikan.

Replikasi database dan ketersediaan

Menyiapkan replikasi database memberi dua manfaat yang sering dianggap satu: salinan data yang selalu segar untuk keadaan darurat, dan tempat mengarahkan kueri baca agar server utama lebih lega.

Keduanya perlu diperlakukan berbeda. Sebagai cadangan darurat, yang penting jeda replikasinya kecil dan dipantau — replika yang tertinggal setengah jam tidak berguna saat dibutuhkan. Sebagai pembagi beban, yang penting aplikasi tahu kueri mana yang aman dibaca dari replika, karena data yang baru ditulis mungkin belum sampai.

Untuk kebutuhan yang lebih ketat, replikasi bisa dilengkapi failover otomatis sehingga replika mengambil alih tanpa campur tangan manusia. Setiap konfigurasi seperti itu selalu kami sertai prosedur tertulis dan pengujian, karena mekanisme yang belum pernah diuji tidak bisa diandalkan.

Backup database otomatis dan pengujian pemulihan

Backup database otomatis punya syarat yang lebih ketat daripada backup berkas: ia harus konsisten. Menyalin direktori data saat basis data sedang menulis menghasilkan cadangan yang hampir pasti tidak bisa dipakai — dan hal itu baru diketahui pada saat paling tidak tepat.

Karena itu kami memakai perkakas yang memahami internal masing-masing basis data, menyimpan salinan di lokasi terpisah dari server aslinya, dan mengarsipkan log transaksi untuk memungkinkan pemulihan ke titik waktu tertentu.

Uji pemulihan dijalankan berkala ke lingkungan terpisah, dan hasilnya dicatat: berapa lama prosesnya, apakah datanya utuh, dan apa yang perlu diperbaiki. Angka lama proses itu sering yang paling mengejutkan pemilik sistem — dan paling berguna untuk menyusun rencana pemulihan yang realistis.