XTX Markets telah merilis TernFS sebagai open-source, sebuah sistem berkas terdistribusi yang mengelola lebih dari 600 petabyte data untuk operasi perdagangan frekuensi tinggi. Meskipun pencapaian ini menunjukkan skala yang signifikan, komunitas teknis telah mengajukan pertanyaan penting tentang pilihan desain dan keterbatasan sistem yang perlu dipertimbangkan oleh calon pengguna.
Spesifikasi Utama TernFS :
- Skala: 600+ petabyte dalam satu deployment
- Ukuran file median: 2MB (tidak dioptimalkan untuk file kecil)
- Backend: CockroachDB untuk manajemen metadata
- Jaringan: TCP/IP (tidak mendukung RDMA)
- Konsensus: Algoritma kustom mirip Raft
- Lisensi: GPL-2.0-or-later (inti), Apache-2.0 dengan pengecualian LLVM (pustaka klien)
Kekhawatiran Performa dan Perangkat Keras
Ketergantungan sistem berkas ini pada TCP/IP alih-alih RDMA (Remote Direct Memory Access) telah menuai kritik dari para ahli penyimpanan. Drive NVMe modern dapat mencapai bandwidth yang jauh lebih tinggi ketika dipasangkan dengan teknologi RDMA, namun TernFS menggunakan koneksi TCP standar melalui proses Go. Pilihan desain ini mungkin membatasi performa untuk beban kerja yang intensif penyimpanan, berpotensi memerlukan lebih banyak node perangkat keras untuk mencapai throughput yang sama yang dicapai sistem lain dengan mesin yang lebih sedikit.
Komunitas mencatat bahwa sistem berkas paralel yang menggunakan RDMA dan jaringan khusus dapat mencapai 80-90 GB/s per node, secara signifikan lebih tinggi dari yang biasanya dicapai pendekatan berbasis TCP. Untuk organisasi yang merencanakan deployment skala besar, kesenjangan performa ini dapat diterjemahkan menjadi biaya perangkat keras dan operasional yang substansial.
Konteks Perbandingan Performa:
- Sistem file paralel modern: 80-90 GB/s per node dengan RDMA
- TernFS : Performa berbasis TCP (angka spesifik tidak diungkapkan)
- Keterbatasan ukuran file: Tidak cocok untuk file kecil karena overhead metadata
- Replikasi: Kemampuan replikasi antar benua yang mulus
Risiko Implementasi Kustom
TernFS menggunakan algoritma konsensus terdistribusi kustom daripada implementasi yang sudah mapan dan teruji seperti Raft standar. Meskipun para pengembang mengutip pengalaman mereka dengan sistem perdagangan sebagai justifikasi, konsensus terdistribusi terkenal sulit untuk diimplementasikan dengan benar. Tim mengakui mereka belum mengaktifkan failover otomatis dan berencana memvalidasi pendekatan mereka dengan pengujian Jepsen hanya setelah deployment.
Pendekatan ini kontras dengan praktik terbaik industri menggunakan algoritma konsensus yang terbukti telah menjalani pengujian dan validasi ekstensif. Keputusan ini mencerminkan trade-off antara kustomisasi untuk kebutuhan spesifik dan keandalan yang datang dengan solusi matang yang diadopsi secara luas.
Arsitektur Teknis:
- Filesystem utama: Backend CockroachDB
- Penyimpanan data: Berbasis blok dengan grup penempatan
- Model konsistensi: Konsistensi eventual dengan konvergensi deterministik
- Antarmuka klien: Mountpoint FUSE , Object API , Message queues
- Lintas wilayah: Pengaturan konsensus terdistribusi multi-wilayah
Keterbatasan Ukuran File dan Pembatasan Kasus Penggunaan
Sistem secara eksplisit menyatakan tidak boleh digunakan untuk file kecil, dengan ukuran file median 2MB. Keterbatasan ini berasal dari tantangan fundamental dalam mengelola metadata untuk sejumlah besar objek kecil. Seperti yang dijelaskan seorang ahli, menangani kuadriliun file kecil menciptakan masalah manajemen metadata yang kompleks yang memerlukan pilihan desain yang tidak biasa dan dapat merusak arsitektur penyimpanan konvensional.
Pembatasan ini secara signifikan mempersempit aplikabilitas TernFS dibandingkan dengan sistem berkas terdistribusi lain yang menangani file kecil lebih efektif. Organisasi dengan beban kerja campuran yang mengandung banyak file kecil akan memerlukan solusi alternatif atau restrukturisasi signifikan dari organisasi data mereka.
Perbandingan dengan Solusi yang Sudah Mapan
Komunitas mempertanyakan mengapa TernFS dibangun dari awal daripada mengadaptasi solusi yang sudah ada seperti CephFS, yang juga beroperasi pada skala petabyte. Meskipun pengembang TernFS mengutip kebutuhan mereka untuk 600PB dalam satu deployment dan replikasi antar benua yang seamless sebagai diferensiator kunci, beberapa anggota komunitas mencatat bahwa deployment Ceph besar memang ada, meskipun detail spesifik tetap rahasia karena privasi perusahaan.
Pilihan antara membangun solusi kustom versus mengadaptasi yang sudah ada sering kali bermuara pada kemampuan pemeliharaan jangka panjang dan persyaratan fitur spesifik. TernFS memprioritaskan memiliki kontrol penuh atas codebase untuk perbaikan dan modifikasi yang cepat, yang dapat berharga bagi organisasi dengan kebutuhan khusus dan sumber daya rekayasa yang memadai.
Kesimpulan
TernFS merepresentasikan pencapaian rekayasa yang mengesankan dalam mengelola penyimpanan skala masif untuk beban kerja khusus. Namun, diskusi teknis mengungkapkan pertimbangan penting bagi calon adopter. Pilihan desain sistem ini menguntungkan kasus penggunaan spesifik - file besar, data immutable, dan organisasi dengan sumber daya rekayasa substansial untuk memelihara infrastruktur kustom. Meskipun skala 600PB mendemonstrasikan kemampuan, keterbatasan performa, implementasi kustom, dan pembatasan ukuran file berarti TernFS mungkin tidak cocok untuk semua kebutuhan penyimpanan terdistribusi. Organisasi yang mempertimbangkan adopsi harus dengan hati-hati mengevaluasi apakah persyaratan mereka selaras dengan kekuatan sistem dan apakah mereka dapat menerima keterbatasan yang didokumentasikan.
Referensi: TernFS – An eventualy scalable, multiregion distributed filesystem