はじめに
今回はストレージやメモリー内に格納されるデータの物理レイアウトの最適化について説明します。データベースに格納されるデータは論理的には多次元の構造を持っていますが、ストレージやメモリーのアドレスは1次元であらわされるため内部的には1次元に畳み込まれて格納されます。オンライン・トランザクション処理と分析・集計処理はデータへのアクセスの性質が異なるため、それぞれに適したデータの物理レイアウトがあります。これらを両立させる方法はあるのでしょうか。もし両立させる方法があれば、オンライン・トランザクション処理用データベースから分析・集計処理用データベースに大量のデータを移動させないという設計の選択肢ができます。
なお、本連載で例として挙げるデータベースはオラクルが提供しているものが多いですが、オラクル製品を使っていない方にも参考にしていただけるように解説していきます。
対象読者
この連載では以下の読者を想定しています。
- データ資産を活用する、新しいアプリケーションの構想や設計を担われる方
- データ基盤の運用を担われている方や、今後検討される方
- 新たに開発するアプリケーションの、最適なデータベースをお探しの方
- 目的別データベースから、価値ある情報を素早く引き出す検討をされている方
データへのアクセスの性質
一般的に、データベースのデータ構造はリレーショナル表やJSONのように多次元や入れ子の構造を持っており、クエリー言語は1次元のアドレス指定ではデータにアクセスしません。しかしストレージやメモリーのアドレスは1次元であらわされるため、クエリー言語によるデータへのアクセスは内部的には物理格納領域の1次元のアドレスを飛び飛びでアクセスすることになります。
まず、オンライン・トランザクション処理と分析・集計処理のデータへのアクセスの性質を見ていきましょう。
オンライン・トランザクション処理は商品の注文など1つの処理で少数の行の多数の列をINSERTやSELECTする傾向があります。1行のデータをまとめて取得するため行指向のアクセス・パターンになります。
これに対し分析・集計処理は金額列の合計などを計算するため、多数の行の少数の列をSELECTする傾向があります。1列のデータをまとめて取得するため列指向のアクセス・パターンになります。
データの物理レイアウト
ストレージやメモリーのアドレスは1次元であらわされますが、データベースのデータ構造は多次元になっています。多次元のデータを1次元のストレージやメモリーに格納するには、どの次元を連続配置するかによってアクセス時間が変わってきます。
一般的に、複数の要素を取得する場合は物理格納領域に連続して配置されている方がアクセス時間は短くなるため、行指向アクセスと列指向アクセスで最適な物理レイアウトは異なるものになります。行指向アクセスに適しているのは1行を連続配置する行指向レイアウトであり、列指向アクセスに適しているのは1列を連続配置する列指向レイアウトです。アクセス・パターンと物理レイアウトが合致していないと、ストレージやメモリーのアドレスを飛び飛びにアクセスすることになります。
