性能だけでは不十分
(motherduck.com)- データベース選定で 生のクエリ速度 と汎用ベンチマークだけを見ると、ユーザーが質問から答えにたどり着くまでの全体時間を見落としやすい
- 2019年のGigaOmベンチマークでは Azure Data Warehouse と Redshift が上位だったが、実際の市場では Snowflake と BigQuery の方が売れており、性能以外の要素の強さを示した
- サーバー実行時間を短縮しても、JDBCドライバ、結果のダウンロード、CSVパース、SQL作成の難しさといった周辺経路の方が大きなボトルネックになり得る
- ClickBench、TPC-H、TPC-DS は有用だが、JOINの有無、単一テーブルスキャン、スキーマチューニング、正確性・ACID保証の条件によって結論は変わる
- データベースエンジンの性能は時間とともに収束していくため、長期的な選定基準は現在の順位よりも アイデアから答えまでの速さ とワークフロー統合性であるべき
ベンチマークが見落とす実際の待ち時間
- シアトルの自宅からサンフランシスコのオフィスまで4.5時間かかる移動では、飛行機の巡航速度を10倍にしても、空港までの移動・保安検査・搭乗・滑走路待機・手荷物・到着後の移動のため、全体時間は約20%しか短縮されないことがある
- データベースも同じ
- エンジンが速くなっても、ユーザーはおかしなCSVファイル、SQLで質問を表現しにくい問題、ツール接続の問題にも直面する
- ベンチマーク戦争に勝った製品は宣伝しやすいが、それがユーザーの問題解決時間をそのまま短縮することを意味しない
- データベース選定では 使いやすさ、エコシステム、更新速度、ワークフロー統合性の方がより良い判断基準になり得る
- 性能は特定時点の特定作業時間しか示さず、見当違いのボトルネックを一生懸命最適化させてしまうことがある
2019年GigaOmの結果と市場の食い違い
- 2019年のGigaOmはクラウドデータウェアハウスを対象に TPC-HとTPC-DSベンチマーク を実施した
- 対象は3大クラウドベンダーと Snowflake だった
- 結果は Azure Data Warehouse が最速で、Redshift が続き、Snowflake と BigQuery は大きく後れを取った
- 当時のBigQueryのユーザー評価では、Azure と直接比較した顧客が BigQuery を選ぶケースが多かった
- 市場の結果はベンチマーク順位とほぼ逆だった
- Snowflake と BigQuery は Redshift より多く売れた
- Redshift は Azure よりよく売れた
- TPC-H と TPC-DS は業界標準であり、内部性能判断にも使われていたテストだったが、良い性能ベンチマークで低順位だったシステムを顧客がより多く買ったのなら、性能より重要な要素 があったと見なせる
ユーザーが体感する速さはサーバー時間ではない
- データベースを作る人たちは、ユーザーが「run」ボタンを押してから結果の準備ができるまでの サーバー実行時間 に集中しがちだ
- ユーザーにとって重要なのは作業を終えるまでの全体時間であり、これはデータベースサーバーがクエリを実行する時間とは異なる
- BigQueryのJDBCドライバの事例はこの違いをよく示している
- JDBCドライバは、プログラマーやBIツールがデータベースに接続する際に使う汎用インターフェースだった
- BigQueryのクエリは1〜2秒で実行されたが、ドライバの完了ポーリングと結果ダウンロード方式のため、ユーザーには数秒から数分遅く見えた
- 結果が多い場合、ドライバはユーザーが必要としないデータまでページ単位で全部取得し、遅延が大きくなり、メモリ不足でクラッシュすることもあった
- エンジニアたちはクエリ時間を数分の1秒縮めることに多くの時間を費やしたが、実際にユーザーが多用していたコネクタの方がより大きな遅延を生んでいた
- 内部ベンチマークは毎日回っていたが、エンドツーエンド性能 とユーザー体感時間は見えていなかった
性能は単一の数値に固定されない
- 性能はデータベースの視点ではなく ユーザー視点 で測るべきで、UXのように1つの数値で完全に説明するのは難しい
- どのデータベースがより速いかは実際のワークロード次第で変わる
- Lamborghini が Prius より速くても、渋滞では通勤時間が変わらないことがある
- ClickHouse と Redshift の性能差も使い方によって変わる
- ClickHouse の ClickBench は ClickHouse が複数のデータベースより速いという結果を示した
- ベンチマークは JOIN なしで単一テーブル上で動作し、distinct カウントに大きく依存していた
- ログ分析やWebサイトのユニークユーザー計算には良い代理指標になり得る
- 伝統的なデータウェアハウスの スター・スキーマ ワークロードでは誤解を招く可能性がある
- ベンダーベンチマークは通常、そのベンダーが得意な部分に焦点を当てる
- BigQuery はベンチマークでは低く見えることがあっても、調整ノブがほとんどなく概ね自己チューニングされるため、実際のユーザー体験では良く感じられることがある
- 高度にチューニングされた SingleStore インスタンスは多くの作業で BigQuery を圧倒できるが、スキーマ調整の時間や新しいワークロード追加時の対応が必要になる
- 性能向上のために安全装置や正確性を削ることもできる
- overflow check の削除
- write flush の省略
- 一部演算で近似結果を提供
- ACID保証 を提供しない
- こうした近道は、統制された環境を除けば使いたくない選択肢になり得る
今の順位より改善速度の方が長く効く
- DuckDBベースの会社を作る際、DuckDB が h2o.ai ベンチマーク で大きく負けているという指摘があった
- 気にしなかった理由は2つあった
- 性能は二次的要素だった
- DuckDB は非常に速いペースで改善されていた
- DuckDB の高速な改善には、一部のアーキテクチャ上の判断、比較的新しくクリーンなコードベース、優秀なエンジニアたちが影響していた
- 同じベンチマークの最新DuckDBリリースを対象にした 公開結果 では、DuckDB は中位圏から大差をつけて上位圏へ移動した
- データベース選定は数年続く意思決定なので、現在の性能や機能だけでなく 1年後に可能な能力 も重要だ
- 2つのデータベースが異なる速度で改善しているなら、より速く動く方を選ぶほうが長期的に有利である可能性が高い
性能差は時間とともに縮まる
- 積極的に保守されている複数のデータベースを数年にわたり改善し続けると、性能は収束する傾向がある
- ある製品の性能技法は、時間がたつと他の製品にも実装され得る
- ClickHouse がスキャン速度で有利な技法を使えば、Snowflake も1〜2年以内に似た機能を持てるかもしれない
- Snowflake が増分 materialized view を追加すれば、BigQuery もすぐ追随するかもしれない
- データベースごとに性能を出す技法は異なる
- クエリをマシンコードにコンパイルする
- データをローカルSSDにキャッシュする
- 特殊なネットワークハードウェアで shuffle を処理する
- 効果的な技法は時間さえあれば誰でも実装でき、うまく機能すれば複数のシステムへ広がる可能性が高い
- Fivetran CEO George Fraser の データウェアハウス性能比較 では、2020年の最速時間は8秒、最遅時間は18秒だったが、2022年には3ベンダーが約7秒、最も遅いベンダーでも9秒へと近づいた
- ただし、アーキテクチャの差 は克服しにくい
- shared nothing データベースは shared disk に対して不利な場合がある
- Redshift は主に shared disk アーキテクチャへ移行するのに数年かかった
- オブジェクトストアにメタデータを保存する lakehouse は高速更新に苦労することがある
- こうした差は主に境界条件で現れ、長期的に Redshift が Snowflake より本質的に速い、あるいは遅い理由はない
質問から答えまでの時間を縮める機能
- ユーザーにとって重要な性能とは、質問が生まれた瞬間から答えを得る瞬間までの時間だ
- この時間を縮める方法はクエリ計画の改善だけではない
- 質問をより簡単に表現できるようにする
- クエリ結果を理解しやすい形に変える
- 間違った質問をしたときにフィードバックを返す
- データの問題を理解するのを助ける
- 必要なデータを正しい場所と形式で準備できるようにする
- Snowflake は、ユーザーがSQLを入力したときに「とにかく動く」ようにする点に強みがあった
- 日付差を計算するときに DATEDIFF と TIMEDIFF の両方を使える
- 妥当な型であればどちらも動作する
- granularity を指定しても省略してもよい
- granularity にクォートを付けても付けなくてもよい
- DuckDB も Friendlier SQL により、クエリ作成や保守を容易にする機能を追加した
GROUP BY ALLは集計クエリで GROUP BY 句のフィールド抜けを減らす- SELECT リストだけを変えればよいため、クエリ進化時に複数箇所を修正する必要が減る
- この機能が有用だと分かると、複数のデータベースベンダーが類似機能を追加した
- CSVファイルは世界中の多くのデータを収める形式だが、多くのファイルは構成が不完全で、パースは実際かなり難しい
- BigQuery 初期の CSV splitter は推論ができず、ファイル間でスキーマが少し違うだけで混乱していた
- CSVパース は思った以上に厄介な問題だ
- 2人のエンジニアがCSVデータを読み込み同じ結果を計算しなければならないなら、CSVをより簡単かつ正しく ingest できる方が、クエリエンジン速度とは無関係に先に答えへ到達できる
- 結果処理の方式もユーザー体験に大きく影響する
SELECT *が MySQL のように最初のページと cursor を返せば即座に表示できる- BigQuery のようにサーバー側でテーブルのコピーを作る必要があるなら、大きなテーブルでは数時間かかることがある
- クライアントが全データをダウンロードしようとするとメモリ不足になることがある
- 長い接続はネットワーク障害に弱く、ポーリングはクエリがポーリング間隔のあいだに終わると実際より遅く見えることがある
DuckDBベンチマークを見る際の手がかり
- DuckDB は高速で、一部の machine size における ClickBench で最上位圏に入っている
- 例として c6a.4xlarge の結果が示されている
- DuckDB は大半の h2o.ai ベンチマーク でも良好な性能を示し、TPC-H と TPC-DS でも悪くない
- どのデータベースが速いと判断する前に、自分の ワークロード で直接試すべきだ
速いクエリより速い問題解決
- 最も成功したデータベース企業が競合より速いという理由だけで成功したわけではない
- Redshift がしばらく強かった一方で、Snowflake が参入できた理由はベンチマーク性能ではなく 保守性 にあった
- 性能を主な売り文句にしたデータベースは市場で良い成果を出せず、作業を簡単に終わらせてくれるデータベースの方がより長く生き残った
- データベース選定で見るべき軸はもっと広い
- 魔法のような秘密の技法はなく、アーキテクチャ差を除けば性能は時間とともに収束する
- データベースエンジンの改善速度は大きく異なり、速く動く側が長期的に有利だ
- 性能に最も執着するデータベースベンダーは長期的には遅くなる可能性がある
- データベース性能に単一指標はなく、高速なデータベースでも特定ワークロードでは悪いことがある
- 重要なのはクエリから結果までではなく、アイデアから答えまで どれだけ速く進めるかだ
- 遅いクエリより速いクエリの方がよいが、データベース選定は生の速度以外の要素を基準にすべきだ
1件のコメント
Hacker Newsの意見
何年ものあいだ顧客からの不満が多かったのに、JDBCドライバの問題が性能を台無しにしていることを「まったく知らなかった」というくだりにはもどかしさを覚える。
Googleは社内で実際の顧客のように自社製品を使っておらず、ユーザーが目にするクエリ時間も社内では見えていなかったため、他人事として扱っていたという話だ。
問題は最適化に労力をかけすぎたことではなく、顧客の痛みから出発して根本原因まで追跡しなかった点にある。実際の原因も結局は性能問題だった。
JDBCの話は本当によかった。Googleは社内ではうまく動くデータベースを作ったが、外の世界向けのアダプタ層は外注で作られ、それがまともに動かなかったせいで、外部ユーザーはひどいデータベースを使わされることになった。
Googleが使う洗練された中核の上に壊れた包装紙をかぶせたせいで、製品全体が不必要に台無しになっていたわけで、社内では誰も気づかず、外部ユーザーも原因を特定しづらかった。Googleのオープンソース戦略を非常に的確に示す事例に見える。
問題は、非中核領域を十分に壊してしまえば、中核能力がどれだけ優れていても意味がなくなることだ。アウトソーシングにただ飯はない。
記事では「性能は主観的」で、単純な測定だけでは不十分だとしているが、実際の例は性能が本当に重要で客観的だったケースだ。ただし、間違った対象を測っていただけだ。
これは会社の組織問題のように聞こえる。最終目標が人々にクラウドを使ってもらい価値を提供することなら、なぜ顧客が重要視するものとずれた指標を持っているのか分からない。
Googleの中に、顧客と直接話して何が問題かを把握し、それをエンジニアに伝えて何を改善すべきか分からせる人がいるべきだ。組織は、エンジニアが必要な指標を受け取れるようにするか、その指標を作ること自体が職務に含まれるよう設計されるべきだ。
製品と組織のリーダーシップはどんな指標を見ていたから、こうした顧客フィードバックを見逃したのかのほうが気になる。
「Seattleの家からSan Franciscoのオフィスまでドア・ツー・ドアで4.5時間」というくだりを見ると、最近の起業家はもう時速179マイルでは動いていないようだ。FRBが金利を上げるとこうなるらしい。
良い指摘はいくつもあるが、結論は少しずれている感じがする。性能はここで言われているように副次的というより、十分かどうかに近い。
十分に速いかという関門を通過して初めて、その次に他の要素を判断できる。それ以前は競争のテーブルにすら着けない。著者も「DuckDBは速い」と言っているが、もし速くなかったなら、少なくともそのチェックボックスを埋めるまでは性能で競争するしかなかったはずだ。
また、「最も速く動くデータベースエンジンが結局は勝つ」という言い方はある程度正しいかもしれないが、実用的ではない。新規プレイヤーのうちは進捗が速くても、Snowflakeのような位置に到達すれば速度は遅くならざるを得ない。今日システムを選ぶ立場として、現在の加速度をそのまま未来まで外挿することはできない。
それでも、「クエリから結果まで」ではなく、アイデアから答えまでどれだけ速く進めるか、という観点は別途深掘りする価値がありそうだ。
性能は「主観的」というより相対的だ。その意味は、目の前の作業と結び付いている。
ただし、素早く動くプログレスバーのように、ユーザーにより速いと感じさせるユーザーインターフェースの話をしているなら別だ。それはインターフェースの問題であって、データベースの問題ではない。
「相対的」と言うなら、システム間比較以外では性能に数字を付ける方法がないことになるが、それは事実ではない。
初期に人気を得たWebアプリは、すべての状態をPython dictに入れて、数分おきにディスクへダンプしていた。今までの人生で見た中で最速のAPIだった。
Mongoへ移したあとは、性能が二度と戻らなかった。それでも今Webサイトを作るときに「pickledb」を手に取ることはない。
fopenの代替としてはSQLiteが中間地点だ。リクエスト/レスポンス型のユーザーインタラクションにはあまり向かないが、大きな静的データや再生可能なストリーミングデータを増分またはバッチ処理する場合には、今より一般的であるべきだと思う。
「shared nothingデータベースはshared diskに比べて不利で、Redshiftが主にshared diskアーキテクチャへ移行するのに何年もかかった。オブジェクトストレージにメタデータを保存するLakehouseは高速更新が難しい」というテーマについて、良い資料を探している。
良い記事だ。過去10年間、pandasが強かった理由の1つもこれだと思う。
単一マシン性能が十分に良く、人類が知るCSVの99%を読み込めた。