データベーススキーマ:CQRSへの読み書き分離

クズども · 掲載地 2020/05/04 9:58:50

読み書き分離

企業の事業が拡大し、ユーザー数が大幅に増加すると、元のデータベースは維持できない可能性が高いです。それなら、はい

スケールインはハードウェアの性能を拡張しますが、ユーザー数は今後も増え続け、その性能向上はすぐに消費されるでしょう。
読み書き分離:データベースは耐えられず、読み書きが多すぎて、特に過去24時間で人気の製品のように複雑なクエリがある場合はなおさらです。非常に複雑なSQL文が必要で、もちろん実行も遅いです。

しかし、読み書きを分離するためには、データベースをマスターライブラリとスレーブライブラリに分割する必要があります。

市場に出回っている主要なリレーショナルデータベースはデータレプリケーションをサポートしているため、データベースをマスターとスレーブの2つの役割に分け、マスターサーバーに書き込み操作を行い、マスターサーバーを他のスレーブサーバーと同期させることができます。

読み取り操作やデータ解析などのオフライン操作はスレーブサーバー上で行われます。

インターネット上の多くのアプリケーションが読み込まれているため、複数のスレーブが負荷を分担し、データの可用性と正確性を保証できることがわかっています。

ただし、対応する元のアプリケーションコードも修正が必要であり、データを書き込む際にマスターライブラリを使い、データを読み込む際にはスレーブライブラリを使うように変更しなければなりません。これは書き換えに相当します。

複素クエリ

しかし、コードを書き直した後でも、複雑なクエリが多すぎてパフォーマンスが大きく向上しなかったこと、そしてデータベースのコンポーネントでジョインは非常にパフォーマンスを多く消費すると述べています。

では、過去24時間の人気商品を別のテーブルで保存できて、簡単なSQLだけで済みますか?

言い換えれば、単一のデータベーステーブルセットはレポート、検索、トランザクションなど異なる動作には適していません。

現在のテーブルはデータの追加や修正を目的としており、複雑なクエリには適していません。

しかし同時に、このクエリベースがどのように更新されるか、この遅延に耐えられるか、リアルタイムで更新されないかどうかも考慮する必要があります。

CQRS

遅延が許容できるかどうかは、ビジネスの観点から考える必要があります。例えば、過去24時間の人気商品などです。少し古い情報は大きな影響を与えず、最終的な一貫性だけが求められます。

CQRS(コマンドクエリ責任分離)を用い、つまりコマンドを追加・変更するためのコマンドをクエリ責任から分離する方法です。

CQRSでは、読み取り(クエリ)と書き込み(コマンド)を分離することに重点が置かれています。ユーザーが読むデータは通常古いため、データベースから読む必要がなく、直接読み取りデータソースを確立できます。キャッシュでも、XML、JSONでも構いません。

先ほど述べたアップデートの問題をどう解決すればいいですか? イベント、つまりイベントを使うことができます。例えば、製品が売れた際に、元のRead Modelを変更するイベントを公開できます。

このようにして、同期はイベントメカニズムを通じて非同期となります。

最後に、この方法は複雑なクエリにのみ最適であり、元の単純なクエリはリレーショナルデータベースで取得されます。なぜでしょうか。新技術の導入には価格が必要であり、同期突然変異ステップやイベントメカニズムなどがあるため、新技術の利点だけを見ることはできず、欠点は見られません。

[出典] データベーススキーマ:CQRSへの読み書き分離

関連記事

閲覧したセクション