Perfだけでは不十分

データベースの性能偏重文化

• データベース業界は性能向上に注力しているが、実際のユーザー体験はしばしば別の要素に左右される。
• ユーザーがデータを処理するうえで本当に重要なのは、クエリ最適化よりも、データの形式やSQLで質問を組み立てる能力かもしれない。
• データベースの性能は重要だが、使いやすさ、エコシステム、更新速度、ワークフローとの統合性など、ほかの要素を基準にデータベースを選ぶほうがよい場合がある。

ベンチマーク戦争の終焉

• 2019年にGigaOmがクラウドデータウェアハウスを比較するベンチマークを発表したが、実際の市場の結果はそれとは異なる様相を示した。
• ベンチマーク結果がユーザー体験と一致しないなら、ベンチマークが間違っているか、間違ったものを測っているか、あるいは性能がそれほど重要ではない可能性を示している。

速さの意味

• クラウドデータベース分野では、ユーザーが「実行」ボタンをクリックしてから結果が準備されるまでの時間に注目しがちである。
• 実際にユーザーへ影響するのは作業を完了するまでにかかる時間であり、それはデータベースサーバー時間と同じではない。

性能は主観的である

• 性能はユーザーの視点から測定されるべきであり、UXの問題であるため単一の数値では説明できない。
• 性能の主観性とは、どちらが速いかはデータベースがどう使われるかによって決まることを意味する。

変化の速度

• DuckDBは高速なペースで改善されており、そのため現在のベンチマークは無意味になりうる。
• データベースを選ぶ際には、現在の性能だけでなく、将来の性能や機能の変化も重要な変数である。

魔法の豆はない

• すべてのデータベースが活発に保守されているなら、性能は時間とともに収束していくはずである。
• 重要な性能差は、時間が経つにつれて持続しない可能性が高い。

問題は椅子とキーボードの間、キーボードとデータベースの間にある

• ユーザーにとって重要な性能指標は、問いを持ってから答えを得るまでにかかる時間である。
• データベースがクエリを実行する時間ではなく、アイデアから答えに到達するまでの速さこそが重要な機能である。

酸っぱいブドウについて

• DuckDBは現在、ClickBenchとh20.aiのベンチマークで上位に位置しており、TPC-HとTPC-DSでも悪くない性能を示している。
• データベースが速いと決めつける前に、実際のワークロードで試してみることが重要である。

結論

• 最も成功したデータベース企業は、競合他社より速い性能によって成功したわけではない。
• 性能を主要な売り文句にしたデータベースは、市場で成功してこなかった。
• データベースを選ぶときは、生の速さ以外の要素を基準に判断するほうがよいと勧めている。

GN⁺の見解

• この記事は、データベースの性能だけに焦点を当てるのではなく、ユーザー体験と作業フローを最適化することが重要だと強調している。これは初級ソフトウェアエンジニアにとっても、データベースを選ぶ際に単純な性能指標よりユーザー中心のアプローチを考慮すべきだという重要な教訓を与えている。
• データベースの性能は時間とともに収束する傾向があり、これは技術の進歩があらゆるプラットフォームへ広がるためである。これは技術選定の際、短期的な性能より長期的なサポートと改善の可能性を考慮すべきことを示唆している。
• DuckDBのようなオープンソースプロジェクトは、速い改善速度とコミュニティの支援を土台に急速に発展できる。これは新しい技術を導入する際、コミュニティの活発さとプロジェクトの発展速度を考慮すべきことを意味する。
• データベース選定では性能ベンチマークの結果だけに依存せず、実際のワークロードで性能を試すことが重要である。これは実際のユースケースにより適したデータベースを選ぶ助けになる。
• データベース技術の選択では、単なる技術的側面だけでなく、ビジネス要件、保守のしやすさ、データ処理の効率性など、多様な要素を考慮すべきであることを強調している。

[GN⁺]

Hacker Newsの意見

• 顧客からの不満が多かった数年後、JDBCドライバのバグが性能を低下させていたことに気づいた。 多くのエンジニアの時間をクエリ速度の改善に費やしたが、ほとんどのユーザーが使っているコネクタが、その節約した時間をはるかに上回る遅延を追加していた。しかも、その事実をまったく認識していなかった。Google社内では誰もJDBCドライバを使っていなかったため、ユーザーが体験するクエリ時間を見ることができず、それを他人の問題として扱っていた。

  • このコメントは、Googleが顧客の不満に対して「完全に盲目」だったことと、自社製品を自分たちで使っていない点に失望を示している。JDBCのくだりが特に印象的だ。
• Googleは内部的にはよく動くデータベースを構築したが、外の世界向けのアダプタ層を外注で作り、それがまともに機能しなかったため、外部の世界は出来の悪いデータベースを使わされることになった。 Googleが使う洗練された中核は不完全なアダプタに囲まれており、全体として不必要にひどい成果物になっている。内部ではそれを認識できず、外部の人々にはそれを把握しにくい。
  • このコメントは、Googleのオープンソース戦略にも非常によく当てはまると評価している。
• ブログが「性能は主観的」と主張しているのは奇妙だと思う。 性能は単に測定するだけでは十分ではないが、ここで示されている唯一の例では、性能は重要で客観的だ。単に間違ったものを測っていただけだ。
  • このコメントは、性能測定に関するブログの主張に疑問を呈している。
• これは会社組織の問題のように聞こえる。 顧客にクラウドを使ってもらい価値を提供することが最終目標なら、顧客が重要だと考えるものと異なるメトリクスを持つべきではない。Google社内には、顧客の問題を積極的に聞き、それをエンジニアに伝えて何を改善すべきか示す人がいるべきだ。
  • このコメントは、Googleが顧客の要件を理解し、それを改善するための組織構造の必要性を強調している。
• シアトルの家からサンフランシスコのオフィスまで、ドアツードアで約4.5時間かかる。
  • このコメントは、創業者たちがもはや以前のようなスピードで動いていないことを指摘し、それは連邦準備制度理事会が金利を上げたせいかもしれないと冗談めかして述べている。
• 性能は、ここで言われているような意味で二次的だとは思わない。 性能が十分に良いことを確認してから、他のすべてを評価すべきだ。著者自身も「DuckDBは速い」と述べている。そうでなければ性能競争をしなければならないだろう。
  • このコメントは、性能が二次的だという主張に同意せず、性能が十分に良いかを確認することが先決だと主張している。
• 性能は「主観的」ではなく「相対的」だ。 その意味は、何を実行しているかに関係している。
  • このコメントは、性能の相対性について説明し、ユーザーインターフェース設計に関連する性能の感じ方とは区別している。
• 最初の人気Webアプリは、すべての状態をPythonのdictに保存し、数分ごとにディスクへダンプしていた。 非常に高速なAPIだったが、MongoDBに移行したときには性能が戻らなかった。それでも、今日Webサイトを作るときに pickledb を選ぶことはない。
  • このコメントは、初期のWebアプリの性能と、データベース移行後の性能低下の経験を共有している。
• 独自のデータベースシステムを構築し、他の人気データベース（Postgres、Sqlite、MySQL、SQL Server）との性能ベンチマークを行いたい。
  • このコメントは、ユーザーが「実行ボタン」を押してから画面に結果が表示されるまでの時間まで測定し、さまざまなクエリにわたって自分のデータベースのほうが速くなるまで満足しなかったと説明している。
• 「もちろん、このルールには例外があり、それはアーキテクチャの違いを克服するのが難しいということだ。 shared nothingデータベースはshared diskに対して不利であり、Redshiftが主にshared diskアーキテクチャへ移行するのに何年もかかった。オブジェクトストアにメタデータを永続化するレイクハウスは、高速な更新に苦労するだろう。これはモデルに内在している。」
  • このコメントは、データベースアーキテクチャの違いに関連する問題点を指摘し、このテーマに関する良い文献を探していると述べている。