รูปแบบไฟล์ข้อมูลใหม่ที่เรียกว่า F3 (Future-proof File Format) ได้เกิดขึ้นจาก Carnegie Mellon University และ Tsinghua University โดยสัญญาว่าจะแก้ไขปัญหาความเข้ากันได้ในการจัดเก็บข้อมูล อย่างไรก็ตาม แนวทางที่เป็นเอกลักษณ์ของรูปแบบนี้ในการฝัง WebAssembly decoders โดยตรงเข้าไปในไฟล์ได้จุดประกายการถกเถียงอย่างเข้มข้นในหมู่นักพัฒนาเกี่ยวกับว่าประโยชน์ที่ได้รับนั้นคุ้มค่ากับต้นทุนหรือไม่
ข้อถกเถียงเรื่อง WebAssembly
การถกเถียงที่ร้อนแรงที่สุดมุ่งเน้นไปที่การตัดสินใจของ F3 ในการฝัง WebAssembly (WASM) decoders ไว้ภายในแต่ละไฟล์ข้อมูล นักวิจารณ์ชี้ให้เห็นว่าแนวทางนี้ทำให้เกิดการลดประสิทธิภาพทันที 10-30% เมื่อเปรียบเทียบกับการใช้งานแบบ native ความกังวลไม่ได้จำกัดอยู่แค่ความเร็วเท่านั้น นักพัฒนายังกังวลเกี่ยวกับการสละโอกาสในการปรับปรุงประสิทธิภาพในอนาคตและฟังก์ชันการถอดรหัสขั้นสูง
อย่างไรก็ตาม ผู้สนับสนุนโต้แย้งว่าสิ่งนี้มองข้ามภาพรวมใหญ่ไป WASM ที่ฝังไว้ทำหน้าที่เป็นกลไกสำรองเมื่อ native decoders ไม่พร้อมใช้งาน ดังที่ผู้สร้างรูปแบบคนหนึ่งอธิบายไว้ว่า การลดประสิทธิภาพนั้นคุ้มค่าเมื่อเปรียบเทียบกับการไม่สามารถอ่านไฟล์ได้เลย ระบบจะเลือกใช้ native decoders เมื่อมีให้ใช้งาน และจะใช้ WASM เป็นทางเลือกสุดท้ายเมื่อจำเป็นเท่านั้น
WebAssembly (WASM): รูปแบบคำสั่งแบบไบนารีที่ทำงานในสภาพแวดล้อมที่ปลอดภัย ช่วยให้โค้ดสามารถทำงานได้อย่างปลอดภัยบนแพลตฟอร์มต่างๆ
ผลกระทบต่อประสิทธิภาพของ F3
- การถอดรหัส WebAssembly: ประสิทธิภาพลดลง 10-30% เมื่อเทียบกับการใช้งานแบบ native
- ขนาดตัวถอดรหัสแบบฝังตัว: การใช้พื้นที่จัดเก็บข้อมูลเพิ่มขึ้นเพียงเล็กน้อย (กิโลไบต์)
- กรณีการใช้งานเป้าหมาย: ไฟล์ที่มีขนาดข้อมูลระดับเทราไบต์
ความกังวลเรื่องความปลอดภัยและ Malicious Payload
แนวคิดของการฝังโค้ดที่สามารถทำงานได้ไว้ในไฟล์ข้อมูลได้ทำให้นักพัฒนาที่ใส่ใจเรื่องความปลอดภัยเกิดความระแวดระวัง ประสบการณ์หลายปีกับรูปแบบไฟล์ที่มี scripting ในตัวได้สอนชุมชนให้ระมัดระวังกับแนวทางดังกล่าว ศักยภาพของ malicious payloads ที่ซ่อนอยู่ภายในโค้ด WebAssembly ถือเป็นความกังวลที่สำคัญ
ผู้ออกแบบ F3 ยอมรับความท้าทายด้านความปลอดภัยเหล่านี้และเสนอแนวทางแก้ไขรวมถึง sandboxed linear memory spaces และ allowlists ที่เป็นไปได้สำหรับ WASM modules ที่ได้รับการตรวจสอบแล้ว พวกเขาแนะนำให้สร้าง central repository ที่ผู้สร้าง decoder สามารถลงทะเบียนและตรวจสอบ modules ของตน ทำให้ป้องกันการแก้ไขได้
ภูมิทัศน์รูปแบบที่กระจัดกระจาย
บางทีการเปิดเผยที่น่าประหลาดใจที่สุดจากการถกเถียงในชุมชนคือการมีอยู่ของโครงการรูปแบบไฟล์สากลที่แข่งขันกันหลายโครงการ สิ่งที่เริ่มต้นเป็นแผนการจัดตั้งคอนซอร์เซียมระหว่างองค์กรใหญ่ๆ รวมถึง CMU, Meta และอื่นๆ ได้ล่มสลายเนื่องจากปัญหาทางกฎหมายเกี่ยวกับข้อตกลงการไม่เปิดเผยข้อมูล
รูปแบบที่ต้องใช้โปรแกรมในการถอดรหัสนั้นบ้าบอ เหมือนกับการแนบ 7zip เข้าไปกับไฟล์ zip ทุกไฟล์
การแตกแยกนี้นำไปสู่การริเริ่มรูปแบบที่แยกจากกันอย่างน้อยห้าโครงการ: Nimble ของ Meta, FastLanes ของ CWI, Vortex ของ SpiralDB, F3 ของ CMU และ Tsinghua และ AnyBlox ของเยอรมนี แต่ละโครงการใช้แนวทางที่แตกต่างกันในการแก้ไขปัญหาที่คล้ายคลึงกัน สร้างภูมิทัศน์ที่กระจัดกระจายซึ่งขัดแย้งกับความสามารถในการทำงานร่วมกันที่รูปแบบเหล่านี้มุ่งหวังจะบรรลุ
โครงการรูปแบบไฟล์ที่แข่งขัน
- Nimble ของ Meta: https://github.com/facebookincubator/nimble
- FastLanes ของ CWI: https://github.com/cwida/FastLanes
- Vortex ของ SpiralDB: https://vortex.dev
- F3 ของ CMU + Tsinghua: https://github.com/future-file-format/f3
- AnyBlox (เยอรมนี): https://github.com/AnyBlox
คำถามเกี่ยวกับการใช้งานจริง
นอกเหนือจากการถกเถียงเชิงปรัชญาแล้ว ความกังวลเชิงปฏิบัติเกิดขึ้นเกี่ยวกับประโยชน์ใช้สอยของ F3 ในโลกแห่งความเป็นจริง รูปแบบนี้มุ่งเป้าไปที่สถานการณ์ที่ขนาดไฟล์มีขนาดหลายเทราไบต์ ทำให้ overhead ของ embedded decoders ที่มีขนาดเพียงกิโลไบต์นั้นไม่มีนัยสำคัญ อย่างไรก็ตาม ยังคงมีคำถามเกี่ยวกับความสามารถในการเข้ารหัส ความจำเป็นของ WASM runtimes บนแพลตฟอร์มที่ไม่ธรรมดา และว่าการใช้งาน decoder อาจจะง่ายกว่าการสนับสนุน WASM runtime แบบเต็มรูปแบบหรือไม่
การพึ่งพา Apache Arrow arrays ของรูปแบบนี้สำหรับการส่งคืนข้อมูลยังจำกัดการใช้งานในฐานะรูปแบบไฟล์ทั่วไปอย่างแท้จริง โดยแนะนำว่าเหมาะสมกับ analytical workloads เฉพาะมากกว่าการจัดเก็บข้อมูลทั่วไป
ข้อมูลจำเพาะทางเทคนิคของ F3
- หลักการหลัก: การทำงานร่วมกันได้, ความสามารถในการขยาย, ประสิทธิภาพ
- การจัดระเบียบข้อมูล: ไฟล์ที่อธิบายตัวเองพร้อมข้อมูลเมตาที่ฝังไว้
- รูปแบบตัวถอดรหัส: ไบนารี WebAssembly เพื่อความเข้ากันได้ข้ามแพลตฟอร์ม
- กลไกสำรอง: ให้ความสำคัญกับตัวถอดรหัสแบบ native ใช้ WASM เป็นตัวสำรอง
- รูปแบบการส่งคืนข้อมูล: อาร์เรย์ Apache Arrow
บทสรุป
F3 แสดงถึงความพยายามอย่างทะเยอทะยานในการทำให้การจัดเก็บข้อมูลพร้อมสำหรับอนาคต แต่แนวทางที่เน้น WebAssembly ทำให้ชุมชนแบ่งแยกความคิดเห็น แม้ว่ารูปแบบนี้จะแก้ไขปัญหาความเข้ากันได้ที่แท้จริงในการวิเคราะห์ข้อมูล แต่การลดประสิทธิภาพ ความกังวลด้านความปลอดภัย และการแพร่หลายของมาตรฐานที่แข่งขันกันทำให้เกิดคำถามเกี่ยวกับการใช้งานจริง โครงการนี้ยังคงเป็น prototype ทางวิชาการ ทำให้ชุมชนมีเวลาประเมินว่าแนวทางที่เป็นนวัตกรรมนี้จะพิสูจน์ให้เห็นคุณค่าหรือไม่ หรือว่าแนวทางแก้ไขที่เรียบง่ายกว่าอาจจะตอบสนองความต้องการของระบบนิเวศการจัดเก็บข้อมูลได้ดีกว่า
อ้างอิง: F3: The Open-Source Data File Format for the Future