基礎知識

データベースの種類と選び方。RDBとNoSQLの違いを解説

データベースには多くの種類があり、選び方が分かりにくい領域です。この記事では、大きな分類から製品ごとの特徴、選定の基準までを順に整理します。

大きく2つに分かれる

データベースは、構造の持ち方で2つに大別されます。

リレーショナルデータベース（RDB）。表の形でデータを持ちます。行と列があり、表と表を関連づけられます。操作にはSQLを使います。

それ以外（NoSQL）。表に収まらない形でデータを持ちます。文書の形、鍵と値の対、グラフ構造など、目的に応じた方式があります。

どちらが優れているという話ではありません。正確性が求められる取引記録はRDB、大量の書き込みや構造が変わりやすいデータはNoSQL、という使い分けが一般的です。

実務では併用されることが多いのが実情です。基幹のデータはRDB、ログや一時的なデータは別方式、という構成になります。

主なRDB製品

表形式のデータベースには、代表的な選択肢があります。

• PostgreSQL／機能が豊富で標準への準拠度が高い。無償で使える。近年の新規採用で最も多い
• MySQL／Webサービスで長く使われてきた。導入例と情報が豊富
• Oracle Database／商用製品。大規模な基幹システムで実績がある
• SQL Server／Microsoft製。Windows環境やAzureとの相性がよい
• SQLite／軽量。アプリの内部やスマートフォンで使われる

基本的なSQLはどれでも共通です。細部の記法や機能に差はありますが、1つ覚えれば他への移行は容易になります。

選定では、費用、既存システムとの関係、必要な機能、運用体制が判断材料になります。

NoSQLの種類

表に収まらないデータを扱う方式も、目的別に分かれます。

文書型。柔軟な構造のデータをそのまま保存できます。項目が一定でないデータに向きます。MongoDBが代表例です。

鍵と値の型。単純な対応関係を高速に読み書きします。一時的な保存や、頻繁にアクセスされるデータの保持に使われます。Redisが代表例です。

列指向型。大量のデータを集計する処理に強い方式です。分析基盤で使われます。

グラフ型。関係性そのものを扱います。人と人のつながり、部品の構成など、経路をたどる処理に向きます。

いずれも万能ではありません。目的に合わないものを選ぶと、かえって扱いにくくなります。

選び方の基準

実務での判断基準を整理します。

• データの構造は決まっているか／決まっているならRDB。変わりやすいなら文書型
• 正確性が最優先か／金額や在庫を扱うならRDB
• 読み書きの量は／極端に多い場合、NoSQLの選択肢が出てくる
• 集計と分析が中心か／列指向型や分析基盤向けの製品
• 運用できる体制はあるか／珍しい製品を選ぶと、扱える人がいなくなる

最後の点が実務では重要です。技術的に最適でも、運用や引き継ぎができなければ選ぶべきではありません。迷ったらPostgreSQLかMySQLという判断は、多くの場合で妥当です。

クラウドでの選択肢

近年は、クラウド事業者が提供する形が主流になっています。

マネージドサービス。データベースの運用を事業者が担います。バックアップ、更新、障害時の切り替えを任せられます。

利点は運用負担の軽減です。自前で機器を持ち、監視し、更新する作業が不要になります。

分析専用の基盤も広く使われます。BigQuery、Snowflake、Redshiftなど、大量のデータを集計することに特化した製品です。

業務用と分析用を分ける構成が一般的になっています。日々の処理は業務用のデータベース、集計は分析基盤へ複製して実行する形です。

設計で問われること

製品の選定より、実は設計のほうが結果を左右します。

表の分け方。何をひとつの表にまとめ、何を分けるか。後から変えるのが最も難しい部分です。

索引の設計。検索を速くする仕組みですが、多すぎると書き込みが遅くなります。

正規化の程度。重複をなくすほど整合性は保てますが、参照が複雑になります。用途に応じた判断が要ります。

拡張の余地。データが10倍になったとき耐えられるか。最初からすべてを備える必要はありませんが、想定は必要です。

設計が不適切だと、どの製品を選んでも問題は解決しません。

学ぶ順序

この領域を学ぶ場合の順序を示します。

第一に、SQLの基本。取り出す、絞る、並べる、集計する。ここまでで日常的な確認作業はできます。

第二に、複数の表を結合する。実務のデータは分かれています。ここが最初の壁です。

第三に、設計を学ぶ。正規化、索引、制約。既存システムの構造を読むことが練習になります。

第四に、性能を扱う。実行計画を読み、遅い処理を改善する。ここから専門的な領域に入ります。

NoSQLは、RDBを理解してから触れるほうが違いが分かります。先に触れると、何が特殊なのかを掴みにくくなります。

性能を左右するもの

製品の選定より、実は使い方のほうが性能に効きます。

索引の有無。大量のデータから条件に合うものを探すとき、索引がなければ全件を順に確認します。数百万件では、応答時間が桁違いに変わります。

取得する量。必要な列だけを指定するか、すべてを取るか。転送量が変わります。

結合の仕方。複数の表を組み合わせる処理は、順序と方法で速度が大きく変わります。

接続の管理。接続の確立には費用がかかるため、使い回す仕組みが必要です。

いずれも実行計画を確認すれば原因が分かります。どう処理されるかを表示する機能が、どの製品にも用意されています。

バックアップと復旧

データベースの運用で最も重要なのが、この領域です。

取得しているだけでは不十分です。実際に戻せるかを確認する必要があります。復元を試したことがない組織は珍しくありません。

どこまで戻せるかを決めておきます。1日前まででよいのか、数分前まで必要か。要件によって仕組みが変わります。

保管場所を分ける。本番と同じ場所に置いたバックアップは、障害や攻撃で一緒に失われます。

クラウドの管理サービスでは、これらが標準で提供されます。自前で運用する場合と比べ、大きな利点になります。