データベースの物理設計について解説してみる

クラウドが普及して、データベースの物理的な設計に関して意識せずともプロダクション環境で問題なく運用できていますが、オンプレミス環境では物理設計は後から変更が難しい部分ですのでおさらいしたいと思います。


オンプレミスでの物理設計として、2つの方針があります。1つはストレージの冗長構成、もう1つは障害発生を想定したバックアップの方式です。



ストレージの冗長構成


ファイルの物理配置によってパフォーマンスが向上しますが、ストレージの冗長構成または分散構成を行うことで、さらなるパフォーマンスの向上と障害耐性を構築することができます。

ここで登場する技術が、 RAID です。



RAIDとは


RAIDとは、複数のディスクを束ねて仮想的に一つのストレージとする技術のことです。この単位でまとめられたディスクをRAIDグループと呼びます。性能の向上と冗長化に使用されます。


RAID構成を行う場合に性能と冗長化のどちらかまたは、両方が必要になるのかを検討するには、以下の3点について考慮する必要があります。


①当該データに求められる信頼性と性能の優先度

②予算的にディスクは何本用意できるか



RAIDの種類


ここでは、RAIDのレベルをいくつか解説します。


RAID0


別名、ストライピング。基本情報でも出てくる基本的なRAIDレベルです。

RAID0は、データを複数のディスクに分散してI/O性能を高める技術です。RAID0を使用すると、I/O性能はディスクの数だけ向上しますが、ディスクが一つでも故障したらデータが失われます。つまり、冗長性は全くありません。


オンプレミスでの運用で選択することはまずありません。ただ、AWSでRAIDを使用する場合、RAID0を採用して性能を向上することが推奨されています。(AWS側がデータの完全性をある程度担保してくれているからです。)

db-raid-0



RAID1


別名、ミラーリング。こちらも基本情報で出てくる基本的なRAIDレベルです。

2本のディスクに全く同じデータを持つことで、冗長性を高める技術です。2本のディスクが同時に壊れない限りデータは保全されます。ただし、データは分散されないため性能は、RAIDを使用しない場合と同じになります。また、同じデータを2本のディスクで運用するので、コストは、RAID0やRAIDを使用しない場合と比較して高くなります。

db-raid-1



RAID5


パリティ分散と呼ばれる方式です。3本以上のディスクで構築し、データとパリティと呼ばれる謝り符号訂正符号を分散して格納します。ディスクが壊れた場合、パリティからデータを復元することが可能です。1本までならどのディスクが壊れたとしてもデータを保全できます。ただし、2本以上のディスクが同時に壊れた場合は、データが失われてしまいます。また、データは分散して格納するため、ディスクI/Oは向上します。ただ、RAID0と比べると、パリティの計算を行うため書き込み性能は高くありません。(読み出し性能は同じ)

db-raid-5

上記の例だと、データ1−1、1−2のいずれかが破損した場合、ディスク3のパリティ1で復元できます。

データ2、データ3も同様にそれぞれのパリティを使用してデータを復元できます。



RAID10


RAID10またはRAID1+0と呼ばれる方式です。こちらの方式は、RAID1とRAID0を組み合わせたものです。まず、RAID1でRAIDグループを作成します。次に、RAID0によって、データを分散してディスクI/Oを向上します。この2つのRAIDを組み合わせることによって、高速かつ高信頼性を両立させます。この構成に唯一欠点があるとすると、ディスクがたくさん必要になるためコストが高くなるところです。ミッションクリティカルなシステムではこちらを採用している企業もあるようです。


余談ですが、AWSでは、推奨されていないですがRAID10の構成もできるそうです。

db-raid-10



RAID6


RAID6は、RAID5の上位版として、パリティ以外にもう1つ冗長データをディスクに分散して持つ方式です。

冗長データを2種類持つことで信頼性はRAID5よりも高い方式ですが、RAID5よりも最低必要なディスクの本数が多く、2種類の冗長データをの生成が必要なためディスクI/Oの性能はRAID5よりも劣ります。最近では、RAID10では、予算がオーバーしてしまう時の選択肢として、RAID5ではなく、RAID6を使用するプロジェクトも増えてきているそうです。

db-raid-6



どのRAIDを選ぶべきか


データベースは、ディスクI/Oと信頼性のどちらも重視しなくてはなりません。したがって、RAID10を選択するのがベストです。しかし、予算の都合がつかない場合は最低でもRAID5を選択すると良いと思います。また、最近では、RAID6の構成も採用されてきているので、RAID5よりも少しコストを増やしたRAID6を採用するのも良いと思います。


余談ですが、AWSで構成する場合は、RDSはSSDを選択するので、ディスクI/O性能は高く、AWSのバックアップの仕組み上RAID1以上のレベルで構築する必要はないと言われています。性能アップのためにRAID0を使用するケースはあるみたいですが、RAID1は、どうしても心配な場合に使用するようです。(AWS SA曰く)



ファイルの物理配置


RAIDの方式が決まったら、次はファイルをどのディスクに配置するかを考えます。

データベースを構成するファイルは、データファイル、インデックスファイル、システムファイル、一時ファイル、ログファイルの5種類です。

それぞれ以下の用途で使用します。


ファイル名 説明
データファイル テーブル上のデータ。ファイルサイズが最も大きい。
インデックスファイル テーブルのインデックスデータ。
システムファイル DBMSの管理ファイル。(特に意識する必要はない。)
一時ファイル 一時的なデータ。(サブクエリの結果などの一時的なデータを保持する。)
ログファイル データファイルへの反映前に変更分を保持して、一括で変更を行うための領域。

開発者はデータファイルとインデックスファイルを、管理者はシステムファイルと一時ファイルとログファイルを意識して開発する必要があります。



物理的なディスクの分け方


5種類のファイルは、運用時にファイルサイズの増加しやすさや参照される頻度が異なるため、ディスクを分けてパフォーマンスを上げる運用が一般的です。

データファイル、インデックスファイル、一時ファイルは、I/Oが多くなりがちなので、ディスクを分けます。

db-op-item-1


システムファイルとログファイルは、分割できるだけの予算が組まれていれば良いのですが、ない場合は、同一ディスクにしてしまってもよいと思います。

※ システムファイル、ログファイル共にファイルが増加することはないため。

db-op-item-2


上記、2パターンの分け方が基本となりますが、画像データなどの大きなバイナリファイルは、I/Oコストが非常に大きいので、他のファイル群とは別のディスクにする運用が望ましいです。


※ とはいえ、そもそもの話として、画像データをデータベースに保存するという設計自体が最近の設計では見かけないので、どうしてもデータベースで保持する必要がある時のみ考慮すると良いかと思います。



バックアップの方式


RAIDによる冗長性の向上を行ない極力データの損失が起きない設計にしてもなお、データが損失する事故は起きるものです。なので、障害が発生してしまった場合にいかにデータを復旧できるようにするのかを決めるのが、バックアップ方式の設計です。



バックアップの種類


主なバックアップの方式は、以下の通りです。


・フルバックアップ

・差分バックアップ

・増分バックアップ


基本は、3種類のバックアップ方式を組み合わせていきます。



フルバックアップ


フルという言葉通り、ある時点のデータ全てをバックアップします。

メリット、デメリットは以下の通りです。


【メリット】

1つのバックアップデータのみでその時点のデータ全てを復旧できる。

【デメリット】


バックアップを取得する時間が長く、バックアップを取得する時間を短くするにはハードウェアの性能に依存する。場合によっては、サービス停止が必要になる。

このような特性から、毎日フルバックアップを取得するような運用を行うケースは稀です。

db-bk-full



差分バックアップ


フルバックアップでは、上述したようなデメリットがありました。差分バックアップは、そのデメリットを補完するための方式です。

差分バックアップは、フルバックアップした時点のバックアップとの差分だけを毎回取得するバックアップ方式です。(フルバックアップからの差分は日毎に累積します)


【メリット】

フルバックアップのみと比べて、短い時間でのバックアップが可能になる。また、バックアップデータの量も少なくなる。

【デメリット】

フルバックアップのみと比べて、必要なファイルが増える。


db-bk-sb



増分バックアップ


差分バックアップと基本的な考え方は同じですが、こちらは、毎日の増分のみをバックアップするので、差分バックアップの累積する方式とは違い、バックアップファイルに無駄がありません。


【メリット】

フルバックアップのみ、差分バックアップと比べて、短い時間でのバックアップが可能になる。また、バックアップデータの量も少なくなる。

【デメリット】

フルバックアップのみ、差分バックアップと比べて、必要なファイルが増える。また、障害発生時点にバックアップファイルが1つでも破損していた場合、データが損失する。


db-bk-zb



どのバックアップ方式を採用するべきなのか


バックアップ方式には、それぞれメリットとデメリットがあり、バックアップコストとリカバリコストを考慮して選択する必要があります。

上述した3種類のバックアップ方式のバックアップコスト、リカバリコストの優位性は以下のようになります。


【バックアップコスト】

フルバックアップ > 差分バックアップ > 増分バックアップ

【リカバリコスト】

フルバックアップ < 差分バックアップ < 増分バックアップ


このように、バッックアップコストが高いとリカバリコストが低くなるというトレードオフの関係となっているため、以下の4点について検討をして決めると良いと思います。


・いつ時点の状態に復旧させる必要があるのか

・バックアップに使用できる時間(バックアップウィンドウ)

・リカバリに使用できる時間(リカバリウィンドウ)

・バックアップは何世代まで残すのか


4点あげましたが、週のはじめにフルバックアップを取得して、その後は差分バックアップか増分バックアップを取得するのが一般的な方式になります。



リカバリ設計


バックアップを適用するための手順がリカバリ設計になります。

ただ、バックアップ設計が決まっていれば、自動的に決まってしまうので、ざっくりと説明します。

リカバリ設計には、大きく分けて2つの手順があり、1つめはリストア、2つめはリカバリです。

リストアとは、フルバックアップで取得したデータを使用して、データベースのデータをもとに戻すことです。リカバリとは、リストアしたデータに、障害発生直前までの変更を反映することです。つまり、以下のようになります。


【リストア】

フルバックアップで取得したデータを使用して、データをもとに戻すこと。

【リカバリ】

もとに戻したデータに増分または差分バックアップで取得したトランザクションログを適用すること。



つまり、フルバックアップ方式はリストアのみ、フルバックアップ+差分または増分バップアップ方式はリストア+リカバリの手順が必要になります。



以上、オンプレミス環境エアプな私の考える設計方針でした。

arrow_back

Previous

Findy スコア60 到達しました ^ - ^

Next

Oracle Cloud 入門 - MFA、ユーザー作成、グループ作成編 -
arrow_forward