プログラミングマガジン

プログラミングを中心にIT技術をできるだけわかりやすくまとめます。

  • ホーム
  • データベース
  • 【データベース設計】ストレージの冗長構成(RAID)の決定(物理設計)
 
 
     
  • サーバー言語  
    • Python
    • Ruby
    • PHP
    • SQL
  •  
  • インフラ  
       
    • AWS
    •  
    • 基本
    • Git
  • Web
       
    • Web開発
    • JavaScript
    • Vue.js
    • React
  •  
  • 設計  
       
    • 実装設計
    • DB設計
  • 問い合わせ
  

【データベース設計】ストレージの冗長構成(RAID)の決定(物理設計)

04.29

  • miyabisan2
  • 4件のコメント

この記事は2分で読めます

データベースのデータを保持する記憶媒体としては、HDD(ハードディスクドライブ)を使うのが一般的です。

格納するデータは、業務において非常に重要度が高いデータなので、耐障害性をあげる必要があります。

そのための技術として用意されているのが「RAID(Redundant Array of Independent Disks)」になります。

RAIDとは?

複数ディスクを束ねて、仮想的な一つのストレージとする技術のことです。

RAIDの基本的な考え方

同じデータを複数ディスクに書き込むことによって冗長化することで、安全性を高めること。

RAIDのメリット

  • 安全性の向上
  • 性能の向上

RAID構築の流れ

下記のことを考えて、設計します。

どのRAIDレベルを採用するか。

RAID0(ストライピング)

引用:http://www.programering.com/a/MzN0EDMwATE.html

複数のディスクにデータを分散します。ディスクのうち一本でも故障すると破綻するので、「RAIDとして欠陥がある」と述べる人もいます。

冗長性は全くありませんが、ディスクを分散することにより、ディスクI/Oの性能がかなり高いのが特徴です。

RAID1(ミラーリング)

引用:http://www.programering.com/a/MzN0EDMwATE.html

2本のディスクに全く同じデータを書き込むので、信頼性が高くなります。

ただ、性能は1本の時と変わらないですし、ディスクの使用効率もあまりよくないです。

RAID5(パリティ分散)

引用:http://www.programering.com/a/MzN0EDMwATE.html

最低3本以上のディスクが必要になります。

「パリティ」と呼ばれる誤り訂正符号を分散して格納します。

「パリティ」から実データを復元できるので、1本までなら壊れても復元可能です。ただ、2本以上壊れると復元できません。

さらに、データを分散することができるため、ディスクI/Oの性能も向上させることができます。

ネックとしては、ディスクをたくさん用意しないといけないので、RAID0、1に比べるとコストがかかることでしょう。

RAID10(RAID1 + 0):ミラーリング+ストライピング

引用:http://www.programering.com/a/MzN0EDMwATE.html

「RAID0」と「RAID1」を組み合わせたものになります。

最初に、RAID1のグループを作って、さらにそのグループの中で、RAID0をさせます。

なので、RAID0の速度と、RAID1の安全性のいいところをもくろんだ手法となります。

ただ、最低4本のディスクが必要になるので、一番コストは高くなってしまいます。

上記にあげたRAID以外も、レベルが存在しますが、あまり実務では利用されないので割愛します。

どのRAIDを選ぶか?

まず、検討の余地にあがるのは、「RAID10」でしょう。ただ、コストがかかってしまうので、財布との相談ですが、余裕がなければ、「RAID5」になるでしょう。

全くお金に余裕がなければ、安全性の高い「RAID1」もありです。「RAID0」は、耐障害性に乏しいので採用されません。

RAID選定における優先度

RAID10 → RAID5 → RAID1
スポンサーリンク
  • 2018 04.29
  • miyabisan2
  • 4件のコメント
  • インフラ, データベース
  • Tweets Twitter
  • このエントリーをはてなブックマークに追加
  • LINEで送る

関連記事

  1. 2018 04.30

    【SQL】内部処理の仕組み(Oracle)

  2. 2020 12.13

    【データベース】「顧客テーブル」のテーブル設計

  3. 2020 12.12

    【データベース】バッチ処理の排他制御

  4. 2020 06.11

    【インフラ】「ドメイン」、お名前.comでのドメインの購入

  5. 2020 09.29

    【インフラ】「ロードバランサー(負荷分散装置)」について

  6. 2021 09.26

    【データベース】テーブル設計:「削除フラグの闇」について

  • コメント ( 0 )
  • トラックバック ( 0 )
  1. この記事へのコメントはありません。

  1. この記事へのトラックバックはありません。

返信をキャンセルする。

【データベース設計】ハードウェアのサイジング(容量と性…

【データベース設計】物理的なファイル配置の検討(物理設…

RETURN TOP

著者プロフィール

エンジニア歴10年で過去に業務系、Webデザイン、インフラ系なども経験あります。現在はWeb系でフロントエンド開発中心です。

詳細なプロフィールはこちら

スポンサーリンク

カテゴリー

  • Android
  • AngularJS
  • API
  • AWS
  • C++
  • CSS
  • cursor
  • C言語
  • DDD
  • DevOps
  • Django
  • Docker
  • Figma
  • Git
  • GitLab
  • GraphQL
  • gRPC
  • Hasura
  • Java
  • JavaScript
  • Kubernetes
  • Laravel
  • linux
  • MySQL
  • Next.js
  • nginx
  • Node.js
  • NoSQL
  • Nuxt.js
  • Oracle
  • PHP
  • Python
  • React
  • Redux
  • Rspec
  • Ruby
  • Ruby on Rails
  • Sass
  • Spring Framework
  • SQL
  • TypeScript
  • Unity
  • Vue.js
  • Webサービス開発
  • Webデザイン
  • Web技術
  • インフラ
  • オブジェクト指向
  • システム開発
  • セキュリティ
  • その他
  • データベース
  • デザインパターン
  • テスト
  • ネットワーク
  • プログラミング全般
  • マイクロサービス
  • マイクロソフト系技術
  • マルチメディア
  • リファクタリング
  • 副業
  • 未分類
  • 業務知識
  • 生成AI
  • 設計
  • 関数型言語
RETURN TOP

Copyright ©  プログラミングマガジン | プライバシーポリシー