Bagaimana Xiaomi Kelola Miliaran Data? Ini Peran OceanBase di Baliknya

Pertumbuhan bisnis digital tidak hanya membawa lebih banyak pengguna, tetapi juga menghasilkan volume data yang terus membesar. Bagi perusahaan seperti Xiaomi, peningkatan data dari jutaan menuju miliaran baris membuat kebutuhan database ikut berubah. Infrastruktur yang sebelumnya mampu menangani beban kerja dapat menjadi semakin rumit ketika transaksi, analytics, flash sale, dan ekspansi global harus berjalan bersamaan.

Di sinilah tantangan Xiaomi menjadi menarik. Perusahaan tidak hanya membutuhkan database yang cepat, tetapi juga arsitektur yang mampu berkembang, tetap tersedia ketika terjadi gangguan, efisien dari sisi resource, dan fleksibel digunakan pada berbagai lingkungan infrastruktur.

​Baca Selengkapnya: OceanBase Database: Rahasia Perusahaan Besar Menangani Jutaan Transaksi Tanpa Gangguan

Ketika Data Terus Bertambah, Sharding Jadi Semakin Rumit

Salah satu tantangan utama Xiaomi datang dari penggunaan MySQL yang di-sharding secara manual di belakang proxy layer. Pendekatan tersebut membantu membagi workload, tetapi kompleksitasnya ikut meningkat setiap kali kapasitas bertambah.

Ketika volume data tumbuh dari jutaan baris menuju miliaran, logic sharding dan routing yang berada di sisi aplikasi menjadi semakin sulit dikelola. Setiap resize atau perubahan kapasitas menambah operational overhead dan engineering effort. Database yang cepat pada cluster kecil pun tetap dapat menemui batas ketika skala bisnis terus bertambah.

Situasi menjadi semakin menantang ketika Xiaomi menjalankan flash sale dan live-streaming campaign. Aktivitas seperti ini dapat mendorong database menerima traffic tinggi dalam waktu singkat sehingga sistem harus tetap responsif sekaligus konsisten.

Disaster Recovery Juga Membutuhkan Banyak Resource

Tantangan lain muncul dari arsitektur disaster recovery tradisional. Pada wilayah dengan dua data center, pola umum adalah menjalankan satu primary cluster dan satu standby cluster. Masalahnya, standby cluster tetap membutuhkan hardware meskipun tidak menangani workload utama.

Kondisi tersebut semakin kompleks karena infrastruktur Xiaomi mencakup self-built data center, public cloud, serta isolated zone untuk memenuhi kebutuhan compliance di beberapa pasar.

Karena itu, database berikutnya harus mampu menjawab beberapa kebutuhan sekaligus: scaling, stability, performance, disaster recovery, efisiensi biaya, fleksibilitas deployment, hingga mengurangi risiko ketergantungan terhadap satu cloud provider.

Mengubah Arsitektur Menjadi Distributed Database

Untuk menjawab kebutuhan tersebut, Xiaomi memindahkan workload database yang paling demanding ke OceanBase.

Melalui pendekatan distributed database, workload yang sebelumnya tersebar pada banyak sharded MySQL dapat dikonsolidasikan ke satu distributed engine. Kompatibilitas dengan MySQL wire protocol juga membantu menjaga perubahan pada aplikasi tetap minimal.

Arsitektur ini membawa beberapa kemampuan utama, mulai dari integrasi single-node menuju distributed architecture, pemisahan storage dan compute, unified TP/AP engine, hingga multi-tenancy untuk menangani berbagai workload dalam satu cluster.

Konsolidasi tersebut penting karena tantangan database berskala besar bukan hanya soal menambah server. Semakin banyak database, proxy, cluster, dan node khusus yang harus dikelola, semakin besar pula operational overhead bagi tim IT.

Satu Platform untuk Transactional dan Analytical Workload

Sebelumnya, kebutuhan analytical query pada lingkungan MySQL dapat membutuhkan AP-only node tambahan di belakang proxy. Pendekatan ini memang membantu menjalankan analytics, tetapi pada saat yang sama menambah server dan pekerjaan operasional.

Dengan kemampuan Hybrid Transactional/Analytical Processing atau HTAP, platform OceanBase memungkinkan transactional dan analytical workload dijalankan pada platform database yang sama.

Untuk transaksi yang sensitif terhadap latency, partition leader dapat dikonsentrasikan pada satu zone. Sebaliknya, untuk workload yang lebih berat pada analytics, leader dapat didistribusikan ke beberapa zone agar resource dari banyak node bisa dimanfaatkan.

Dengan demikian, perbedaan karakter workload dapat ditangani tanpa harus terus membangun database stack terpisah.

Distributed Architecture untuk Menjaga Konsistensi

Pada lingkungan distributed, konsistensi data menjadi salah satu aspek penting. Xiaomi menggunakan Paxos-based synchronous replication pada implementasi OceanBase untuk menjaga konsistensi antar-replica.

Untuk deployment standar, sistem berjalan pada tiga data center dengan tiga full-featured replica: satu leader dan dua follower.

Pada wilayah yang hanya memiliki dua data center, arbitration replica dapat menjadi bagian dari quorum tanpa harus membawa full copy data. Pendekatan tersebut membantu memenuhi kebutuhan disaster recovery tanpa harus menyiapkan satu full standby cluster yang hanya menunggu terjadinya kegagalan.

Konsep primary-standby tenant juga memungkinkan dua cluster saling menjadi backup. Masing-masing dapat menjalankan primary tenant sendiri sekaligus menjadi standby untuk tenant yang berada di cluster lainnya.

Dengan begitu, resource yang tersedia tidak harus menganggur hanya untuk kebutuhan disaster recovery.

Apa Hasil yang Didapat Xiaomi?

Transformasi database tersebut menghasilkan beberapa indikator konkret yang menunjukkan dampak implementasinya.

1. RTO Kurang dari 8 Detik dan RPO 0

Xiaomi mencatat automatic recovery dengan Recovery Time Objective (RTO) di bawah 8 detik. Pada saat yang sama, Recovery Point Objective (RPO) mencapai 0 melalui synchronous replication berbasis Paxos. Artinya, pada skenario yang dilaporkan dalam studi kasus tersebut, arsitektur dirancang untuk melakukan recovery dengan cepat sekaligus tanpa kehilangan data.

2. Storage Footprint 3–5× Lebih Kecil

Penggunaan LSM-tree compression menghasilkan pengurangan on-disk footprint sekitar 3–5 kali, bergantung pada workload dan baseline database yang dibandingkan. Bersama dengan konsolidasi instance, efisiensi storage tersebut menjadi salah satu faktor utama yang mendorong penurunan Total Cost of Ownership (TCO) setelah migrasi.

3. Performa Tetap Kompetitif

Performa transactional tetap berada pada kisaran stack sharded MySQL plus proxy yang digunakan Xiaomi sebelumnya. P99 latency yang mendekati lingkungan lama menunjukkan bahwa konsolidasi database tidak harus dibayar dengan mengorbankan performa pada jalur transaksi yang sensitif terhadap latency hal yang sangat penting dalam aktivitas seperti flash sale.

4. Tidak Perlu Idle Standby Cluster

Arbitration replica dan skema primary-standby tenant memungkinkan resource digunakan secara lebih produktif. Alih-alih menyediakan satu cluster penuh yang hanya menunggu terjadinya failure, cluster yang tersedia dapat tetap membawa workload nyata.

5. Banyak Workload Bisa Berbagi Cluster

Kemampuan multi-tenant resource isolation membuat beberapa bisnis dapat berbagi cluster tanpa satu workload mengambil kapasitas workload lainnya. Bagi perusahaan berskala besar, manfaat ini penting karena efisiensi database bukan hanya berasal dari kapasitas storage atau jumlah server, tetapi juga dari berkurangnya kompleksitas yang harus ditangani setiap kali bisnis berkembang.

Pelajaran dari Xiaomi untuk Perusahaan yang Sedang Bertumbuh

Studi kasus Xiaomi menunjukkan bahwa masalah database sering kali baru terasa ketika pertumbuhan bisnis mulai menekan batas dari arsitektur yang digunakan sebelumnya.

Sharding mungkin masih efektif pada tahap tertentu. Namun semakin banyak data, aplikasi, transaksi, dan lokasi deployment, semakin besar pula pekerjaan operasional di belakangnya.

Karena itu, strategi database sebaiknya tidak hanya menjawab kebutuhan hari ini. Perusahaan perlu mempertimbangkan bagaimana sistem melakukan scaling, bagaimana proses recovery berlangsung ketika terjadi gangguan, berapa banyak resource yang menganggur, hingga apakah analytical workload membutuhkan infrastruktur terpisah.

Chunhua Cui, Database Expert di Xiaomi Group, menggambarkan platform yang digunakan perusahaan sebagai kombinasi kapabilitas yang dekat dengan Oracle, membawa ekosistem MySQL, sekaligus menambahkan kemampuan distributed scale.

Ingin Infrastruktur Database Lebih Siap Menghadapi Pertumbuhan Bisnis?

Ketika volume data terus meningkat, menambah server bukan selalu menjadi jawaban terbaik. Arsitektur database yang semakin kompleks justru dapat membuat scaling, disaster recovery, maintenance, dan penggunaan resource semakin sulit dikendalikan.

Virtuenet dapat membantu perusahaan mengevaluasi kebutuhan database dan memahami bagaimana solusi distributed database seperti OceanBase dapat diterapkan sesuai workload, skala data, kebutuhan high availability, serta arsitektur infrastruktur perusahaan.

Ingin mengetahui apakah OceanBase cocok untuk kebutuhan database bisnis Anda? Hubungi tim Virtuenet untuk konsultasi dan diskusi lebih lanjut mengenai strategi database yang lebih scalable, resilient, dan efisien.

Coba Demo Gratis

Temukan insight lainnya dari solusi Virtuenet:

• 7 Masalah Operasional yang Sering Terjadi di Pabrik

• 9 Aplikasi Kolaborasi Terbaik untuk Bisnis di 2026

• Mengandalkan WhatsApp untuk Approval? Saatnya Beralih ke Sistem yang Lebih Terukur

• Laporan Keuangan Lengkap, tapi Sulit Ambil Keputusan? Ini Cara Melihat Kinerja Bisnis Lebih Jelas

FAQ (Frequently Asked Questions)

1. Apa itu OceanBase dan mengapa Xiaomi menggunakannya?

   Sebagai distributed database, solusi ini mendukung transactional dan analytical workload dalam satu platform. Xiaomi menggunakannya untuk membantu mengatasi kompleksitas manual sharding, kebutuhan scaling, disaster recovery, efisiensi resource, hingga deployment pada lingkungan hybrid-cloud.

2. Apa manfaat OceanBase yang dirasakan Xiaomi?

   Berdasarkan customer story resminya, Xiaomi mencatat RTO di bawah 8 detik, RPO 0, pengurangan on-disk footprint sekitar 3–5 kali, P99 latency yang mendekati stack sharded MySQL sebelumnya, serta berkurangnya kebutuhan akan idle standby cluster.

3. Apakah OceanBase hanya cocok untuk perusahaan sebesar Xiaomi?

   Tidak. Kebutuhannya lebih ditentukan oleh karakter workload dibandingkan ukuran brand. Perusahaan dengan pertumbuhan data tinggi, transaksi besar, kebutuhan high availability, arsitektur sharding yang semakin kompleks, atau deployment lintas data center dapat mempertimbangkan distributed database sebagai salah satu pendekatan untuk membangun infrastruktur yang lebih scalable.

Source

Semua informasi dalam artikel ini bersumber dari customer story dan dokumentasi resmi OceanBase. Berikut sumber utama yang dapat Anda verifikasi:

• How Xiaomi Modernized Its Data Foundation for Hybrid-Cloud Scale — OceanBase – Xiaomi Customer StoryStudi kasus resmi mengenai perjalanan Xiaomi menghadapi pertumbuhan data dari jutaan menuju miliaran baris, kompleksitas sharded MySQL, kebutuhan hybrid-cloud, serta implementasi OceanBase. Sumber ini juga mencatat hasil berupa RTO <8 detik, RPO 0, storage footprint 3–5× lebih kecil, P99 latency mendekati arsitektur MySQL sebelumnya, dan penghapusan idle standby cluster.

• OceanBase Database Architecture — OceanBase Documentation – Database ArchitectureDokumentasi resmi mengenai arsitektur distributed OceanBase, termasuk multiple replicas, Paxos protocol, resource isolation, multi-tenancy, storage-compute separation, serta kompatibilitas tenant dengan MySQL dan Oracle.

• Multi-Tenant Architecture of OceanBase Database — OceanBase Documentation – Multi-Tenant ArchitecturePenjelasan resmi mengenai bagaimana OceanBase menjalankan berbagai tenant dalam satu distributed database dengan thread dan resource yang terisolasi, mendukung konsolidasi workload sekaligus penggunaan resource yang lebih efisien.