Xử lý dữ liệu lớn trên chiếc MacBook rẻ nhất

 (duckdb.org)
4 điểm bởi GN⁺ 2026-03-13 | 2 bình luận | Chia sẻ qua WhatsApp
  • Kết quả đo lường mức độ xử lý workload cơ sở dữ liệu của MacBook Neo mới nhất bằng các benchmark ClickBench và TPC-DS SF300
  • Mẫu dùng trong thử nghiệm được trang bị chip Apple A18 Pro 6 lõi, 8GB bộ nhớ và 512GB SSD, với các bài test chạy trên DuckDB v1.5.0 và v1.4.4 LTS
  • Trong ClickBench, MacBook Neo cho kết quả nhanh hơn instance cloud ở lần chạy lạnh, được cho là nhờ tốc độ truy cập nhanh của SSD NVMe cục bộ
  • Trong bài test TPC-DS SF300, một số truy vấn đã spill ra đĩa tới 80GB, nhưng vẫn hoàn tất mọi truy vấn trong vòng 79 phút một cách ổn định
  • Dù có giới hạn cho công việc dữ liệu lớn hằng ngày, thiết bị này vẫn được chứng minh là hoàn toàn đủ dùng như một laptop cho client DuckDB

Cấu hình của MacBook Neo và mục đích thử nghiệm

  • MacBook Neo do Apple ra mắt được giới thiệu cho sinh viên và nhà văn, nhưng nhóm DuckDB đã kiểm chứng hiệu năng của máy theo triết lý “dữ liệu lớn trên laptop”
    • Mẫu bán tại châu Âu không kèm sạc, chỉ có thân máy và cáp USB-C
    • Tùy chọn chỉ gồm SSD 256GB hoặc 512GB, và bài test sử dụng bản 512GB
  • Máy được trang bị 8GB bộ nhớ và chip Apple A18 Pro (6 lõi)
    • iPhone 16 Pro dùng cùng con chip này trước đó đã hoàn thành TPC-H SF100 trong chưa đầy 10 phút trong một bài test trước

Benchmark ClickBench

  • ClickBench là benchmark cơ sở dữ liệu phân tích thực hiện 43 truy vấn trên một bảng đơn gồm 100 triệu dòng
    • Kích thước là 14GB ở định dạng Parquet và 75GB ở CSV
  • DuckDB v1.5.0 được port sang macOS để chạy thử, với giới hạn bộ nhớ đặt ở 5GB nhằm giảm phụ thuộc vào swap
  • Đối tượng so sánh:
    • MacBook Neo (2 lõi P + 4 lõi E, 8GB RAM)
    • AWS c6a.4xlarge (16 vCPU, 32GB RAM)
    • AWS c8g.metal-48xl (192 vCPU, 384GB RAM)

Kết quả và phân tích

  • Kết quả chạy lạnh:
    • MacBook Neo hoàn tất mọi truy vấn trong chưa đầy 1 phút, với trung vị 0,57 giây, cho hiệu năng nhanh nhất
    • Các instance cloud chậm hơn do độ trễ của lưu trữ qua mạng
  • Kết quả chạy nóng:
    • Tổng thời gian chạy của MacBook Neo được cải thiện khoảng 10%
    • c8g.metal-48xl là nhanh nhất nhìn chung, nhưng MacBook Neo vượt c6a.4xlarge theo thời gian trung vị
    • Tổng thời gian chạy chậm hơn c6a.4xlarge khoảng 13%

Benchmark TPC-DS

  • Sử dụng DuckDB v1.4.4 LTS, với giới hạn bộ nhớ 6GB
  • SF100:
    • Thời gian truy vấn trung vị là 1,63 giây, tổng thời gian 15,5 phút
  • SF300:
    • Thời gian truy vấn trung vị là 6,90 giây
    • Mức spill ra đĩa tối đa đạt 80GB
    • Truy vấn số 67 mất 51 phút, nhưng toàn bộ truy vấn vẫn hoàn thành trong vòng 79 phút

Những điểm cần cân nhắc khi mua

  • Với xử lý dữ liệu lớn liên tục, I/O đĩa (1,5GB/s) và 8GB bộ nhớ là những yếu tố hạn chế
    • Các mẫu Air·Pro (3–6GB/s) hoặc laptop chạy hệ điều hành khác sẽ phù hợp hơn
  • Tuy nhiên, nếu chạy DuckDB trên cloud và dùng máy cục bộ làm client, MacBook Neo vẫn hoàn toàn hữu ích
    • Máy cũng có thể xử lý ổn định các tác vụ dữ liệu cục bộ không thường xuyên

Kết luận

  • MacBook Neo, dù là một laptop giá rẻ, vẫn có thể hoàn tất các workload dữ liệu quy mô lớn dựa trên DuckDB
  • Ngay cả khi so sánh với môi trường cloud, ưu thế của SSD cục bộ vẫn hiện lên rất rõ
  • Thiết bị này được đánh giá là cấu hình tối thiểu cho phép nhà phát triển hoặc nhà phân tích dữ liệu đồng thời có tính di động và hiệu năng đủ để thử nghiệm

Bài viết liên quan

2 bình luận

 
GN⁺ 2026-03-13
Ý kiến trên Hacker News

  • Tôi muốn thử làm “công việc phát triển thực thụ” với chiếc MacBook Neo nhỏ này
    Tôi đã làm nhiều ứng dụng iOS bằng M1 MacBook Air và đã trải qua hai thương vụ startup được thâu tóm
    Tôi cũng chỉnh sửa video đua xe 4K dài 30–45 phút bằng FCP mà không gặp vấn đề gì, và Neo còn cho hiệu năng tốt hơn chiếc Air đó

    • Ngày trước tôi từng phát triển backend PHP và frontend jQuery trên một chiếc laptop cũ có bàn phím tiếng Na Uy
      Những dự án làm bằng nó đã giúp tôi có được công việc lập trình viên đầu tiên, và cũng vào ngày đó tôi biết đến Hacker News lần đầu
      Cuối cùng thì điều quan trọng là không phải phần cứng mà là khả năng bắt tay thực hiện
    • Trong kỳ nghỉ, tôi từng phát triển bằng tổ hợp Galaxy S22 + adapter HDMI + bàn phím Bluetooth thay vì laptop
      Tôi kết nối với TV và làm Elixir bằng neovim và termux, test chạy xong chỉ trong 5 giây
      Build Rust thì chậm, nhưng nhờ tính di động và hiệu quả pin nên đó vẫn là một trải nghiệm khá thú vị
    • Tôi vẫn đang dùng Intel MacBook Pro(16GB) đời 2019
      Nó vẫn gánh tốt ngay cả khi chạy đồng thời Xcode build, Docker, Claude Code và Codex
      Chỉ là tiếng quạt ồn như động cơ phản lực nên tôi đã đặt chiếc M5 Max 16" MBP(48GB) mới
      Tôi nâng cấp theo chu kỳ 7 năm nên chắc lần này cũng sẽ dùng lâu dài
    • Tôi đã build ứng dụng iOS suốt 1 năm bằng M1 Mac Mini(8GB)
      Trong lúc build thì hơi khựng lại một chút, và khi chuyển sang Firefox thì việc chuyển tab trở nên chậm hơn, nhưng vẫn hoàn toàn làm được
      Làm cùng công việc đó trên Intel MacBook Pro(16GB) thì mượt mà và dễ chịu hơn hẳn
      Cảm nhận thực tế cho thấy sự khác biệt lớn nằm ở độ phản hồi của OS
    • Mọi người thường đánh giá thấp RAM 8GB
      Nhờ bộ nhớ nén, thực tế nó có thể chứa lượng dữ liệu gấp 2–3 lần, và nhờ NVMe SSD nên cả việc đọc swap cũng nhanh
      Ngược lại, điểm thiếu sót đáng tiếc thật sự là không có đèn nền bàn phím

  • Khi giảng dạy, tôi phân loại dữ liệu như sau — nếu vừa trong bộ nhớ của một máy thì là Small data, nếu vừa trên đĩa thì là Medium data, còn lớn hơn nữa thì là Big data
    Gần đây khi hiện đại hóa một ứng dụng Python 20 năm tuổi, tôi đã làm cho backend có thể thay bằng polars hoặc duckDB, và tốc độ đã nhanh hơn 40–80 lần
    Việc này chỉ mất có hai ngày

    • Giờ đây một hệ thống đơn lẻ cũng có thể lắp tới 64TB DDR5 RAM, nên trừ cấp độ data lake ra thì gần như mọi thứ đều là Small data
    • Tôi tò mò vì sao lại có chênh lệch tốc độ lớn như vậy với polars
      Nếu dùng đúng cách thì nó rất nhanh, nhưng nếu xử lý sai thì hiệu năng có thể giảm mạnh
    • Một liên kết kinh điển nhưng vẫn còn nguyên giá trị: Your Data Fits in RAM
      Dù đắt đỏ, phần lớn vấn đề vẫn nằm gọn trong RAM
    • Nhờ NVMe, tốc độ truy cập đĩa đã nhanh hơn nên định nghĩa về ‘Medium data’ cũng trở nên mơ hồ
      Hạ tầng Big Data kiểu những năm 2000 giờ có vẻ đã lỗi thời

  • Tôi đã mất phần nào niềm tin sau khi xem bài benchmark di động của DuckDB
    So sánh một ứng dụng Swift với một ứng dụng CLI giống như so táo với chuối

    • Nhưng thí nghiệm đó là chạy ứng dụng CLI cục bộ trên smartphone
      Đó không phải so sánh iPhone với Android, mà là so với hệ thống trong một bài nghiên cứu về xử lý truy vấn vector hóa

  • Đây cũng là một lời phê bình về hiệu năng compute của AWS

    • AWS dùng EBS network storage, nên độ trễ cao hơn rất nhiều so với bus PCIe cục bộ
      Đặc biệt với tải truy cập ngẫu nhiên thì khác biệt là rất lớn
    • Nhưng chẳng phải AWS vẫn nhanh hơn laptop sao?
      Chỉ vì network disk chậm thì cũng khó mà phê phán cả AWS nói chung
      AWS cũng có instance dùng SSD cục bộ
    • Nhưng cloud vẫn đắt quá mức
      Laptop M1 Max của tôi áp đảo phần lớn instance trên cloud
      Giá băng thông có thể chênh tới 10.000 lần, và giờ phần lớn thế hệ lập trình viên chỉ biết đến cloud SaaS
      Tôi đã chứng kiến dòng chảy đó theo thời gian thực
    • Thực ra nội dung bài viết nói điều ngược lại
      “Nếu bạn làm Big Data hằng ngày trên laptop thì Neo không phù hợp”
      “Nhưng nếu chạy DuckDB trên cloud và dùng laptop như máy khách thì nó rất tuyệt” mới là ý chính

  • Tôi là một nhà sinh thái học nghèo, nhưng với chiếc máy tính nhỏ này tôi có thể xử lý toàn bộ công việc bằng R và Word
    Tôi rất hài lòng với chất lượng hoàn thiện so với mức giá

    • Bạn có đang nghiên cứu sò, nghêu không?
      Chương trình nghiên cứu về sò, nghêu được nhà nước hỗ trợ ở khu vực chúng tôi hầu như đã kết thúc hết, thật đáng tiếc
    • Nhưng bạn mua rồi à? Tôi tưởng vẫn còn ở giai đoạn pre-order

  • Tôi thật sự rất thích DuckDB
    Tôi đã làm một PoC xử lý dữ liệu được lưu dưới dạng GZ trên S3 bằng AWS Lambda,
    và đã thay 400 dòng mã C# bằng 10 dòng
    Đây là một công cụ mã nguồn mở tuyệt vời

    • Tôi nghĩ đây là một trong những món quà mã nguồn mở tuyệt vời nhất xuất hiện trong vài năm gần đây

  • Những người nói kiểu ‘năm 2026 rồi mà còn làm được gì với 8GB’ thật sự nên đọc những bài như thế này

  • Tôi ước có nhiều công ty làm thêm những màn trình diễn hiệu năng phần cứng phổ thông kiểu này
    Việc cho thấy nó thực sự gánh được mức tải nào là rất hữu ích

  • Khi benchmark thì lẽ ra nên dùng instance NVMe cục bộ (c8gd.4xlarge)

    • Ý kiến hay, nên tôi đã thực sự test lại bằng c8gd.4xlarge(950GB NVMe) và c5ad.4xlarge(cấu hình RAID 0)
      Tôi cũng so kè cùng kết quả trên MacBook M1 Max cục bộ(64GB, 10 lõi) của mình
      Kết quả là M1 Max vẫn nhanh hơn các instance cloud
      Nếu là M5 Pro/Max mới nhất thì khoảng cách có lẽ còn lớn hơn
    • Nhưng NVMe cục bộ của AWS là lưu trữ tạm thời, nên mỗi lần đều phải nạp sẵn dữ liệu lên
      Dù vậy, cho mục đích benchmark thì điều đó lại khá lý tưởng
    • Tuy nhiên trong trường hợp mất điện trên toàn khu vực thì đảm bảo tính bền vững của dữ liệu vẫn còn chưa chắc chắn
      Nếu muốn độ bền thực sự hoàn chỉnh thì vẫn cần WAL streaming

  • Việc chỉ ra ngay rằng instance cloud dùng network disk là rất tốt
    Vậy thì tôi lại thắc mắc vì sao không benchmark lại bằng instance có local storage (c8id.2xlarge, c8id.4xlarge)
 
dkang 2026-03-14

Có một bình luận hỏi liệu người dùng tên clamlady có phải là nhà nghiên cứu nghêu sò không, vì đó là một nhà sinh thái học nghèo (tôi vào xem bản gốc vì tưởng “clam” là bản dịch sai và tò mò nguyên văn là gì).