- Apple menggunakan Cassandra dan FoundationDB untuk iCloud dan CloudKit
- Database-database ini menyimpan miliaran database dalam arsitektur multi-tenant yang ekstrem
Pelajaran dunia nyata yang tak lekang oleh waktu
- Meta dan Apple sama-sama menggunakan pemrosesan asinkron untuk membuat fitur pengguna berjalan mulus
- Kedua perusahaan menggunakan arsitektur stateless untuk mengatasi masalah skalabilitas
- Mengisolasi sumber daya secara logis untuk memastikan keandalan dan ketersediaan
- Menangani beragam kebutuhan dengan sederhana
- Membangun lapisan abstraksi untuk meningkatkan pengalaman pengembang
- Memahami pengguna dan menentukan setiap lapisan, API, dan desain berdasarkan hal itu
Cassandra
- Cassandra adalah sistem manajemen database NoSQL berbasis kolom yang tersebar luas
- Awalnya dikembangkan di Facebook untuk fitur pencarian inbox Facebook
- Menariknya, Meta sendiri telah mengganti sebagian besar penggunaan Cassandra dengan ZippyDB ZippyDB
- iCloud sebagian menggunakan Cassandra, dan Apple mengoperasikan salah satu deployment Cassandra terbesar di dunia
- lebih dari 300 ribu instance/node
- ratusan petabyte data
- lebih dari 2 petabyte per klaster
- jutaan kueri per detik
- ribuan aplikasi
- Cassandra masih terus ditingkatkan secara aktif di Apple
- Namun, CloudKit + Cassandra menemui batas skalabilitas sehingga Apple mengadopsi FoundationDB
FoundationDB
- Apple menggunakan FoundationDB secara terbuka dan mengakuisisinya pada 2015
- FoundationDB adalah penyimpanan key-value transaksional terdistribusi open source yang dirancang untuk menangani data berskala besar
- Cocok baik untuk beban kerja baca/tulis maupun beban kerja yang berat di penulisan
- Apple menggunakan FoundationDB Record Layer secara luas di CloudKit
- FoundationDB Record Layer menyediakan API Java untuk penyimpanan data terstruktur
- Record Layer mendukung multi-tenancy yang ekstrem
Mengapa menggunakan Record Layer di FoundationDB
- FoundationDB menangani sistem terdistribusi dan pekerjaan kontrol konkurensi.
- Record Layer berperan sebagai database relasional yang membuat FoundationDB lebih mudah digunakan.
- CloudKit berada di lapisan paling atas dan menyediakan fitur serta API bagi pengembang aplikasi.
- Melalui Record Layer, Apple mendukung multi-tenancy skala besar
- Digunakan untuk multi-tenancy ekstrem yang menyediakan penyimpanan record independen bagi setiap pengguna dari setiap aplikasi
- Meng-host miliaran database independen yang berbagi ribuan skema
Bagaimana CloudKit menggunakan FoundationDB dan Record Layer
- Di CloudKit, aplikasi direpresentasikan sebagai 'kontainer logis' yang mengikuti skema yang telah ditentukan
- Skema ini merangkum tipe record, field, dan indeks yang diperlukan untuk pengambilan dan kueri data yang efisien
- Aplikasi dapat mengatur data sebagai 'zona' di dalam CloudKit untuk mengelompokkan record secara logis agar dapat disinkronkan secara opsional dengan perangkat klien
- Setiap pengguna diberi subspace unik di dalam FoundationDB, dan penyimpanan record dibuat untuk setiap aplikasi yang berinteraksi dengan pengguna tersebut
- Pada dasarnya, CloudKit mengelola jumlah database logis yang sangat besar, setara dengan jumlah pengguna dikali jumlah aplikasi
- Setiap database memiliki set record, indeks, dan metadata-nya sendiri, sehingga totalnya mencapai miliaran database
- Saat menerima permintaan dari perangkat klien, CloudKit meneruskan permintaan ini ke proses layanan CloudKit yang tersedia melalui load balancing
- Proses tersebut menangani permintaan dengan berinteraksi dengan penyimpanan record Record Layer tertentu
- CloudKit mengubah skema aplikasi yang telah ditentukan menjadi definisi metadata di dalam Record Layer yang disimpan dalam metadata store terpisah
- Metadata ini diperkaya oleh field sistem khusus CloudKit yang melacak waktu pembuatan, waktu modifikasi, dan zona tempat record disimpan
- Agar record di setiap zona dapat diakses secara efisien, primary key diberi prefiks nama zona
- Bersama indeks yang didefinisikan pengguna, CloudKit juga mengelola 'indeks sistem' untuk keperluan internal seperti manajemen kuota penyimpanan dengan melacak ukuran record per tipe
Dengan menggunakan FoundationDB dan Record Layer bersama-sama, Apple dapat menyelesaikan 4 masalah utama yang tidak bisa diatasi hanya dengan Cassandra
1. Menyelesaikan masalah pencarian full-text yang dipersonalisasi
- FoundationDB mendukung pencarian full-text yang dipersonalisasi agar pengguna bisa mengakses data mereka dengan cepat
- Dengan memanfaatkan urutan key di FoundationDB, sistem dapat dengan cepat mencari awal teks (pencocokan prefiks), sekaligus melakukan pencarian yang lebih kompleks tanpa overhead tambahan, seperti pencarian kedekatan dan pencarian frasa untuk menemukan kata-kata yang berdekatan atau dalam urutan tertentu
- Di sistem pencarian tradisional, sering kali perlu menjalankan proses tambahan di latar belakang untuk menjaga indeks pencarian tetap mutakhir, tetapi sistem Apple menangani semuanya secara real-time sehingga indeks pencarian langsung diperbarui begitu data berubah tanpa memerlukan langkah tambahan
2. Menyelesaikan masalah zona dengan konkurensi tinggi
- CloudKit menggunakan FoundationDB untuk menangani banyak pembaruan yang terjadi secara bersamaan dengan mulus
- Sebelumnya saat menggunakan Cassandra, CloudKit mengandalkan indeks khusus yang melacak perubahan di setiap zona untuk menyinkronkan data di banyak perangkat
- Saat perangkat perlu memperbarui data, perangkat memeriksa indeks ini untuk melihat apa yang baru
- Namun, pendekatan ini memiliki kelemahan karena tabrakan bisa terjadi ketika banyak pembaruan berlangsung secara bersamaan
- Dengan FoundationDB, CloudKit menggunakan jenis indeks khusus yang melacak urutan tepat setiap perubahan tanpa menimbulkan konflik
- Hal ini dilakukan dengan memberikan 'versi' unik pada setiap perubahan, lalu CloudKit memeriksa versi-versi ini saat sinkronisasi diperlukan untuk mengetahui pembaruan apa yang terlewat oleh perangkat
- Jika CloudKit perlu memindahkan data antar beberapa klaster penyimpanan untuk mendistribusikan beban dengan lebih merata, situasinya menjadi rumit karena nomor versi tiap klaster tidak cocok
- Untuk mengatasi ini, CloudKit memberi data setiap pengguna sebuah 'jumlah perpindahan' (disebut 'incarnation') yang bertambah setiap kali data dipindahkan ke klaster baru
- Setiap pembaruan record mencakup nomor 'incarnation' pengguna saat ini, sehingga bahkan setelah perpindahan, CloudKit tetap bisa menentukan urutan pembaruan yang benar dengan memeriksa incarnation dan nomor versi sekaligus
- Saat beralih ke sistem baru, CloudKit menghadapi masalah dalam menangani data lama yang tidak memiliki nomor versi ini
- Namun, masalah ini diatasi dengan cerdas menggunakan kemampuan khusus yang mengurutkan pembaruan lama dari sistem sebelumnya sebelum pembaruan dari sistem baru
- Berkat itu, tidak perlu membuat perubahan aplikasi yang rumit atau mempertahankan kode lama
- Untuk menjaga urutan riwayat yang benar, sistem mempertimbangkan nilai incarnation, versi, dan penghitung pembaruan lama
3. Menyelesaikan masalah kueri berlatensi tinggi
- FoundationDB dirancang untuk konkurensi tinggi, bukan latensi rendah. Artinya, sistem ini berfokus pada kemampuan menangani banyak pekerjaan secara bersamaan, bukan pada kecepatan tiap operasi individual
- Untuk memanfaatkan desain ini semaksimal mungkin, Record Layer menjalankan banyak pekerjaan secara 'asinkron'
- Pekerjaan yang akan selesai di masa depan dimasukkan ke antrean sehingga sistem bisa mengerjakan hal lain sementara menunggu
- Pendekatan ini membantu menutupi latensi yang bisa muncul selama pekerjaan tersebut
- Namun, alat yang digunakan FoundationDB untuk berkomunikasi dengan database dirancang menggunakan satu thread untuk jaringan, sehingga hanya dapat mengerjakan satu hal pada satu waktu
- Pada versi sebelumnya, pengaturan ini menyebabkan kemacetan lalu lintas di sistem karena semua pekerjaan harus menunggu giliran pada thread jaringan ini
- Karena Record Layer menggunakan pendekatan satu thread ini, bottleneck pun terjadi
- Untuk memperbaikinya, Apple mengurangi beban kerja pada thread jaringan ini
- Kini pekerjaan kompleks menjadi lebih cepat karena sistem dapat bekerja dengan database di banyak aspek secara bersamaan tanpa membentuk antrean
- Dengan begitu, latensi atau kesan lambat dapat disembunyikan karena sistem tidak perlu menunggu satu pekerjaan selesai sebelum memulai pekerjaan lain
4. Menyelesaikan masalah transaksi yang saling bertabrakan
- Di FoundationDB, 'konflik transaksi' terjadi ketika satu transaksi membaca key tertentu sementara transaksi lain memodifikasi key yang sama
- FoundationDB menyediakan kendali atas kumpulan key yang bisa menimbulkan konflik ini saat pembacaan atau penulisan, sehingga konflik dapat dikelola secara presisi
- Cara umum untuk menghindari konflik yang tidak perlu adalah melakukan jenis pembacaan khusus yang tidak memicu konflik, yaitu pembacaan 'snapshot', terhadap berbagai key
- Jika key penting ditemukan dalam pembacaan ini, transaksi hanya menandai key spesifik yang berpotensi menimbulkan konflik, bukan seluruh rentang
- Dengan begitu, transaksi hanya terpengaruh oleh perubahan yang benar-benar penting terhadap hasil
- Record Layer menggunakan strategi ini untuk mengelola secara efisien struktur bernama skip list yang merupakan bagian dari sistem indeks peringkat
- Namun, mengatur rentang konflik ini secara manual bisa rumit, dan jika tercampur dengan logika utama aplikasi, dapat menimbulkan bug yang sulit diidentifikasi
- Karena itu, dalam sistem yang dibangun di atas FoundationDB, sebaiknya dibuat alat tingkat lebih tinggi seperti indeks kustom untuk menangani pola semacam ini
- Pendekatan ini membantu mencegah situasi di mana tanggung jawab untuk melonggarkan aturan konflik diserahkan ke tiap aplikasi klien, yang bisa menyebabkan kesalahan dan ketidakkonsistenan
1 komentar
Komentar Hacker News
Seorang pengguna Hacker News membagikan wawasan dari pengalamannya saat bekerja di Apple tentang perbedaan antara basis data dan sistem berkas. Ia menyebut bahwa basis data dan sistem berkas pada dasarnya melakukan fungsi yang sama, dan merupakan optimasi untuk menyelesaikan masalah tertentu. Sebagai contoh, iCloud menunjukkan cara mendefinisikan sistem berkas di atas basis data. Pengguna ini juga membagikan pengalaman menggunakan Cassandra untuk penyimpanan video.
Pengguna lain menyebut pengalaman di perusahaan sebelumnya membangun sistem katalog transaksional menggunakan FoundationDB dan RecordLayer. Sistem ini sangat efektif, dan penggunaan gRPC serta Protobuf terasa alami. Namun, ia menyoroti kekurangan berupa tingginya hambatan masuk untuk mengoperasikan FoundationDB dalam skala besar.
Seorang pengguna menilai fitur sinkronisasi Apple Notes menangani konflik lebih baik daripada aplikasi catatan berbasis Markdown. Karena itu, ia menyebut akhirnya berpindah ke Apple Notes.
Disebutkan beberapa postingan sebelumnya tentang FoundationDB. Ini mencakup tautan mengenai penyimpanan key-value terdistribusi FoundationDB, Record Layer, akuisisi oleh Apple, serta cara kerja dan karakteristik FoundationDB.
Disebutkan hal menarik tentang arsitektur perangkat lunak desktop native yang secara bertahap berpindah ke penyimpanan berbasis cloud dan kolaborasi. Menangani perubahan skema dan migrasi versi dengan baik sangat penting, dan hal ini terjadi dalam skala besar tanpa campur tangan administrator.
Seorang pengguna berharap iCloud dapat menyimpan cadangan Time Machine.
Karena FoundationDB dibangun di atas SQLite, muncul rasa penasaran tentang kemungkinan mesin HCTree diterapkan ke FoundationDB. HCTree memiliki potensi meningkatkan performa baca/tulis SQLite hingga 10 kali lipat.
Ada keluhan tentang cara iCloud mengelola berkas pengguna. Terkadang menjadi masalah ketika iCloud secara otomatis memindahkan berkas, aplikasi, dan foto yang baru digunakan ke cloud untuk mengosongkan ruang.
Seorang pengguna mengenang sistem pelaporan bernama Hyperion yang pernah ia gunakan saat bekerja di bank pada masa lalu. Sistem ini membuat basis data baru untuk setiap laporan, yang saat itu terasa aneh, tetapi sekarang menurutnya justru merupakan pendekatan yang mendahului zamannya.