พื้นที่เก็บข้อมูลประสิทธิภาพสูงสำหรับแอปของคุณ: Storage Foundation API

Thomas Steiner

แพลตฟอร์มเว็บมีเครื่องมือที่นักพัฒนาซอฟต์แวร์ต้องการในการสร้างแอปพลิเคชันที่มีประสิทธิภาพสูงและปรับแต่งมาอย่างดีสำหรับเว็บมากขึ้นเรื่อยๆ ที่สำคัญที่สุดคือ WebAssembly (Wasm) ได้เปิดประตูสู่เว็บแอปพลิเคชันที่รวดเร็วและมีประสิทธิภาพ ในขณะที่เทคโนโลยีอย่าง Emscripten ช่วยให้นักพัฒนาซอฟต์แวร์สามารถนำโค้ดที่ผ่านการทดสอบแล้วมาใช้ซ้ำบนเว็บได้ หากต้องการใช้ประโยชน์จากศักยภาพนี้อย่างแท้จริง นักพัฒนาแอป ต้องมีอำนาจและความยืดหยุ่นเช่นเดียวกันเมื่อพูดถึงพื้นที่เก็บข้อมูล

Storage Foundation API จึงเข้ามามีบทบาทในจุดนี้ Storage Foundation API เป็น API พื้นที่เก็บข้อมูลใหม่ที่รวดเร็วและ ไม่เจาะจง ซึ่งจะเปิดตัว Use Case ใหม่ๆ ที่มีการร้องขอเป็นจำนวนมากสำหรับเว็บ เช่น การติดตั้งใช้งานฐานข้อมูลที่มีประสิทธิภาพและการจัดการไฟล์ชั่วคราวขนาดใหญ่อย่างราบรื่น อินเทอร์เฟซใหม่นี้ช่วยให้นักพัฒนาซอฟต์แวร์สามารถ "นำพื้นที่เก็บข้อมูลของตนเอง" มาใช้บนเว็บได้ ซึ่งจะช่วยลดช่องว่างของฟีเจอร์ระหว่างเว็บกับโค้ดเฉพาะแพลตฟอร์ม

Storage Foundation API ได้รับการออกแบบมาให้คล้ายกับระบบไฟล์พื้นฐานมาก เพื่อให้นักพัฒนาซอฟต์แวร์มีความยืดหยุ่นโดยการจัดเตรียม Primitive ทั่วไป ง่าย และมีประสิทธิภาพ ซึ่งนักพัฒนาซอฟต์แวร์สามารถสร้างคอมโพเนนต์ระดับสูงขึ้นได้ แอปพลิเคชันสามารถใช้ประโยชน์จากเครื่องมือที่ดีที่สุดสำหรับความต้องการของตนเอง โดยค้นหา ความสมดุลที่เหมาะสมระหว่างความสามารถในการใช้งาน ประสิทธิภาพ และความน่าเชื่อถือ

เหตุใดเว็บจึงต้องมี Storage API อื่น

แพลตฟอร์มเว็บมีตัวเลือกพื้นที่เก็บข้อมูลหลายอย่างสำหรับนักพัฒนาซอฟต์แวร์ โดยแต่ละตัวเลือกสร้างขึ้นโดยคำนึงถึง กรณีการใช้งานที่เฉพาะเจาะจง

  • ตัวเลือกบางอย่างเหล่านี้ไม่ทับซ้อนกับข้อเสนอนี้อย่างชัดเจน เนื่องจากอนุญาตให้จัดเก็บข้อมูลได้เพียงเล็กน้อย เช่น คุกกี้ หรือ Web Storage API ซึ่งประกอบด้วยกลไก sessionStorage และ localStorage
  • ตัวเลือกอื่นๆ ถูกเลิกใช้งานไปแล้วด้วยเหตุผลต่างๆ เช่น File and Directory Entries API หรือ WebSQL
  • File System Access API มี API Surface ที่คล้ายกัน แต่มีไว้เพื่อ เชื่อมต่อกับระบบไฟล์ของไคลเอ็นต์และให้สิทธิ์เข้าถึงข้อมูลที่อาจอยู่นอก การเป็นเจ้าของของต้นทางหรือแม้แต่ของเบราว์เซอร์ การมุ่งเน้นที่แตกต่างกันนี้มาพร้อมกับข้อควรพิจารณาด้านความปลอดภัยที่เข้มงวดมากขึ้นและต้นทุนด้านประสิทธิภาพที่สูงขึ้น
  • IndexedDB API สามารถใช้เป็นแบ็กเอนด์สำหรับ Use Case บางอย่างของ Storage Foundation API ได้ เช่น Emscripten มี IDBFS ซึ่งเป็นระบบไฟล์แบบถาวรที่อิงตาม IndexedDB อย่างไรก็ตาม เนื่องจาก IndexedDB เป็นที่เก็บคีย์-ค่าโดยพื้นฐาน จึงมีข้อจำกัดด้านประสิทธิภาพที่สำคัญ นอกจากนี้ การเข้าถึงส่วนย่อยของไฟล์โดยตรงยังทำได้ยากและช้ากว่าใน IndexedDB
  • สุดท้ายนี้ CacheStorage interface ได้รับการรองรับอย่างกว้างขวางและได้รับการปรับแต่งให้จัดเก็บข้อมูลขนาดใหญ่ เช่น ทรัพยากรของเว็บแอปพลิเคชัน แต่ค่าจะเปลี่ยนแปลงไม่ได้

Storage Foundation API เป็นความพยายามในการปิดช่องว่างทั้งหมดของตัวเลือกพื้นที่เก็บข้อมูลก่อนหน้าโดย อนุญาตให้จัดเก็บไฟล์ขนาดใหญ่ที่เปลี่ยนแปลงได้ซึ่งกำหนดไว้ภายในต้นทางของ แอปพลิเคชันได้อย่างมีประสิทธิภาพ

Use Case ที่แนะนำสำหรับ Storage Foundation API

ตัวอย่างเว็บไซต์ที่อาจใช้ API นี้ ได้แก่

  • แอปเพิ่มประสิทธิภาพหรือแอปครีเอทีฟโฆษณาที่ทำงานกับข้อมูลวิดีโอ เสียง หรือรูปภาพจำนวนมาก แอปดังกล่าว สามารถส่งต่อส่วนต่างๆ ไปยังดิสก์แทนที่จะเก็บไว้ในหน่วยความจำ
  • แอปที่ต้องอาศัยระบบไฟล์แบบถาวรที่เข้าถึงได้จาก Wasm และต้องการประสิทธิภาพมากกว่าที่ IDBFS รับประกันได้

Storage Foundation API คืออะไร

API ประกอบด้วย 2 ส่วนหลักๆ ดังนี้

  • การเรียกใช้ระบบไฟล์ ซึ่งมีฟังก์ชันพื้นฐานในการโต้ตอบกับไฟล์และเส้นทางของไฟล์
  • แฮนเดิลไฟล์ ซึ่งให้สิทธิ์อ่านและเขียนไปยังไฟล์ที่มีอยู่

การเรียกใช้ระบบไฟล์

Storage Foundation API มีออบเจ็กต์ใหม่ storageFoundation ซึ่งอยู่ในออบเจ็กต์ window และมีฟังก์ชันหลายอย่างดังนี้

  • storageFoundation.open(name): เปิดไฟล์ที่มีชื่อที่ระบุหากมีอยู่ และหากไม่มี จะสร้างไฟล์ใหม่ แสดงผล Promise ที่จะแก้ไขด้วยไฟล์ที่เปิด
  • storageFoundation.delete(name): นำไฟล์ที่มีชื่อที่ระบุออก แสดงผล Promise ที่ จะทำงานเมื่อลบไฟล์แล้ว
  • storageFoundation.rename(oldName, newName): เปลี่ยนชื่อไฟล์จากชื่อเก่าเป็นชื่อใหม่ โดยอัตโนมัติ แสดงผล Promise ที่จะได้รับการแก้ไขเมื่อเปลี่ยนชื่อไฟล์
  • storageFoundation.getAll(): แสดงผล Promise ที่แก้ไขด้วยอาร์เรย์ของชื่อไฟล์ทั้งหมดที่มีอยู่
  • storageFoundation.requestCapacity(requestedCapacity): ขอความจุใหม่ (เป็นไบต์) สำหรับบริบทการดำเนินการปัจจุบัน แสดงผล Promise ที่แก้ไขด้วยความจุที่เหลืออยู่
  • storageFoundation.releaseCapacity(toBeReleasedCapacity): ปล่อยไบต์ตามจำนวนที่ระบุ จากบริบทการดำเนินการปัจจุบัน และแสดงผล Promise ที่จะเปลี่ยนเป็นความจุที่เหลือ
  • storageFoundation.getRemainingCapacity(): แสดงผล Promise ที่จะได้รับการแก้ไขด้วยความจุ ที่พร้อมใช้งานสำหรับบริบทการดำเนินการปัจจุบัน

แฮนเดิลไฟล์

การทำงานกับไฟล์จะเกิดขึ้นผ่านฟังก์ชันต่อไปนี้

  • NativeIOFile.close(): ปิดไฟล์และแสดงผล Promise ที่จะทำงานเมื่อการดำเนินการ เสร็จสมบูรณ์
  • NativeIOFile.flush(): ซิงค์ (นั่นคือล้าง) สถานะในหน่วยความจำของไฟล์กับอุปกรณ์จัดเก็บข้อมูล และส่งคืน Promise ที่จะทำงานเมื่อการดำเนินการเสร็จสมบูรณ์
  • NativeIOFile.getLength(): แสดงผล Promise ที่แก้ไขด้วยความยาวของไฟล์ในหน่วยไบต์
  • NativeIOFile.setLength(length): กำหนดความยาวของไฟล์เป็นไบต์ และแสดงผล Promise ที่ จะได้รับการแก้ไขเมื่อการดำเนินการเสร็จสมบูรณ์ หากความยาวใหม่น้อยกว่าความยาวปัจจุบัน ระบบจะนำไบต์ ออกโดยเริ่มจากท้ายไฟล์ ไม่เช่นนั้น ระบบจะขยายไฟล์ด้วยไบต์ที่มีค่าเป็น 0

  • NativeIOFile.read(buffer, offset): อ่านเนื้อหาของไฟล์ที่ออฟเซ็ตที่ระบุผ่านบัฟเฟอร์ซึ่งเป็นผลลัพธ์ของการโอนบัฟเฟอร์ที่ระบุ จากนั้นจะปล่อยให้บัฟเฟอร์ดังกล่าวไม่ได้เชื่อมต่อ แสดงผล NativeIOReadResult พร้อมบัฟเฟอร์ที่โอนและจำนวนไบต์ที่อ่านสำเร็จ

    NativeIOReadResult คือออบเจ็กต์ที่มี 2 รายการ ได้แก่

    • buffer: ArrayBufferView ซึ่งเป็นผลลัพธ์ของการโอนบัฟเฟอร์ที่ส่งไปยัง read() มีประเภทและความยาวเหมือนกับบัฟเฟอร์ต้นทาง
    • readBytes: จำนวนไบต์ที่อ่านลงใน buffer ได้สำเร็จ ซึ่งอาจน้อยกว่าขนาดบัฟเฟอร์หากเกิดข้อผิดพลาดหรือหากช่วงการอ่านครอบคลุมเกินกว่าจุดสิ้นสุดของไฟล์ โดยจะตั้งค่าเป็น 0 หากช่วงการอ่านอยู่เลยจุดสิ้นสุดของไฟล์

  • NativeIOFile.write(buffer, offset): เขียนเนื้อหาของบัฟเฟอร์ที่ระบุลงในไฟล์ที่ออฟเซ็ตที่ระบุ ระบบจะโอนบัฟเฟอร์ก่อนที่จะเขียนข้อมูลใดๆ จึงทำให้บัฟเฟอร์ไม่ได้เชื่อมต่อ แสดงผล NativeIOWriteResult พร้อมบัฟเฟอร์ที่โอนและจำนวนไบต์ที่เขียนสำเร็จ ระบบจะขยายไฟล์หากช่วงการเขียนยาวเกินความยาวของไฟล์

    NativeIOWriteResult คือออบเจ็กต์ที่มี 2 รายการ ได้แก่

    • buffer: ArrayBufferView ซึ่งเป็นผลลัพธ์ของการโอนบัฟเฟอร์ที่ส่งไปยัง write() โดยมีประเภทและความยาวเหมือนกับบัฟเฟอร์ต้นทาง
    • writtenBytes: จำนวนไบต์ที่เขียนลงใน buffer ได้สำเร็จ ซึ่งอาจมีขนาด น้อยกว่าขนาดบัฟเฟอร์หากเกิดข้อผิดพลาด

ตัวอย่างที่สมบูรณ์

เพื่อให้แนวคิดที่กล่าวถึงข้างต้นชัดเจนยิ่งขึ้น ต่อไปนี้คือตัวอย่างที่สมบูรณ์ 2 ตัวอย่างที่จะอธิบายขั้นตอนต่างๆ ในวงจรของไฟล์ Storage Foundation

การเปิด การเขียน การอ่าน การปิด

// Open a file (creating it if needed).
const file = await storageFoundation.open('test_file');
try {
  // Request 100 bytes of capacity for this context.
  await storageFoundation.requestCapacity(100);

  const writeBuffer = new Uint8Array([64, 65, 66]);
  // Write the buffer at offset 0. After this operation, `result.buffer`
  // contains the transferred buffer and `result.writtenBytes` is 3,
  // the number of bytes written. `writeBuffer` is left detached.
  let result = await file.write(writeBuffer, 0);

  const readBuffer = new Uint8Array(3);
  // Read at offset 1. `result.buffer` contains the transferred buffer,
  // `result.readBytes` is 2, the number of bytes read. `readBuffer` is left
  // detached.
  result = await file.read(readBuffer, 1);
  // `Uint8Array(3) [65, 66, 0]`
  console.log(result.buffer);
} finally {
  file.close();
}

การเปิด แสดง และลบ

// Open three different files (creating them if needed).
await storageFoundation.open('sunrise');
await storageFoundation.open('noon');
await storageFoundation.open('sunset');
// List all existing files.
// `["sunset", "sunrise", "noon"]`
await storageFoundation.getAll();
// Delete one of the three files.
await storageFoundation.delete('noon');
// List all remaining existing files.
// `["sunrise", "noon"]`
await storageFoundation.getAll();

ความปลอดภัยและสิทธิ์

ทีม Chromium ออกแบบและใช้ Storage Foundation API โดยใช้หลักการพื้นฐาน ที่ระบุไว้ในการควบคุมการเข้าถึงฟีเจอร์ที่มีประสิทธิภาพของแพลตฟอร์มเว็บ ซึ่งรวมถึงการควบคุมของผู้ใช้ ความโปร่งใส และการยศาสตร์

การเข้าถึง Storage Foundation API จะเชื่อมโยงกับต้นทาง ซึ่งหมายความว่าต้นทางจะเข้าถึงได้เฉพาะข้อมูลที่สร้างขึ้นเองเท่านั้น โดยเป็นไปตามรูปแบบเดียวกับ API พื้นที่เก็บข้อมูลที่ทันสมัยอื่นๆ บนเว็บ นอกจากนี้ ยังจำกัดเฉพาะ บริบทที่ปลอดภัย

การควบคุมของผู้ใช้

ระบบจะใช้โควต้าพื้นที่เก็บข้อมูลเพื่อกระจายสิทธิ์เข้าถึงพื้นที่ดิสก์และป้องกันการละเมิด คุณต้องขอหน่วยความจำที่ต้องการ ใช้ก่อน เช่นเดียวกับ Storage API อื่นๆ ผู้ใช้สามารถล้างพื้นที่ที่ Storage Foundation API ใช้ผ่านเบราว์เซอร์ได้

ลิงก์ที่มีประโยชน์

คำขอบคุณ

Storage Foundation API ได้รับการระบุและติดตั้งใช้งานโดย Emanuel Krivoy และ Richard Stotz บทความนี้ได้รับการตรวจสอบโดย Pete LePage และ Joe Medley

รูปภาพหลักจาก Markus Spiske ใน Unsplash