ประมวลผลบิ๊กดาต้าบน MacBook ที่ถูกที่สุด

• วัดผลว่า MacBook Neo รุ่นล่าสุดจัดการเวิร์กโหลดฐานข้อมูลได้ดีแค่ไหนด้วยเบนช์มาร์ก ClickBench และ TPC-DS SF300
• ใช้รุ่นที่มาพร้อมชิป Apple A18 Pro แบบ 6 คอร์, หน่วยความจำ 8GB และ SSD 512GB ในการทดลอง และทดสอบด้วย DuckDB เวอร์ชัน v1.5.0 และ v1.4.4 LTS
• ใน ClickBench พบว่า MacBook Neo ทำผลงานได้เร็วกว่าคลาวด์อินสแตนซ์ในการรันแบบ cold run ซึ่งวิเคราะห์ว่าเป็นผลจากความเร็วในการเข้าถึงของ local NVMe SSD
• ในการทดสอบ TPC-DS SF300 มีบางคิวรีที่เกิด disk spilling สูงสุด 80GB แต่ก็ยัง รันทุกคิวรีเสร็จภายใน 79 นาที ได้อย่างเสถียร
• แม้จะมีข้อจำกัดสำหรับงานบิ๊กดาต้าในชีวิตประจำวัน แต่ก็พิสูจน์ได้ว่าสามารถใช้งานเป็น โน้ตบุ๊กสำหรับไคลเอนต์ DuckDB ได้อย่างเพียงพอ

---

สเปกของ MacBook Neo และเป้าหมายของการทดสอบ

• MacBook Neo ที่ Apple เปิดตัวถูกนำเสนอสำหรับนักเรียนและนักเขียน แต่ทีม DuckDB ทดสอบประสิทธิภาพของมันตามแนวคิด ‘บิ๊กดาต้าบนโน้ตบุ๊ก’
  • รุ่นที่ขายในยุโรปไม่มีที่ชาร์จมาให้ และ มีเฉพาะตัวเครื่องกับสาย USB-C เท่านั้น
  • ตัวเลือกที่มีให้เลือกมีเพียง SSD 256GB หรือ 512GB และการทดสอบนี้ใช้รุ่น 512GB
• ใช้ หน่วยความจำ 8GB และชิป Apple A18 Pro (6 คอร์)
  • iPhone 16 Pro ที่ใช้ชิปตัวเดียวกันเคยทำ TPC-H SF100 เสร็จภายใน 10 นาทีในการทดสอบก่อนหน้านี้

เบนช์มาร์ก ClickBench

• ClickBench เป็นเบนช์มาร์กฐานข้อมูลเชิงวิเคราะห์ที่รัน 43 คิวรีบนตารางเดียวขนาด 100 ล้านแถว
  • ขนาดข้อมูลอยู่ที่ 14GB ในรูปแบบ Parquet และ 75GB ในรูปแบบ CSV
• พอร์ต DuckDB v1.5.0 สำหรับ macOS มารัน โดย ตั้ง memory limit ไว้ที่ 5GB เพื่อลดการพึ่งพา swap
• เครื่องที่ใช้เปรียบเทียบ:
  • MacBook Neo (2P+4E คอร์, RAM 8GB)
  • AWS c6a.4xlarge (16 vCPU, RAM 32GB)
  • AWS c8g.metal-48xl (192 vCPU, RAM 384GB)

ผลลัพธ์และการวิเคราะห์

• ผล cold run:
  • MacBook Neo รันทุกคิวรีเสร็จภายใน 1 นาที ด้วยค่ามัธยฐาน 0.57 วินาที และ ให้ประสิทธิภาพดีที่สุด
  • คลาวด์อินสแตนซ์ช้ากว่าเนื่องจาก latency ของ network storage
• ผล hot run:
  • เวลารวมในการรันของ MacBook Neo ดีขึ้นประมาณ 10%
  • c8g.metal-48xl เร็วที่สุดโดยรวม แต่ MacBook Neo ยังทำค่ามัธยฐานได้ดีกว่า c6a.4xlarge
  • เวลารวมช้ากว่า c6a.4xlarge ประมาณ 13%

เบนช์มาร์ก TPC-DS

• ใช้ DuckDB v1.4.4 LTS และตั้ง memory limit 6GB
• SF100:
  • เวลาคิวรีค่ามัธยฐาน 1.63 วินาที ใช้เวลารวม 15.5 นาที
• SF300:
  • เวลาคิวรีค่ามัธยฐาน 6.90 วินาที
  • เกิด disk spilling สูงสุด 80GB
  • คิวรีหมายเลข 67 ใช้เวลา 51 นาที และรันทุกคิวรีเสร็จภายใน 79 นาที

สิ่งที่ควรพิจารณาก่อนซื้อ

• สำหรับ งานประมวลผลบิ๊กดาต้าอย่างต่อเนื่อง ข้อจำกัดอยู่ที่ disk I/O (1.5GB/s) และ หน่วยความจำ 8GB
  • รุ่น Air หรือ Pro (3–6GB/s) หรือโน้ตบุ๊กบนระบบปฏิบัติการอื่นอาจเหมาะกว่า
• แต่หาก รัน DuckDB บนคลาวด์และใช้เครื่องโลคัลเป็นไคลเอนต์ MacBook Neo ก็ยังมีประโยชน์เพียงพอ
  • และยังรองรับ การประมวลผลข้อมูลแบบโลคัลเป็นครั้งคราว ได้อย่างเสถียร

บทสรุป

• MacBook Neo แม้จะเป็นโน้ตบุ๊กราคาประหยัด แต่ก็สามารถรันเวิร์กโหลดข้อมูลขนาดใหญ่บน DuckDB ได้จนจบ
• เมื่อเทียบกับสภาพแวดล้อมคลาวด์ ก็เห็นได้ชัดถึง ข้อได้เปรียบของ local SSD
• จึงถูกประเมินว่าเป็น อุปกรณ์สเปกขั้นต่ำที่เหมาะสำหรับนักพัฒนาหรือนักวิเคราะห์ข้อมูลที่ต้องการทั้งความพกพาและประสิทธิภาพสำหรับการทดลอง

[GN⁺]

ความเห็นบน Hacker News

• ผมอยากลองทำ ‘งานพัฒนาจริงๆ’ บน MacBook Neo เครื่องเล็กนี้
  ผมเคยสร้างแอป iOS หลายตัวด้วย M1 MacBook Air และผ่านกระบวนการถูกซื้อกิจการของสตาร์ทอัพมาสองครั้ง
  แม้จะตัดต่อวิดีโอแข่ง 4K ความยาว 30–45 นาทีใน FCP ก็ไม่มีปัญหา และ Neo ก็ให้ประสิทธิภาพดีกว่า Air เครื่องนั้นอีก

  • เมื่อก่อนผมเคยพัฒนา PHP backend กับ jQuery frontend บนโน้ตบุ๊กมือสองที่ใช้คีย์บอร์ดนอร์เวย์
    โปรเจ็กต์ที่ทำบนเครื่องนั้นกลายเป็นจุดเริ่มต้นที่ทำให้ผมได้งานนักพัฒนางานครั้งแรก และวันนั้นก็เป็นครั้งแรกที่ผมรู้จัก Hacker News
    สุดท้ายแล้วสิ่งสำคัญคือ ความสามารถในการลงมือทำ ไม่ใช่ฮาร์ดแวร์
  • ตอนพักร้อน ผมเคยพัฒนาโดยใช้ชุด Galaxy S22 + อะแดปเตอร์ HDMI + คีย์บอร์ดบลูทูธ แทนโน้ตบุ๊ก
    ผมต่อเข้าทีวีแล้วพัฒนา Elixir ด้วย neovim และ termux โดยรันเทสต์เสร็จใน 5 วินาที
    การ build Rust ช้าหน่อย แต่ด้วยความพกพาง่ายและประสิทธิภาพแบตเตอรี่ที่ดี มันก็เป็นประสบการณ์ที่สนุกมาก
  • ผมยังใช้ Intel MacBook Pro (16GB) รุ่นปี 2019 อยู่
    เปิด Xcode build, Docker, Claude Code และ Codex พร้อมกันก็ยังเอาอยู่
    แต่เสียงพัดลมดังระดับเครื่องบินไอพ่น เลยสั่ง M5 Max 16" MBP (48GB) ใหม่แล้ว
    ผมอัปเกรดทุก 7 ปี ดังนั้นรอบนี้ก็น่าจะใช้อีกนาน
  • ผมเคยใช้ M1 Mac Mini (8GB) build แอป iOS อยู่ 1 ปี
    ระหว่าง build จะหน่วงนิดหน่อย และตอนสลับไป Firefox การเปลี่ยนแท็บจะช้าลง แต่ก็ยังทำงานได้สบาย
    ถ้าทำงานเดียวกันบน Intel MacBook Pro (16GB) จะลื่นและสบายกว่ามาก
    ความต่างด้าน การตอบสนองของระบบปฏิบัติการ รู้สึกได้ชัด
  • คนมักประเมิน หน่วยความจำ 8GB ต่ำเกินไป
    ด้วย compressed memory มันจึงเก็บข้อมูลได้จริงราว 2–3 เท่า และด้วย NVMe SSD การอ่าน swap ก็เร็ว
    สิ่งที่น่าเสียดายจริงๆ กลับเป็น ไม่มีไฟแบ็กไลต์คีย์บอร์ด

• เวลาผมสอน ผมแบ่งข้อมูลแบบนี้ — ถ้าใส่ในหน่วยความจำของเครื่องเดียวได้ทั้งหมดคือ Small data ถ้าใส่ในดิสก์ได้คือ Medium data และถ้าเกินกว่านั้นคือ Big data
  ตอนนี้ผมกำลังปรับแอป Python อายุ 20 ปีให้ทันสมัย โดยทำให้ backend เปลี่ยนไปใช้ polars หรือ duckDB ได้ ซึ่งทำให้เร็วขึ้น 40–80 เท่า
  งานนี้ใช้เวลาแค่สองวัน

  • ทุกวันนี้ระบบหนึ่งใส่ 64TB DDR5 RAM ได้แล้ว ดังนั้นถ้าไม่ใช่ระดับ data lake ข้อมูลแทบทั้งหมดก็นับเป็น Small data
  • ผมสงสัยว่าทำไม polars ถึงทำให้เร็วขึ้นได้ขนาดนั้น
    ถ้าใช้ถูกวิธีมันเร็วมาก แต่ถ้าใช้ผิด ประสิทธิภาพก็อาจตกลงไปมาก
  • ลิงก์คลาสสิกที่ยังใช้ได้เสมอ Your Data Fits in RAM
    แม้ RAM จะแพง แต่ปัญหาส่วนใหญ่ก็ยังใส่อยู่ใน RAM ได้
  • ด้วย NVMe ความเร็วในการเข้าถึงดิสก์ก็สูงขึ้น ทำให้นิยามของ ‘Medium data’ เริ่มคลุมเครือ
    โครงสร้างพื้นฐาน Big Data แบบยุค 2000 ดูเหมือนจะล้าสมัยไปแล้ว

• ผมหมดความเชื่อถือหลังอ่าน บทความ benchmark บนมือถือของ DuckDB
  การเอาแอป Swift ไปเทียบกับแอป CLI ดูเหมือน เอาแอปเปิลไปเทียบกับกล้วย

  • แต่การทดลองนั้นคือการรัน แอป CLI แบบ local บนสมาร์ตโฟน
    ไม่ใช่การเปรียบเทียบระหว่าง iPhone กับ Android แต่เป็นการเปรียบเทียบกับ ระบบจากงานวิจัยด้าน vectorized query processing

• นี่ก็เป็นคำวิจารณ์เรื่อง ประสิทธิภาพ compute ของ AWS ด้วย

  • AWS ใช้ EBS network storage จึงมี latency สูงกว่าบน local PCIe bus มาก
    โดยเฉพาะกับ ภาระงานแบบ random access ความต่างยิ่งชัด
  • แต่ AWS ก็ยังไม่น่าจะช้ากว่าโน้ตบุ๊กไม่ใช่เหรอ?
    แค่ network disk ช้า ไม่น่าจะใช้วิจารณ์ AWS ทั้งหมดได้
    ใน AWS ก็มี อินสแตนซ์ที่ใช้ local SSD เหมือนกัน
  • แต่ถึงอย่างนั้น คลาวด์ก็ยัง แพงเกินจริง
    โน้ตบุ๊ก M1 Max ของผมเหนือกว่าคลาวด์อินสแตนซ์ส่วนใหญ่
    ราคาค่าแบนด์วิดท์ต่างกันได้ถึง 10,000 เท่า และตอนนี้นักพัฒนารุ่นใหม่จำนวนมากรู้จักแค่ คลาวด์ SaaS
    ผมเห็นกระแสนี้เกิดขึ้นแบบเรียลไทม์
  • จริงๆ แล้วเนื้อหาในบทความสื่อสารตรงกันข้าม
    ใจความคือ “ถ้าคุณทำงาน Big Data บนโน้ตบุ๊กทุกวัน Neo ไม่เหมาะ”
    “แต่ถ้ารัน DuckDB บนคลาวด์ แล้วใช้โน้ตบุ๊กเป็นไคลเอนต์ มันยอดเยี่ยมมาก”

• ผมเป็นนักนิเวศวิทยาฐานะไม่ดีนัก แต่คอมพิวเตอร์เล็กๆ เครื่องนี้ก็จัดการงาน R และ Word ของผมได้ทั้งหมด
  ผมพอใจกับ คุณภาพงานประกอบที่ดีมากเมื่อเทียบกับราคา มาก

  • คุณกำลังทำวิจัย หอย อยู่หรือเปล่า?
    น่าเสียดายที่โครงการวิจัยหอยซึ่งได้รับการสนับสนุนจากรัฐบาลในพื้นที่เราส่วนใหญ่ยุติไปแล้ว
  • แต่คุณซื้อแล้วเหรอ? ผมนึกว่ายังอยู่ช่วง พรีออร์เดอร์

• ผมชอบ DuckDB มากจริงๆ
  ผมเคยทำ PoC สำหรับประมวลผลข้อมูลที่เก็บแบบ GZ บน S3 ด้วย AWS Lambda และ
  แทนที่ โค้ด C# 400 บรรทัด ด้วยเพียง 10 บรรทัด
  เป็นเครื่องมือโอเพนซอร์สที่น่าทึ่งมาก

  • ผมคิดว่านี่เป็นหนึ่งใน ของขวัญจากโอเพนซอร์สที่ยอดเยี่ยมที่สุด ในช่วงหลายปีที่ผ่านมา

• คนที่พูดว่า ‘ปี 2026 แล้วจะทำอะไรกับ 8GB ได้’ ควรอ่านบทความแบบนี้จริงๆ

• อยากให้มีบริษัททำ โชว์เคสประสิทธิภาพฮาร์ดแวร์ทั่วไป แบบนี้มากกว่านี้
  การได้เห็นว่ามันรับภาระงานจริงได้แค่ไหนมีประโยชน์มาก

• ตอนทำ benchmark ควรใช้ local NVMe instance (c8gd.4xlarge) มากกว่า

  • เป็นข้อสังเกตที่ดี ดังนั้นผมเลยทดสอบใหม่ด้วย c8gd.4xlarge (NVMe 950GB) และ c5ad.4xlarge (ตั้งค่าแบบ RAID 0)
    และเทียบกับผลจาก MacBook M1 Max (64GB, 10-core) ของผมด้วย
    ผลคือ M1 Max ก็ยังเร็วกว่า cloud instance อยู่ดี
    ถ้าเป็น M5 Pro/Max รุ่นใหม่ ช่องว่างก็น่าจะยิ่งกว้างขึ้น
  • แต่ local NVMe ของ AWS เป็น สตอเรจแบบไม่คงอยู่ถาวร ดังนั้นทุกครั้งต้องอัปโหลดข้อมูลเข้าไปล่วงหน้า
    ถึงอย่างนั้น สำหรับจุดประสงค์ด้าน benchmark มันกลับเหมาะอย่างยิ่ง
  • แต่อย่างไรก็ดี หากเกิดไฟดับทั้งรีเจียน ก็ยังไม่ชัดเจนว่าจะ รับประกันความคงทนของข้อมูล ได้หรือไม่
    ถ้าต้องการความทนทานเต็มรูปแบบ ก็ยังต้องใช้ WAL streaming อยู่ดี

• การชี้ได้ทันทีว่า cloud instance ใช้ network disk ถือว่าดีมาก
  ถ้าอย่างนั้นก็สงสัยว่าทำไมไม่ benchmark ใหม่ด้วย local storage instance (c8id.2xlarge, c8id.4xlarge)

[dkang]

มีคอมเมนต์ถามว่าเพราะนักนิเวศวิทยาที่ยากจนใช้ไอดีว่า clamlady เลยเป็นนักวิจัยหอยหรือเปล่า (ฉันนึกว่าคำว่า หอย เป็นการแปลผิด เลยเข้าไปดูต้นฉบับเพราะสงสัยว่าจริง ๆ เขียนว่าอะไร)