ハクソク

世界を動かす技術を、日本語で。

データ分析のための分散アーキテクチャ追求における失われた10年？

2025年5月19日原文(duckdb.org)

概要

  • 2012年製MacBook ProでDuckDBの性能を検証し、分散アーキテクチャの必要性を再考する提案。
  • 古いハードウェアでも現代的なSQL分析が十分に実行可能であることを示す確認。
  • 2023年モデルとの比較で約20倍の速度向上を記録するも、絶対的な差はユーザー体験に大きな影響を与えない指摘。
  • DuckDBの移植性と依存性の少なさが、古いOS上での動作を容易にする利点を強調。
  • 分散処理への過度な投資が本当に必要だったのか、歴史的観点から再評価することを推奨。

2012年製MacBook ProでDuckDBをベンチマーク：分散アーキテクチャの10年は無駄だったのか？

データ分析基盤の進化に関する背景

  • データ量の成長よりも ハードウェア性能の進化 が速い現状を指摘すること
  • ほとんどの有用なデータセットは 単一ノードで処理可能 になる「データ特異点」の到来を予測する提案
  • Amazon RedshiftやSnowflakeの実測値では、 中央値100MB、99.9パーセンタイルでも300GB未満 のデータ読み込みである確認
  • 2012年当時の MacBook Pro の性能に着目し、データ分析革命が既に可能だったのではないかという疑問を提示すること

2012年製Retina MacBook Proの特徴

  • 初の内蔵SSD搭載 モデルであり、4コア2.6GHz Core i7 CPUを装備する確認
  • 16GB RAMへのアップグレードが可能で、当時としては高性能ノートPCであった説明
  • 現在もDuckDB Labsオフィスで現役稼働していることを紹介すること

ソフトウェア環境とDuckDBの移植性

  • OSを OS X 10.8.5 “Mountain Lion” にダウングレードし、当時の環境を再現すること
  • DuckDBは 依存性が少なく高い移植性 を持つため、最小限の変更で古いOS上で動作可能である確認
  • C++11対応のコンパイラ不足等、当時のビルド環境の制約も考慮すること

TPC-Hベンチマークによる性能測定

  • TPC-Hベンチマーク（スケールファクタ1000） を用い、lineitemとordersテーブルでそれぞれ60億・15億行を処理すること
  • DuckDBデータベースサイズは約265GBで、16GB RAMでは キャッシュによる高速化が限定的 となる説明
  • 22クエリを5回ずつ実行し、中央値を測定することでノイズを除去する手法を採用すること
  • すべてのクエリが完了し、1分～30分程度の待ち時間で現実的な分析が可能である実証

2023年製MacBook Pro（M3 Max）との比較

  • GeekBench 5スコアで CPU性能約7倍（全コア）、シングルコアでも約3倍 の差を示すこと
  • RAM・SSD速度も大幅に向上しているが、 ディスプレイのサイズ・解像度はほぼ同等 である確認
  • 各クエリの実行時間は7～53倍高速化、 幾何平均で約20倍の改善 を記録すること

再現性と公開リソース

  • GitHubでバイナリ・スクリプト・クエリ・結果を公開 し、再現性を担保すること
  • TPC-H SF1000のデータベースファイルもダウンロード可能である案内

考察と歴史的再評価

  • 2012年製ノートPCでも 6億行規模の分析クエリが現実的な時間で完了 することを確認
  • 新旧マシンの差は 定量的なものであり、ユーザー体験としては許容範囲 である主張
  • DuckDBの アウトオブコア処理機能 により、メモリ不足でもディスク利用で大規模データ分析が可能である説明
  • 2012年時点で既に 単一ノードSQLエンジンによる分析基盤構築が可能だった のではないかという歴史的仮説を提示すること
  • ベクトル化クエリ処理技術も2005年には登場しており、分散システムへの過度な投資が本当に必要だったのか再考する提案

結論

  • 2012年の高性能ノートPCと現代的なSQLエンジン（DuckDB）があれば、 分散アーキテクチャに頼らず大規模分析が可能 であった提案
  • この10年間で失われた可能性や、 今後のデータ分析基盤の設計方針 を再検討すること

Hackerたちの意見

俺の2014年のMBP、先週やっと引退させたんだ！最初はたまに起動しなくなって、数週間後にはもうたまにしか起動しなくなったから、そろそろ引退の時かなって思った。新しいノートパソコンは実はかなり安い買い物で、Macじゃないし、いろんな面で古いMBPよりちょっと遅い。でも、古いノートパソコンは仕事で使う「大きな」VMと同じくらいの性能なんだ。今の流れは、BigQueryでボックスに収まらないような0.001%のクエリをやって、ちょっとだけ準備して中間結果をボックスに収まるように整えてる。それをVMに保存したparquetに抽出して、PythonノートブックからDuckDBを使って分析してる。DuckDBは、できることだけじゃなくて、やり方を根本的に変えてくれた。必要な要素は前からあったけど、DuckDBがそれをまとめて、使いやすさが全然違う。結合とかするのが、pandasでやるよりずっと楽になったよ。

└

まだ持ってるけど、放置されてる感じ。どうしたらいいかわからないし、捨てるのももったいない気がする。Appleストアでは返品できるけど、これに関しては何ももらえない。「はい、こちらで処理します」って感じ。画面の端が剥がれ始めて、後継機（タッチバー付きのMBP）の画面は完全に壊れてる（たぶんコネクタケーブルのせい）。使い道がないけど、捨てるのはもったいない気がするんだよね。

データベースは、ディスクサイズやクエリパフォーマンスだけじゃないんだ。データベースは会社の文化やプロセス、ワークフロー、コラボレーションを反映してる。周りにはマスターデータ、ビジネスプロセス、トランザクション、分散アプリケーション、規制要件、レジリエンシー、運用、レポート、ツールなどのエコシステムがある。データベースの役割は、クエリパフォーマンスを提供するだけじゃない。エコシステムにフィットして、いろんな面で全体的な役割を果たし、技術的な期待と非技術的な期待の幅広い範囲に応える必要がある。役に立つデータセット自体がハードウェアの進化に追いつかなくても、エコシステムの複雑さはハードウェアやAIの進化を確実に上回る。エコシステムへの全体的な適応がデータベースの選択を決めるんだ、クエリパフォーマンスじゃない。技術は孤立して動作するわけじゃない。

└

いや、データベースは自分がどう使うかによって変わるんだ。レポートは結局クエリに過ぎないし。他の名前を挙げたものがデータベースと直接関係あるとは思えない。データベースの唯一の目的はデータを保存して読み取ること、それが全てだ。だから、クエリパフォーマンスは最も重要な指標の一つなんだよ。

└

そして、会社の技術選択に影響を与えるのは、やっぱり広い意味での技術文化なんだ。ピカピカのものを追いかけて、自分の仕事に無理やり押し込もうとする技術者たち - たぶん自分の履歴書を膨らませるために皮肉っぽくやってるか、実際に正しいことだと思ってるか - が、技術チームが技術についてどう考えるか、そして自分の仕事が何だと思っているかに大きな影響を与えてる。2012年には、XML全盛期から回復しつつあって、NoSQLブームの真っ只中で、すべてがウェブスケールで分散ファーストのマイクロサービスだったりして。で、あの混乱の後、前にあったものを愛することを学んだんだ：つまり、お願いだからSQLをくれ！ :D

└

データを大きくするのは、ディスクスペースを増やしたりパフォーマンスを下げたりせずに、フォントサイズを大きくすることでいつでもできるよ！

うわ、ビッグデータチームに入っちゃった。99%のフィードが数GB以下なのに、ScalaとSparkを使わなきゃいけない。開発も実行も遅くてたまらない。

└

a) ScalaはJVM言語だから、周りで一番速い言語の一つだよ。Pythonよりもずっと速い。b) フィードの1%はどれくらいの大きさで、全体の結合データセットのサイズはどれくらいなの？結局、それがプラットフォームを作る理由なんだよね。単純なユースケースのためじゃない。

└

今の時点で誰かがScalaを書くなんて信じられない。

└

1年後、チームを説得して、最もホットなデータセット（約150万レコード）をDynamoDBからRedisに移行することができた。マジで、みんなでDynamoDBの使い方を誤ったり悪用したりするのに、すごく時間をかけてしまったよ。

Rコミュニティは小さなデータに一生懸命取り組んでる。俺はまだRのdplyrでメモリデータを扱うのが大好きだ。DataTableはエレガントで速いし。CRANのパッケージはどれも高品質で、メンテナーが2ヶ月間メールに返信しなかったら、そのパッケージは自動的に削除される。ほとんどのパッケージは、キャリアのほとんどをこれに捧げてきた大学の教授から来てるんだ。

└

インメモリのデータフレーム中心のワークフローの大きな部分は、一度に一ステップずつ進めて結果を確認するのがどれだけ簡単かってことだよ。データベースだと、クエリを実行して結果を見てから、その結果に対してクエリを実行するのが難しい。私にとっては、DuckDBでpandasやdplyr、polarsを置き換える際に欠けている部分なんだ。

Hacker Newsで議論の続きを見る