トランザクショナルデータベースとは

トランザクショナルデータベースはウェブサイトや銀行、小売店などあらゆるタイプの本番環境の運用に適しており、データの整合性を維持したまま、データ行の読み込みと書き込みを素早く実行します。

トランザクショナルデータベースは分析に特化したデータベースではありませんが、すでに本番データベースとしての環境が整っていることから、実質的な分析環境として広く利用されています。数十年前からあるため知名度が高く、アクセスが容易で、利用しやすいデータベースといえます。

独立した既存の分析スタックを持たない組織の場合は、分析を始める簡単な方法はトランザクショナルデータベースを複製することです。この方法なら、分析クエリが基幹業務の本稼働用クエリの邪魔にならず、追加のセットアップも必要ありません。ただ、これらのデータベースは分析用でなく、トランザクションの処理用というのが短所です。これらを分析に使用すると、しばらくは問題ないかもしれませんが、制限に悩まされることになり、いずれ解決策を講じる必要があります。分析に特化したデータベースではこの問題を当面は回避できます。

トランザクショナルデータベースは行のストアであり、データは列ではなく行としてディスクに保存されます。これは、ユーザーテーブルから必要なデータのみを取得できるため、顧客一社のデータをすべて把握したい場合などに便利です。しかし、特定の郵便番号に該当する顧客の数を計上する場合は、「郵便番号」の列だけでなく、name(氏名)、address(住所)、user_id(ユーザーID)の列も読み込まなければならず最適とは言えません。

トランザクショナルデータベースが実際に役立つ事例

データの完全性を確保

トランザクショナルデータベースはACIDに適合する設計のため、データベースへの書き込みはまとめて成功するか失敗するかのどちらかです。これにより、データベースへの書き込みの際にデータの完全性が高く保たれます。このことから、トランザクショナルデータベースは、高度なデータの完全性が求められるビジネストランザクションに不可欠です(説得力のある例としてバンキングがあります。ある口座からの出金と別の口座への入金が1件のトランザクションとして処理され、結果は成功か失敗のどちらかでなければなりません)。

レイテンシの低さ

トランザクショナルデータベースは本稼働システムで運用するために設計されており、ミリ秒単位で完了する必要がある処理に非常に長けています。本稼働用データベースのトランザクションの複製に対して分析を実行する場合、複製はマスターデータベースとほぼ同期することになります(レイテンシ1秒未満など)。

稼働システムの監視

トランザクショナルデータベースを分析に使用するぴったりの事例を挙げるなら、トランザクショナルデータベースからのデータを使った業務に関するリアルタイムのスナップショットの作成でしょう。複製によって発生するレイテンシがほとんどないというのがその理由です。サポートのワークロードや在庫、別の運用システムを監視しながら、できるだけ最新のデータに基づいて意思決定を下す必要がある場合、本稼働データベースの複製が最適なチョイスと言えるでしょう。

代表的なトランザクショナルデータベース

アーキテクチャ

行ストア

トランザクショナルデータベースは行ストアです。データの各行が全体として保存されますが、これはユーザーがデータの記録を読み込む際にその記録についてすべてのデータを取得するだろうという前提に基づいています。トランザクショナルデータベースにクエリを実行すると、それぞれのデータ行全体がスキャンされ、データベースクエリによって選択された列だけが表示されます。

これとは対照的に、分析データウェアハウスは列ストアで各フィールドが個別に保存されます。このため、分析データウェアハウスはデータの読み込みに特化して最適化されますが、データの書き込みについてはそうなりません。この理由は、分析データベースへの書き込みでは複数の列にわたって同時に書き込む必要があるからです。

しかし、分析データベースは一般的に、集約の実行において効率とスピードがより優れているとも言えます。トランザクショナルデータベースからのデータセットに集約を実行する場合、集約する前にすべての行をひとつずつスキャンすることになります。集約する列だけをスキャンする方が効率が良く、分析データウェアハウスはより複雑な分析に向いています。

データ量の少ない企業にとってはこの問題は気にならないかもしれませんが、利用可能なデータの量が増えるにつれて、こうした違いはより明確になってきます。

ACIDトランザクション

ACIDは、データベースへの書き込みの完全性を守るためにトランザクショナルデータベースがどう設計されているかを説明する、一連の特性です。

特性 説明
アトミック性 トランザクションのごく一部が失敗しても、全体が失敗することになります。このため、データベースに問題なくコミットするためには、すべてのトランザクションが100%成功しなければなりません。
一貫性 トランザクションはデータベースに書き込まれるか(データベースがある有効な状態から別の状態に移行)、それ以外の場合は元の状態に戻されます。
独立性 完了していないトランザクションを、他のトランザクションによって処理したり修正することはできません。
耐久性 トランザクションが一度データベースに書き込まれると、データベース障害が発生してもデータベース内に残ります。

以下は、トランザクショナルデータベースの設計の機能としてACIDの重要性を示す一例です。航空券の予約手続きを進めている人が2人いるとします。

Aは1名分の座席を、Bはいくつかの座席を同時に予約しようとしています。

  • アトミック性 - Aがトランザクションを無事に終えたとき、Bのトランザクションは座席の1つがすでに予約確定済みのため失敗します。
  • 一貫性 - AとBは同じ座席のチケットを同時に購入することはできません。
  • 独立性 - Bのトランザクションは、Aのトランザクションが完全に問題なくデータベースに書き込まれた場合にのみキャンセルされます。
  • 耐久性 - Aが座席の予約を済ませた後にデータベースに障害が発生した場合でも、Aは空港でチケットを手にすることができます。

データスタック内のロケーション

トランザクショナルデータベースを分析サービスに使用する場合、それらはたいてい本稼働用データベースを複製したものとして構成されます。この構成は広範囲にわたって文書化されており、データベース管理者やエンジニアが設定のために利用しやすくなっています。

クラウドデータベースベンダーは、複製をプロビジョニングする簡単な方法をいくつか用意しています。本稼働用データベースで直接分析を実行するよりも、この方法をお勧めします。その理由は、分析のクエリは多大なリソースを消費し、データの書き込みに集中すべき本稼働用データベースのパフォーマンスを低下させる可能性があるためです。ほとんどの場合、複製されたデータベースと本稼働用データベースにはせいぜい数秒の違いしかありません。

制約

トランザクショナルデータベースの分析に自社の本稼働用データベースの複製を使用する場合、複製にデータを一切書き込めないこともあります。その理由は、複製の役割は本稼働用データベースをそっくり反映することで、複製に実行される書き込みはマスターデータベースに反映されないからです。

これには例外もあり、複製したデータベースの一部を書き込み可能にすることもできますが、検討に値する制約です。また、特定の処理がより複雑になることがあります。

最適化

分離レベル

トランザクショナルデータベースを分析用に最適化する場合に最も容易に解決ができる問題とは、分離のレベルを下げることです。分離レベルによってテーブルを「ロック」する処理の種類が決まります。つまり、分離を抑えることで複製の遅延が短くなり、データベースによるロック条件の利用が控えめになります。こうした設定は読み取り専用の複製でのみ変更するため、安全と言えます。

インデックスの作成

トランザクショナルデータベースのパフォーマンスを強化する最も優れた方法は、有効なインデックスを作成することです。その名の通りインデックスとは索引で、データベースで指定した列を並び替えてディスク上でどこにどの行があるかすぐに分かるようにします。結合されたテーブルの外部キーおよび時系列になったテーブルのタイムスタンプにインデックスを作成すると、JOINでスキャンされる行数が少なくなり、分析クエリのパフォーマンスが大幅に向上します。

インデックス作成の唯一の短所は、インデックスはディスク容量を消費することです。そのため、インデックスを作成する賢明な方法は、容量を使い切らずにパフォーマンスを高速化できるようバランスを見極めることです。

冗長性の低減

また、データの冗長性を抑えることは、テーブルを読み込む際のパフォーマンス向上につながります。その代表的な方法が第3正規形でのデータの保存です。こうすることで一般的に読み取る行の範囲を格段に小さくし、データのあまり使わない部分を独立したテーブルに移動します。そして、必要なときにだけJOINでそれらを結合します。

データ行列

また、スパース行列があるかどうかでパフォーマンスに大きな違いが出ます。スパース行列を持つ最も一般的なデータベースと言えば、診療記録、サーバーのログ、非構造化データのコレクションなどです。列指向のデータベースのコアは、スパース行列を扱えるよう設計されています。

行ストアを使用する際には、回避策が少なくともひとつは必要になります。これに対処するひとつの方法が、テーブル内の列を断片化してテーブルの数を増やすことです。この方法ならクエリごとに使用する列を減らすことができます。また、entity-attribute-value(EAV)スキーマを作成すると、極端なスパース行列がある場合に役立つでしょう。ただし、この方法では分析クエリがより複雑になります。Lookerのような堅牢なモデリングレイヤーを備えたツールなら、こうした方法に対応できます。逆に、すべてのSQLをゼロから記述すると手間が相当かかります。

データ変換

クエリを最適化するもうひとつの優れた方法は、クエリを実行する前にSQLで高価な計算を実行することです。データ変換を使用して未処理の行を処理して集約したデータを作成するか、事前にDISTINCTを実行すれば、クエリの処理速度が格段に上がります。この方法の主な短所は、データをロールアップすると分解能が低下し、新しいデータが追加されるたびにメンテナンスと更新が継続的に必要になる点です。

アナリティクスを快適に

ビジネスインテリジェンス、ビッグデータ分析、顧客の360°ビュー。
Lookerはお客様のどんなニーズにもお応えします。当社のデータエキスパートにご相談ください。

デモをリクエスト