XTX Markets telah membuka sumber TernFS , sebuah sistem fail teragih yang menguruskan lebih 600 petabait data untuk operasi perdagangan frekuensi tinggi. Walaupun pencapaian ini mewakili skala yang ketara, komuniti teknikal telah menimbulkan persoalan penting mengenai pilihan reka bentuk dan batasan sistem yang perlu dipertimbangkan oleh pengguna berpotensi.
Spesifikasi Utama TernFS:
- Skala: 600+ petabait dalam satu pelaksanaan
- Saiz fail median: 2MB (tidak dioptimumkan untuk fail kecil)
- Backend: CockroachDB untuk pengurusan metadata
- Rangkaian: TCP/IP (tiada sokongan RDMA)
- Konsensus: Algoritma seperti Raft yang disesuaikan
- Lesen: GPL-2.0-or-later (teras), Apache-2.0 dengan pengecualian LLVM (perpustakaan klien)
Kebimbangan Prestasi dan Perkakasan
Pergantungan sistem fail kepada TCP/IP berbanding RDMA (Remote Direct Memory Access) telah menarik kritikan daripada pakar storan. Pemacu NVMe moden boleh mencapai lebar jalur yang lebih tinggi apabila dipasangkan dengan teknologi RDMA , tetapi TernFS menggunakan sambungan TCP standard melalui proses Go . Pilihan reka bentuk ini mungkin mengehadkan prestasi untuk beban kerja intensif storan, berpotensi memerlukan lebih banyak nod perkakasan untuk mencapai daya pemprosesan yang sama yang dicapai oleh sistem lain dengan mesin yang lebih sedikit.
Komuniti menyatakan bahawa sistem fail selari yang menggunakan RDMA dan rangkaian khusus boleh mencapai 80-90 GB/s setiap nod, jauh lebih tinggi daripada apa yang biasanya dicapai oleh pendekatan berasaskan TCP . Bagi organisasi yang merancang penggunaan berskala besar, jurang prestasi ini boleh diterjemahkan kepada kos perkakasan dan operasi yang besar.
Konteks Perbandingan Prestasi:
- Sistem fail selari moden: 80-90 GB/s setiap nod dengan RDMA
- TernFS : Prestasi berasaskan TCP (nombor khusus tidak didedahkan)
- Had saiz fail: Tidak sesuai untuk fail kecil disebabkan overhed metadata
- Replikasi: Keupayaan replikasi antara benua yang lancar
Risiko Pelaksanaan Tersuai
TernFS menggunakan algoritma konsensus teragih tersuai berbanding pelaksanaan yang telah ditetapkan dan teruji seperti Raft standard. Walaupun pembangun menyebut pengalaman mereka dengan sistem perdagangan sebagai justifikasi, konsensus teragih terkenal sukar untuk dilaksanakan dengan betul. Pasukan mengakui mereka belum membolehkan failover automatik lagi dan merancang untuk mengesahkan pendekatan mereka dengan ujian Jepsen hanya selepas penggunaan.
Pendekatan ini berbeza dengan amalan terbaik industri menggunakan algoritma konsensus yang terbukti telah menjalani ujian dan pengesahan yang meluas. Keputusan ini mencerminkan pertukaran antara penyesuaian untuk keperluan khusus dan kebolehpercayaan yang datang dengan penyelesaian matang yang diterima pakai secara meluas.
Seni Bina Teknikal:
- Sistem fail induk: Backend CockroachDB
- Penyimpanan data: Berasaskan blok dengan kumpulan penempatan
- Model konsistensi: Konsistensi akhirnya dengan penumpuan deterministik
- Antara muka klien: Titik lekapan FUSE , API Objek, Barisan gilir mesej
- Merentas rantau: Persediaan konsensus teragih berbilang rantau
Batasan Saiz Fail dan Sekatan Kes Penggunaan
Sistem ini secara jelas menyatakan ia tidak sepatutnya digunakan untuk fail kecil, dengan saiz fail median 2MB . Batasan ini berpunca daripada cabaran asas dalam menguruskan metadata untuk bilangan besar objek kecil. Seperti yang dijelaskan oleh seorang pakar, mengendalikan kuadrilion fail kecil mewujudkan masalah pengurusan metadata yang kompleks yang memerlukan pilihan reka bentuk luar biasa dan boleh memecahkan seni bina storan konvensional.
Sekatan ini dengan ketara menyempitkan kebolehgunaan TernFS berbanding sistem fail teragih lain yang mengendalikan fail kecil dengan lebih berkesan. Organisasi dengan beban kerja campuran yang mengandungi banyak fail kecil memerlukan penyelesaian alternatif atau penstrukturan semula yang ketara dalam organisasi data mereka.
Perbandingan dengan Penyelesaian Yang Ditetapkan
Komuniti mempersoalkan mengapa TernFS dibina dari awal berbanding menyesuaikan penyelesaian sedia ada seperti CephFS , yang juga beroperasi pada skala petabait. Walaupun pembangun TernFS menyebut keperluan mereka untuk 600PB dalam satu penggunaan dan replikasi antara benua yang lancar sebagai pembeza utama, beberapa ahli komuniti menyatakan bahawa penggunaan Ceph yang besar wujud, walaupun butiran khusus kekal sulit kerana privasi perusahaan.
Pilihan antara membina penyelesaian tersuai berbanding menyesuaikan yang sedia ada sering bergantung kepada keupayaan penyelenggaraan jangka panjang dan keperluan ciri khusus. TernFS mengutamakan kawalan penuh ke atas pangkalan kod untuk pembaikan dan pengubahsuaian pantas, yang boleh bernilai untuk organisasi dengan keperluan khusus dan sumber kejuruteraan yang mencukupi.
Kesimpulan
TernFS mewakili pencapaian kejuruteraan yang mengagumkan dalam menguruskan storan berskala besar untuk beban kerja khusus. Walau bagaimanapun, perbincangan teknikal mendedahkan pertimbangan penting untuk bakal pengguna. Pilihan reka bentuk sistem memihak kepada kes penggunaan khusus - fail besar, data tidak berubah, dan organisasi dengan sumber kejuruteraan yang besar untuk menyelenggara infrastruktur tersuai. Walaupun skala 600PB menunjukkan keupayaan, batasan prestasi, pelaksanaan tersuai, dan sekatan saiz fail bermakna TernFS mungkin tidak sesuai untuk semua keperluan storan teragih. Organisasi yang mempertimbangkan penggunaan perlu menilai dengan teliti sama ada keperluan mereka sejajar dengan kekuatan sistem dan sama ada mereka boleh menerima batasan yang didokumenkan.
Rujukan: TernFS – An eventualy scalable, multiregion distributed filesystem