DuckDB v2.0: ปลดล็อกความเร็วด้วย Asynchronous I/O สำหรับไฟล์ Parquet และ CSV 🚀

สำหรับผู้ใช้งาน DuckDB ที่ต้องทำงานกับข้อมูลขนาดใหญ่ที่เก็บอยู่บนคลาวด์ การรอคอยการอ่านข้อมูลอาจเป็นคอขวดที่ทำให้ประสิทธิภาพโดยรวมลดลง แต่ข่าวดีก็คือ DuckDB เวอร์ชัน 2.0 ที่มีกำหนดเปิดตัวในช่วงฤดูใบไม้ร่วงปี 2026 นี้ จะมาพร้อมกับการรองรับ Asynchronous I/O สำหรับการอ่านไฟล์ Parquet และ CSV ซึ่งจะช่วยเร่งความเร็วให้กับคิวรีได้อย่างมหาศาล โดยเฉพาะอย่างยิ่งในสถานการณ์ที่การอ่านข้อมูลแบบ Synchronous ไม่สามารถใช้ประโยชน์จากแบนด์วิดท์ที่มีอยู่ได้อย่างเต็มที่ เช่น การตั้งค่าแบบ EC2/S3

ทำไม Asynchronous I/O ถึงสำคัญกับ DuckDB? 🤔

ในอดีต DuckDB ถูกออกแบบมาเพื่อใช้งานบนเครื่องโลคัลเป็นหลัก โดยมีจุดประสงค์หลักคือการเป็นเอนจิ้นฐานข้อมูลที่รวดเร็วสำหรับการสอบถามข้อมูลโดยตรงจาก SSD ของเครื่องผู้ใช้งาน ด้วยการใช้เทคนิคอย่างการตัดข้อมูลที่ไม่จำเป็นออก (pruning) และการอ่านข้อมูลแบบ Synchronous ที่มี Latency ต่ำและแบนด์วิดท์สูง ทำให้คอขวดมักจะอยู่ที่ส่วนอื่น ๆ ของคิวรี เช่น Subqueries, Joins หรือ Aggregations

อย่างไรก็ตาม เมื่อ DuckDB เริ่มเข้ามามีบทบาทในการสอบถามชุดข้อมูลขนาดใหญ่ที่จัดเก็บแบบระยะไกล (Remote Storage) เช่น Data Lakes หรือการใช้งาน DuckDB ในรูปแบบ Server ด้วย Quack protocol สถานการณ์ก็เปลี่ยนไป การที่ไฟล์ข้อมูลไม่ได้อยู่บน SSD ของเครื่องอีกต่อไป ทำให้การถ่ายโอนไฟล์จาก Remote Storage มายังเครื่องที่ประมวลผลมีความสำคัญมากขึ้น ในกรณีเช่นการใช้ S3 เป็นที่เก็บข้อมูลและ EC2 เป็นเครื่องประมวลผล หากไม่สามารถส่งคำขอพร้อมกันจำนวนมากพอที่จะใช้แบนด์วิดท์เครือข่ายที่มีอยู่ได้อย่างเต็มที่ ประสิทธิภาพก็จะลดลงอย่างมาก เนื่องจากเธรด (Thread) จะต้องเสียเวลาส่วนใหญ่ไปกับการรอข้อมูล

Asynchronous I/O ทำงานอย่างไรใน DuckDB? 🛠️

แนวคิดหลักของ Asynchronous I/O คือการอนุญาตให้เริ่มการทำงาน I/O ได้โดยไม่ทำให้เธรดที่ร้องขอหยุดทำงาน (Block) แทนที่จะรอให้การอ่านข้อมูลเสร็จสมบูรณ์ เธรดสามารถกลับไปทำงานอื่น ๆ ได้ ใน DuckDB ได้มีการนำแนวคิดนี้มาปรับใช้โดยการแบ่งกลุ่มเธรดออกเป็น 2 ประเภท:

  • REGULAR Threads: กลุ่มเธรดหลักที่ทำหน้าที่ประมวลผลจริง เช่น การถอดรหัสข้อมูล, การ Join, การทำ Aggregation เธรดเหล่านี้สามารถทำงาน I/O ได้เมื่อไม่ได้ยุ่งกับงานหลัก
  • ASYNC Threads: กลุ่มเธรดที่ออกแบบมาเพื่องาน Asynchronous โดยเฉพาะ ซึ่งส่วนใหญ่เป็นงาน I/O ที่อาจต้องรอเป็นเวลานาน (Blocking I/O) เช่น การรอการตอบสนองจาก HTTP

เหตุผลที่ต้องมีสองกลุ่มเธรดนี้ คือเธรด ASYNC มักจะใช้เวลาส่วนใหญ่ไปกับการรอ ทำให้มี CPU Utilization ต่ำ ดังนั้น DuckDB จึงสร้าง ASYNC workers จำนวนมากกว่าจำนวน System threads ทั่วไป (ค่าเริ่มต้นคือ 4 เท่าของ System threads และสูงสุดไม่เกิน 256 เธรด) เพื่อให้แน่ใจว่า ASYNC threads เหล่านี้จะทำงานอยู่ตลอดเวลา

Read-Ahead Strategy: การอ่านข้อมูลล่วงหน้า

เพื่อรักษา ASYNC threads ให้ทำงานอยู่เสมอ DuckDB ใช้กลยุทธ์ Read-ahead คือการกำหนดตารางการทำงาน (Fetch Tasks) ล่วงหน้า แทนที่จะรอให้เธรด REGULAR ต้องการข้อมูลก่อน จึงค่อยเริ่มอ่าน ขณะที่เธรด REGULAR กำลังถอดรหัสข้อมูลชุดปัจจุบัน เธรด ASYNC ก็จะเริ่มดึงข้อมูลสำหรับงานถัดไปเข้ามาเก็บไว้ เพื่อซ่อน Latency ของ Remote Storage

การจัดการหน่วยความจำ (Memory Governance)

การอ่านข้อมูลล่วงหน้าจำนวนมากอาจทำให้เกิดปัญหาหน่วยความจำไม่เพียงพอ (Out-of-memory) หากการถอดรหัสข้อมูลช้ากว่าความเร็วเครือข่าย DuckDB จึงได้นำ Asynchronous Memory Governance มาใช้ เพื่อควบคุมปริมาณข้อมูลที่ถูกอ่านเข้ามาเก็บไว้ล่วงหน้า

ประสิทธิภาพที่เห็นได้ชัด: ผลการทดสอบ 📊

จากผลการทดสอบ TPC-H Query 6 ที่ SF100 โดยใช้ข้อมูล Parquet ขนาด 22 GB บน S3 และประมวลผลบนเครื่อง EC2 r7i.16xlarge พบว่า:

  • Parquet: DuckDB v2.0.0-dev (Asynchronous I/O) ทำงานได้เร็วกว่า DuckDB v1.5.5 (Synchronous I/O) เกือบ 3 เท่า โดยลดเวลาจาก 8.230 วินาที เหลือ 2.844 วินาที
  • CSV: การทดสอบกับไฟล์ CSV ก็ให้ผลลัพธ์ที่น่าประทับใจเช่นกัน
  • Network Throughput: DuckDB v2.0.0-dev สามารถใช้แบนด์วิดท์เครือข่ายได้อย่างมีประสิทธิภาพมากขึ้นอย่างเห็นได้ชัด เมื่อเทียบกับ v1.5.5 ที่ใช้งานแบนด์วิดท์ได้เพียงประมาณ 5 Gbit/s

การปรับแต่งค่า Asynchronous I/O เพิ่มเติม เช่น การตั้งค่า async_threads หรือการจำกัด read-ahead ทำให้ได้ประสิทธิภาพที่ดียิ่งขึ้นไปอีก โดยเวอร์ชันที่ปรับแต่งสามารถใช้แบนด์วิดท์ 25 Gbit/s ได้เกือบเต็มที่ ทำให้เวลาประมวลผลลดลงเหลือเพียง 2.227 วินาที หรือเร็วขึ้นประมาณ 3.7 เท่าเมื่อเทียบกับ v1.5.5

สรุป 📌

การรองรับ Asynchronous I/O ใน DuckDB v2.0 ถือเป็นก้าวสำคัญที่จะช่วยเพิ่มประสิทธิภาพอย่างมหาศาล โดยเฉพาะอย่างยิ่งสำหรับผู้ที่ใช้งาน DuckDB กับข้อมูลขนาดใหญ่ที่เก็บอยู่บน Remote Storage การปรับปรุงนี้จะช่วยลดเวลาที่เธรดต้องรอ I/O ทำให้สามารถใช้ประโยชน์จากทรัพยากรที่มีอยู่ได้อย่างเต็มที่ และเร่งความเร็วในการประมวลผลคิวรีให้ดียิ่งขึ้น

สำหรับผู้ที่ต้องการทดลองใช้งาน สามารถลองใช้ DuckDB เวอร์ชัน v2.0.0-dev preview ได้แล้ววันนี้ และเตรียมพบกับการเปลี่ยนแปลงครั้งใหญ่นี้ได้ใน DuckDB v2.0 ช่วงฤดูใบไม้ร่วงปี 2026!

#DuckDB #AsynchronousIO #Database #BigData #Parquet #CSV

ขอบคุณ แหล่งข้อมูล
https://duckdb.org/2026/07/31/asynchronous-io

DuckDB v2.0: ปลดล็อกความเร็วด้วย Asynchronous I/O สำหรับไฟล์ Parquet และ CSV 🚀สำหรับผู้ใช้งาน DuckDB ที่ต้องทำงานกับข้อมูลขนาดใหญ่ที่เก็บอยู่บนคลาวด์ การรอคอยการอ่านข้อมูลอาจเป็นคอขวดที่ทำให้ประสิทธิภาพโดยรวมลดลง แต่ข่าวดีก็คือ DuckDB เวอร์ชัน 2.0 ที่มีกำหนดเปิดตัวในช่วงฤดูใบไม้ร่วงปี 2026 นี้ จะมาพร้อมกับการรองรับ Asynchronous I/O สำหรับการอ่านไฟล์ Parquet และ CSV ซึ่งจะช่วยเร่งความเร็วให้กับคิวรีได้อย่างมหาศาล โดยเฉพาะอย่างยิ่งในสถานการณ์ที่การอ่านข้อมูลแบบ Synchronous ไม่สามารถใช้ประโยชน์จากแบนด์วิดท์ที่มีอยู่ได้อย่างเต็มที่ เช่น การตั้งค่าแบบ EC2/S3ทำไม Asynchronous I/O ถึงสำคัญกับ DuckDB? 🤔ในอดีต DuckDB ถูกออกแบบมาเพื่อใช้งานบนเครื่องโลคัลเป็นหลัก โดยมีจุดประสงค์หลักคือการเป็นเอนจิ้นฐานข้อมูลที่รวดเร็วสำหรับการสอบถามข้อมูลโดยตรงจาก SSD ของเครื่องผู้ใช้งาน ด้วยการใช้เทคนิคอย่างการตัดข้อมูลที่ไม่จำเป็นออก (pruning) และการอ่านข้อมูลแบบ Synchronous ที่มี Latency ต่ำและแบนด์วิดท์สูง ทำให้คอขวดมักจะอยู่ที่ส่วนอื่น ๆ ของคิวรี เช่น Subqueries, Joins หรือ Aggregationsอย่างไรก็ตาม เมื่อ DuckDB เริ่มเข้ามามีบทบาทในการสอบถามชุดข้อมูลขนาดใหญ่ที่จัดเก็บแบบระยะไกล (Remote Storage) เช่น Data Lakes หรือการใช้งาน DuckDB ในรูปแบบ Server ด้วย Quack protocol สถานการณ์ก็เปลี่ยนไป การที่ไฟล์ข้อมูลไม่ได้อยู่บน SSD ของเครื่องอีกต่อไป ทำให้การถ่ายโอนไฟล์จาก Remote Storage มายังเครื่องที่ประมวลผลมีความสำคัญมากขึ้น ในกรณีเช่นการใช้ S3 เป็นที่เก็บข้อมูลและ EC2 เป็นเครื่องประมวลผล หากไม่สามารถส่งคำขอพร้อมกันจำนวนมากพอที่จะใช้แบนด์วิดท์เครือข่ายที่มีอยู่ได้อย่างเต็มที่ ประสิทธิภาพก็จะลดลงอย่างมาก เนื่องจากเธรด (Thread) จะต้องเสียเวลาส่วนใหญ่ไปกับการรอข้อมูลAsynchronous I/O ทำงานอย่างไรใน DuckDB? 🛠️แนวคิดหลักของ Asynchronous I/O คือการอนุญาตให้เริ่มการทำงาน I/O ได้โดยไม่ทำให้เธรดที่ร้องขอหยุดทำงาน (Block) แทนที่จะรอให้การอ่านข้อมูลเสร็จสมบูรณ์ เธรดสามารถกลับไปทำงานอื่น ๆ ได้ ใน DuckDB ได้มีการนำแนวคิดนี้มาปรับใช้โดยการแบ่งกลุ่มเธรดออกเป็น 2 ประเภท:REGULAR Threads: กลุ่มเธรดหลักที่ทำหน้าที่ประมวลผลจริง เช่น การถอดรหัสข้อมูล, การ Join, การทำ Aggregation เธรดเหล่านี้สามารถทำงาน I/O ได้เมื่อไม่ได้ยุ่งกับงานหลักASYNC Threads: กลุ่มเธรดที่ออกแบบมาเพื่องาน Asynchronous โดยเฉพาะ ซึ่งส่วนใหญ่เป็นงาน I/O ที่อาจต้องรอเป็นเวลานาน (Blocking I/O) เช่น การรอการตอบสนองจาก HTTPเหตุผลที่ต้องมีสองกลุ่มเธรดนี้ คือเธรด ASYNC มักจะใช้เวลาส่วนใหญ่ไปกับการรอ ทำให้มี CPU Utilization ต่ำ ดังนั้น DuckDB จึงสร้าง ASYNC workers จำนวนมากกว่าจำนวน System threads ทั่วไป (ค่าเริ่มต้นคือ 4 เท่าของ System threads และสูงสุดไม่เกิน 256 เธรด) เพื่อให้แน่ใจว่า ASYNC threads เหล่านี้จะทำงานอยู่ตลอดเวลาRead-Ahead Strategy: การอ่านข้อมูลล่วงหน้าเพื่อรักษา ASYNC threads ให้ทำงานอยู่เสมอ DuckDB ใช้กลยุทธ์ Read-ahead คือการกำหนดตารางการทำงาน (Fetch Tasks) ล่วงหน้า แทนที่จะรอให้เธรด REGULAR ต้องการข้อมูลก่อน จึงค่อยเริ่มอ่าน ขณะที่เธรด REGULAR กำลังถอดรหัสข้อมูลชุดปัจจุบัน เธรด ASYNC ก็จะเริ่มดึงข้อมูลสำหรับงานถัดไปเข้ามาเก็บไว้ เพื่อซ่อน Latency ของ Remote Storageการจัดการหน่วยความจำ (Memory Governance)การอ่านข้อมูลล่วงหน้าจำนวนมากอาจทำให้เกิดปัญหาหน่วยความจำไม่เพียงพอ (Out-of-memory) หากการถอดรหัสข้อมูลช้ากว่าความเร็วเครือข่าย DuckDB จึงได้นำ Asynchronous Memory Governance มาใช้ เพื่อควบคุมปริมาณข้อมูลที่ถูกอ่านเข้ามาเก็บไว้ล่วงหน้าประสิทธิภาพที่เห็นได้ชัด: ผลการทดสอบ 📊จากผลการทดสอบ TPC-H Query 6 ที่ SF100 โดยใช้ข้อมูล Parquet ขนาด 22 GB บน S3 และประมวลผลบนเครื่อง EC2 r7i.16xlarge พบว่า:Parquet: DuckDB v2.0.0-dev (Asynchronous I/O) ทำงานได้เร็วกว่า DuckDB v1.5.5 (Synchronous I/O) เกือบ 3 เท่า โดยลดเวลาจาก 8.230 วินาที เหลือ 2.844 วินาทีCSV: การทดสอบกับไฟล์ CSV ก็ให้ผลลัพธ์ที่น่าประทับใจเช่นกันNetwork Throughput: DuckDB v2.0.0-dev สามารถใช้แบนด์วิดท์เครือข่ายได้อย่างมีประสิทธิภาพมากขึ้นอย่างเห็นได้ชัด เมื่อเทียบกับ v1.5.5 ที่ใช้งานแบนด์วิดท์ได้เพียงประมาณ 5 Gbit/sการปรับแต่งค่า Asynchronous I/O เพิ่มเติม เช่น การตั้งค่า async_threads หรือการจำกัด read-ahead ทำให้ได้ประสิทธิภาพที่ดียิ่งขึ้นไปอีก โดยเวอร์ชันที่ปรับแต่งสามารถใช้แบนด์วิดท์ 25 Gbit/s ได้เกือบเต็มที่ ทำให้เวลาประมวลผลลดลงเหลือเพียง 2.227 วินาที หรือเร็วขึ้นประมาณ 3.7 เท่าเมื่อเทียบกับ v1.5.5สรุป 📌การรองรับ Asynchronous I/O ใน DuckDB v2.0 ถือเป็นก้าวสำคัญที่จะช่วยเพิ่มประสิทธิภาพอย่างมหาศาล โดยเฉพาะอย่างยิ่งสำหรับผู้ที่ใช้งาน DuckDB กับข้อมูลขนาดใหญ่ที่เก็บอยู่บน Remote Storage การปรับปรุงนี้จะช่วยลดเวลาที่เธรดต้องรอ I/O ทำให้สามารถใช้ประโยชน์จากทรัพยากรที่มีอยู่ได้อย่างเต็มที่ และเร่งความเร็วในการประมวลผลคิวรีให้ดียิ่งขึ้นสำหรับผู้ที่ต้องการทดลองใช้งาน สามารถลองใช้ DuckDB เวอร์ชัน v2.0.0-dev preview ได้แล้ววันนี้ และเตรียมพบกับการเปลี่ยนแปลงครั้งใหญ่นี้ได้ใน DuckDB v2.0 ช่วงฤดูใบไม้ร่วงปี 2026!#DuckDB #AsynchronousIO #Database #BigData #Parquet #CSVhttps://duckdb.org/2026/07/31/asynchronous-io
Shared content
DUCKDB.ORG
Asynchronous I/O in DuckDB: Work, Thread, Work
Starting with v2.0, scheduled for fall 2026, DuckDB will support asynchronous reads of Parquet and CSV files. This can significantly speed up queries when synchronous I/O does not saturate the available bandwidth, as is typical in EC2/S3 compute-storage setups.
7 Комментарии 0 Поделились 686 Просмотры 0 предпросмотр