Cloudflare の D1 データベースサービスは、本番環境で導入した開発者から大きな批判を受けています。多くの開発者が最適化の試みにもかかわらず、一貫して低いパフォーマンスを報告しています。最近の記事では D1 データベースクエリを最適化するための様々な手法が詳細に説明されましたが、コミュニティからのフィードバックによると、これらの最適化は基本的なアーキテクチャの制限を克服するには不十分であるかもしれません。
グローバルパフォーマンスの問題
複数の地域の開発者が Cloudflare D1 で一貫して遅いレスポンスタイムを報告しており、単純なクエリでも通常200〜400ミリ秒以上の時間がかかっています。このパフォーマンスの問題はヨーロッパ以外で特に顕著であり、北米ではレスポンスタイムが500ミリ秒以上に急増することもあるとの報告もあります。Cloudflare のネットワークのグローバル分散は通常、他の製品では強みとなっていますが、D1 のアーキテクチャ上の制約（データベースが単一のプライマリリージョンに保存され、多くの操作でデータセンター間の通信が必要）を克服できていないようです。
数ヶ月前にあるプロジェクトで D1 を評価しましたが、グローバルなパフォーマンスがひどいことがわかりました。彼らのアーキテクチャの正確な問題点はわかりませんが、ファーストバイトまでの時間を見ると、D1 のデモデータベースでさえヨーロッパ以外の数値は悲惨で、ヨーロッパ内でも TTFB が 200ミリ秒以上というのはあまり良くありません。「
開発者から報告されたD1のパフォーマンス問題:
- 単純なクエリが定期的に200〜400ms以上かかる
- 北米ではレスポンス時間が500ms以上にスパイクする
- CF Workers + D1を使用した場合のクエリレスポンス時間は300〜3000msの範囲
- CF Workers + ホスト型 PostgreSQL の場合は50〜100msの範囲と比較して遅い
特定されたアーキテクチャの制限:
- データベースはすべての書き込みに対して単一のプライマリリージョンに保存される
- コールドスタートには接続確立が必要
- キャッシュミスの場合はプライマリリージョンからのフェッチが必要
- 書き込み同時実行性が制限された SQLite 上に構築されている
- プライマリからエッジへのアクティブな結果キャッシングの欠如
アーキテクチャの制限
複数の開発者が D1 のパフォーマンス問題に寄与する可能性のある特定のアーキテクチャ特性を特定しています。これには、すべての書き込みが処理されなければならない単一のプライマリリージョンにデータベースが保存されていること、接続確立のオーバーヘッドを含むコールドスタート、ローカルレプリカでのキャッシュミスによるプライマリリージョンからのデータ取得の必要性などが含まれます。さらに、D1 は SQLite 上に構築されており、分散環境での書き込み同時実行性に関する既知の制限があります。プライマリリージョンからエッジロケーションへのアクティブな結果キャッシングの欠如も、これらの問題を悪化させています。
最適化テクニックと根本的な問題
元の記事では、バッチリクエストの使用、更新操作からの ID の除外、フルテーブルスキャンの回避、マルチテーブル結合の分割、複数レコード挿入の最適化など、いくつかの最適化テクニックが詳細に説明されていました。これらのテクニックは行の読み取りを減らしクエリ効率を向上させるのに役立つかもしれませんが、コミュニティのフィードバックによると、それらは核心的な遅延問題に対処していないようです。多くの開発者は、同様の最適化を実装した後でも、本番アプリケーションにとって応答時間が許容できないほど高いままであると報告しています。
推奨される D1 最適化テクニック:
- 複数のデータベース操作にはバッチ操作を使用する
- 更新操作からIDフィールドを除外する
- カウントクエリに対するフルテーブルスキャンを避ける
- 複数テーブルの結合を個別のクエリに分割する
- 大量操作には分割された複数レコード挿入を使用する
- わずかなパフォーマンス向上のために Smart Placement を有効にする
D1 に適したユースケース:
- 5つ未満のテーブルと最小限の JOIN を持つ小規模プロジェクト
- ページ訪問者カウント
- メーリングリスト
- ウェブサイトのページビュー追跡
- 積極的なキャッシングを伴う高読み取り・低書き込みシナリオ
限定的なユースケース
パフォーマンスの制約を考えると、開発者は D1 の実用的なアプリケーションが当初期待されていたよりも限定的であることに気づいています。一部の開発者は、積極的なキャッシングを備えた高読み取り・低書き込みアプリケーション、または関係の複雑さが限られた非常に小規模なプロジェクトなど、特定のシナリオにのみ適している可能性があると示唆しています。複数のユーザーが、D1 は複雑な結合が不要でテーブルサイズが控えめな、ページ訪問者数、メーリングリスト、ウェブサイトのページビュー追跡などの単純なユースケースに最適であると述べています。
代替案と比較
D1 を評価した多くの開発者は最終的に代替ソリューションを選択しました。いくつかのコメンターは、従来のホスト型 PostgreSQL データベースを使用した Cloudflare Workers で大幅に優れたパフォーマンスを達成し、D1 の 300〜3000ミリ秒と比較して 50〜100ミリ秒のクエリ応答を報告しています。他の人々は、真のデータベース機能を必要とするアプリケーションでは、従来のデータベースソリューションの初期コストが高くても、サーバーレスの落とし穴や予測不可能な請求に対処するために費やされるエンジニアリング時間の削減によって相殺される可能性があると示唆しています。
スマートプレイスメントと将来の改善
一部のユーザーは、ワーカー実行場所を最適化しようとする Cloudflare の Smart Placement 機能を有効にした後、パフォーマンスがわずかに向上したと報告しています。しかし、この機能を有効にしても、多くの人はまだ本番アプリケーションにとってパフォーマンスが不十分であると感じています。一部の開発者は、現在の実装がパフォーマンス最適化よりも市場投入までの時間を優先している可能性があることを示唆し、D1 のパフォーマンス問題が将来のアップデートで対処される可能性があるという希望を表明しています。
結論として、Cloudflare D1 は Workers プラットフォームと統合された魅力的なサーバーレスデータベースオプションを提供していますが、現在のパフォーマンス制限は、多くの開発者が本番アプリケーションで他のソリューションを検討するほど重大であるようです。記事で詳述されている最適化テクニックは効率を向上させるのに役立つかもしれませんが、遅延問題を引き起こす根本的なアーキテクチャ上の制約に対処しているようには見えません。現時点では、D1 はパフォーマンス要件が控えめでデータベースの複雑さが限られている特定のユースケースに最適であると思われます。