最も安価なMacBookでビッグデータを処理する

 (duckdb.org)
4 ポイント 投稿者 GN⁺ 2026-03-13 | 2件のコメント | WhatsAppで共有
  • 最新のMacBook Neoがデータベースワークロードをどの程度うまく処理できるかを、ClickBenchとTPC-DS SF300ベンチマークで測定した結果
  • 6コアApple A18 Proチップ、8GBメモリ、512GB SSDを搭載したモデルを実験に使用し、DuckDB v1.5.0とv1.4.4 LTSでテストを実施
  • ClickBenchでは、コールドランでMacBook Neoがクラウドインスタンスより高速な結果を示し、これはローカルNVMe SSDの高速なアクセス速度によるものと分析された
  • TPC-DS SF300テストでは、一部のクエリで最大80GBのディスクスピリングが発生したものの、すべてのクエリを79分以内に完了し、安定して実行
  • 日常的なビッグデータ作業向けには限界があるが、DuckDBクライアント用ノートPCとしては十分に活用可能であることを実証

MacBook Neoの仕様とテスト目的

  • Appleが発売したMacBook Neoは学生・作家向けとして紹介されたが、DuckDBチームはこれを**「ノートPCでのビッグデータ」**という思想に沿って性能検証した
    • 欧州販売モデルには充電器が含まれず、ノートPC本体とUSB-Cケーブルのみが提供される
    • 選択可能なオプションは256GBまたは512GB SSDのみで、テストでは512GBモデルを使用
  • 8GBメモリと**Apple A18 Pro（6コア）**チップを搭載
    • 同じチップを採用したiPhone 16 Proは、以前のテストでTPC-H SF100を10分以内に完了している

ClickBenchベンチマーク

  • ClickBenchは、1億行の単一テーブルで43個のクエリを実行する分析型データベースベンチマーク
    • Parquet形式で14GB、CSVで75GBのサイズ
  • DuckDB v1.5.0をmacOS向けにポーティングして実行し、メモリ制限を5GBに調整してスワップ依存を減らした
  • 比較対象:
    • MacBook Neo (2P+4Eコア、8GB RAM)
    • AWS c6a.4xlarge (16 vCPU, 32GB RAM)
    • AWS c8g.metal-48xl (192 vCPU, 384GB RAM)

結果と分析

  • コールドラン結果:
    • MacBook Neoはすべてのクエリを1分以内に完了し、中央値0.57秒で最も速い性能を示した
    • クラウドインスタンスはネットワークストレージの遅延により遅い結果となった
  • ホットラン結果:
    • MacBook Neoの総実行時間は約10%改善
    • c8g.metal-48xlが全体的に最も高速だが、MacBook Neoは中央値ベースでc6a.4xlargeより優秀
    • 総実行時間はc6a.4xlargeより約13%遅い

TPC-DSベンチマーク

  • DuckDB v1.4.4 LTSを使用し、メモリ制限6GBに設定
  • SF100:
    • クエリ時間の中央値は1.63秒、全体で15.5分を要した
  • SF300:
    • クエリ時間の中央値は6.90秒
    • 最大80GBのディスクスピリングが発生
    • クエリ67が51分を要し、全体では79分以内にすべてのクエリを完了

購入時の考慮事項

  • 継続的なビッグデータ処理用としては、ディスクI/O（1.5GB/s）と8GBメモリが制約要因
    • Air・Proモデル（3–6GB/s）や他OSベースのノートPCのほうが適している
  • ただし、クラウドでDuckDBを実行し、ローカルをクライアントとして使う場合、MacBook Neoは十分に有用
    • 断続的なローカルデータ処理にも安定して対応可能

結論

  • MacBook Neoは低価格ノートPCでありながら、DuckDBベースの大規模データワークロードを完走できる
  • クラウド環境との比較でも、ローカルSSDの利点がはっきり表れた
  • 開発者やデータアナリストが携帯性と実験用性能を同時に確保できる最小構成のデバイスとして評価できる

関連記事

2件のコメント

 
GN⁺ 2026-03-13
Hacker Newsの意見

  • この小さな MacBook Neo で「本当の開発作業」をしてみたかった
    M1 MacBook AirでiOSアプリをいくつも作り、スタートアップの買収を2回経験した
    FCPで4Kのレース映像を30〜45分ものに編集しても問題なく、NeoはそのAirよりも高い性能を見せている

    • 昔はノルウェー語キーボード付きの中古ノートPCでPHPバックエンドとjQueryフロントエンドを開発していた
      それで作ったプロジェクトが最初の開発者職を得るきっかけになり、その日に Hacker News を初めて知った
      結局重要なのは ハードウェアではなく実行力 だ
    • 休暇中はノートPCの代わりに Galaxy S22 + HDMIアダプター + Bluetoothキーボード の組み合わせで開発していた
      TVにつないでneovimとtermuxでElixir開発を行い、テストは5秒で終わった
      Rustのビルドは遅かったが、携帯性とバッテリー効率のおかげでかなり楽しい体験だった
    • 2019年モデルの Intel MacBook Pro(16GB) を今でも使っている
      Xcodeビルド、Docker、Claude Code、Codexを同時に動かしても十分耐える
      ただしファンの騒音がジェット機レベルなので、新しい M5 Max 16" MBP(48GB) を注文した
      7年周期でアップグレードしているので、今回も長く使えそうだ
    • M1 Mac Mini(8GB) で1年間iOSアプリをビルドしていた
      ビルド中は少しもたつき、Firefoxに切り替えるとタブ切り替えが遅くなったが、十分実用になった
      同じ作業を Intel MacBook Pro(16GB) でやるとずっと滑らかで快適だった
      体感ではOSの 応答性 の差が大きかった
    • 人はしばしば 8GBメモリ を過小評価する
      圧縮メモリのおかげで実際には2〜3倍のデータを載せられ、NVMe SSDのおかげでスワップ読み出しも速い
      むしろ本当に惜しいのは キーボードバックライトがないこと だ

  • 私は講義でデータをこう分類している — 1台のマシンのメモリに全部入れば Small data、ディスクに入れば Medium data、それ以上は Big data だ
    最近20年前のPythonアプリをモダナイズしながら、backendを polars や duckDB に置き換えられるようにしたところ、速度が40〜80倍速くなった
    この作業には2日しかかからなかった

    • 今では1台のシステムに 64TB DDR5 RAM も積めるので、データレイク級でなければほとんど全部Small dataだ
    • polars でそこまで大きな速度差が出た理由が気になる
      正しく使えば速いが、扱い方を誤ると性能は大きく落ちる
    • 古典だが今でも有効なリンク Your Data Fits in RAM
      高価ではあっても、ほとんどの問題は依然としてRAMに収まる
    • NVMeのおかげでディスクアクセス速度が速くなり、「Medium data」の定義も曖昧になった
      2000年代式の Big Data インフラ はもう古くなったように思える

  • 私は DuckDBのモバイルベンチマーク記事 を見て信頼が下がった
    SwiftアプリとCLIアプリを比較するのは リンゴとバナナの比較 のように感じた

    • でもその実験はスマートフォン上で ローカルCLIアプリ を動かしたものだった
      iPhoneとAndroidの比較ではなく、ベクトル化クエリ処理の研究論文システム との比較だった

  • これは AWSのコンピュート性能 への批判でもある

    • AWSは EBSネットワークストレージ を使っていたため、ローカルPCIeバスと比べてレイテンシがはるかに大きい
      特に ランダムアクセス負荷 では大きな差になる
    • それでもAWSのほうがノートPCより速くなかったのか？
      ネットワークディスクが遅かったからといってAWS全体を批判するのは難しい
      AWSにも ローカルSSDインスタンス がある
    • それでもクラウドは依然として 過度に高い
      私の M1 Max ノートPCは大半のクラウドインスタンスを圧倒する
      帯域幅価格は1万倍の差が出ることもあり、いまや開発者世代の多くは クラウドSaaS しか知らない
      その流れをリアルタイムで見てきた
    • 実際には記事の内容は逆だ
      「Big Data作業を毎日ノートPCでやるならNeoは適していない」
      「ただしクラウドでDuckDBを動かし、ノートPCをクライアントとして使うなら素晴らしい」というのが要旨だった

  • 私は貧しい生態学者だが、この小さなコンピュータで RとWord の作業をすべてこなせる
    価格に対して 完成度の高いビルド品質 にとても満足している

    • もしかして 貝類の研究 をしているのですか？
      私たちの地域の政府支援の貝類研究プログラムはほとんど終了してしまい残念だ
    • でももう購入したの？ まだ 予約注文段階 だと思っていた

  • 私は DuckDB が本当に大好きだ
    AWS LambdaでS3にGZで保存されたデータを処理するPoCをやったが、
    400行のC#コード を 10行 に置き換えた
    驚くべきオープンソースツールだ

    • ここ数年で登場した 最も素晴らしいオープンソースの贈り物 の1つだと思う

  • 「2026年に8GBで何をするんだ」と言う人たちには、こういう記事をぜひ読んでほしい

  • こうした 一般的なハードウェア性能のショーケース をもっと多くの企業がやってほしい
    実際にどの程度の負荷をさばけるのかを示すのは有益だ

  • ベンチマークをするときは ローカルNVMeインスタンス(c8gd.4xlarge) でやるべきだった

    • 良い指摘だったので、実際に c8gd.4xlarge(950GB NVMe) と c5ad.4xlarge(RAID 0構成) で再テストした
      ローカルの MacBook M1 Max(64GB, 10コア) の結果もあわせて比較した
      結果として M1 Max は依然としてクラウドインスタンスより速い
      最新の M5 Pro/Max ならさらに差が広がりそうだ
    • ただしAWSの ローカルNVMe は 揮発性ストレージ なので、毎回データを事前に載せる必要がある
      それでもベンチマーク目的にはむしろ理想的だ
    • ただ、リージョン全体の停電時に データ永続性の保証 がまだ不確かだ
      完全な耐久性が必要なら依然として WALストリーミング が必要だ

  • クラウドインスタンスが ネットワークディスク を使っているとすぐ見抜いたのは良かった
    それならなぜ ローカルストレージインスタンス(c8id.2xlarge, c8id.4xlarge) でベンチマークをやり直さなかったのか気になる
 
dkang 2026-03-14

貧しい生態学者さんのIDが clamlady なので、ハマグリ研究者なのかと尋ねるコメントが付いていました（「clamlady」が誤訳なのかと思って原文が気になり、見に行ってみました）。