データベース・アーキテクチャ

一般的に、データベースのアーキテクチャには可用性(Availability) と 速度(Speed) と 整合性(Consistency/Integrity) の間にトレードオフ(一方を追求すれば他方を犠牲にせざるを得ないという関係)が成り立ちます。

代表的アーキテクチャ 主な製品 可用性(Availability) 速度(Speed) 整合性(Consistency/Integrity)
リレーショナル・データベース(RDB) SQL Server
Oracle
MySQL
NoSQL MongoDB
Redis
Google BigTable
Amazon DynamoDB
HBase
Cassandra

巷ではリレーショナル・データベース(RDB)の時代はもう終わりでこれからはNoSQLという報道も多々見受けられますが、弊社ではそれぞれの特性を組み合わせるべきと考えます。
ユースケース(用途)に応じてどのようなアーキテクチャを選択するべきかを決定させて頂きます。
上記表のように、可用性(Availability) と 速度(Speed)はそれぞれ十分に早いため、整合性(Consistency/Integrity) の要件に合わせてアーキテクチャを考えます。

そこで、当方のポリシーとしては以下を基本にします。

  • ユーザ体験は 可用性(Availability) と 速度(Speed) を優先します。
  • 大切な保存データは整合性(Consistency/Integrity)を優先します。

上記のポリシーは通常稼働時にはどちらも違いがありません。 1台サーバで小規模運用している時も違いがありません。
複数サーバを運用していて一部サーバが障害発生した時の挙動が異なります。
リレーショナル・データベース(RDB)では(構成にもよりますが) サイト全体が停止する可能性が高まります。 これは、整合性(Consistency/Integrity)を重視してサーバが停止するためです。
NoSQLでは(製品にもよりますが)基本的にはサーバ動作が継続します。 これは、整合性(Consistency/Integrity)よりも可用性(Availability)を重視してそのままサーバが動作継続するためです。

どちらが良いかはユースケースにもよります。

ただし、NoSQLはリレーショナル・データベース(RDB)のようにデータを正規化(用途別に分割)して定義する手法が洗練されておらず、簡単なデータであればNoSQLですぐ実装できるので見た目は簡単に見えるものの、データが複雑になるにつれNoSQLの運用は破綻する危険性が高まります。

よって、弊社ではリレーショナル・データベース(RDB)を基本に考え、アクセスが増えた場合にNoSQLを使用することを考えます。
その場合でも、複数製品を組み合わせると管理が煩雑になるため、同じリレーショナル・データベース(RDB)を使って両方の用途に対応させることを第一にし、それでも対応できない場合にNoSQLを検討します。

最近のサーバはパフォーマンスが高いのでそれなりの規模まではリレーショナル・データベース(RDB)だけで運用が可能です。

規模が拡大するにつれ、以下の構成を辿ります。

ステップ 規模 構成 使用するデータベース
1 低速サーバ1台でWebとデータベースを兼ねる構成 リレーショナル・データベース(RDB)のみ
2 高速サーバ1台でWebとデータベースを兼ねる構成 (スケールアップ) リレーショナル・データベース(RDB)のみ
3 Webとデータベースをそれぞれ複数台で運用 (スケールアウト) リレーショナル・データベース(RDB)のみ (*1)
4 特大 Webとデータベースをかなりの台数で運用 (スケールアウト) リレーショナル・データベース(RDB)のみ (*1)
或いは
リレーショナル・データベース(RDB)とNoSQLの組み合わせ

(*1) 補足: データの要件に従って、とあるデータは整合性を重視して一部サーバ障害時にサーバ全体を停止にするように設計し、一方で、とあるデータの要件としては整合性を後で辻褄合わせれば良いということであれば一部サーバ障害時でも他のサーバの処理は続行するように作り込むことでリレーショナル・データベース(RDB)だけであってもNoSQL的な要件を実現できます。 設計を工夫することでリレーショナル・データベース(RDB)とNoSQLの両方を使用するよりもリレーショナル・データベース(RDB)によるシンプルな管理が行えます。

■NoSQLの使い所

オンライン・ショッピングモールのように提供するデータがある程度固定で更新頻度が低く、アクセスが大量でサーバが複数必要なような場合です。

  • アクセス量が多く、スケールアウト(複数台化)が必要
  • サーバ間がある程度独立して動作すれば十分な場合
  • サーバ間の整合性の優先度が低い用途

よって、アクセス数がさほどでもない場合にNoSQLを使用するのは賢明ではありません。 というのも、NoSQLはデータの構造化に難がある場合が多いためです。

■NoSQLは構造化に弱い

リレーショナル・データベースはデータ構造の定義をまず行うことで整合性を重視しています。一方で、NoSQLは整合性よりも速度やサービス提供を優先しています。 整合性は後で保てばよい、というのがNoSQLの基本的な思想です。 弊社では、基本はリレーショナル・データベースを使用します。 整合性を重視し、しっかりとデータベースの構造を定義させて頂きます。 一方で、速度やサービス提供を重視する要求については必要に応じてNoSQLなどの解決法を選択させて頂きます。

■NoSQLは開発しやすい、素早く作れる、という誤解

一部のNoSQLは構造化データをデータベースに定義せずにデータをそのままプログラムで使う形のまま保存する、という、いわゆるドキュメント指向のNoSQLがございます。そういったNoSQLはデータを定義しない故に簡単に素早く開発できることをうたっていたりしますが、実際には、しっかりとデータの構造を定義しないが故に後で破綻する可能性を秘めた時限爆弾になりかねないのがNoSQLです。 メリットとデメリットを理解した上でNoSQLを使うことは有益ですが、それは必ずしも「開発しやすい」とか「素早く作れる」という単純な比較論ではなく、一面のみをクローズアップした宣伝文句です。 実際には同様にきちんとデータ構造を定義しなければ管理できなくなりますので、それをデータベースで定義するかどうかの違いこそありますが、設計的にはどちらも必要になりますし、その構造化データをしっかりと実装して使っていくとなると、やはりリレーショナル・データベースが優位です。 NoSQLが優位な場面というのは本当に限られます。

■従来開発の問題点をマツエソフト・データベース・クラウドで解決

リレーショナル・データベースを使用する場合にはその実装の手間が問題になります。 旧来の開発では問題となっていたコーディング量の負荷はクラウド上のツール「マツエソフト・データベース・クラウド」を使用することで手間を大幅に削減し、高速な開発を行います。 これが弊社の強みです。 詳しくはデータベース・テクノロジーの記事をご覧下さい

ログイン当サイトのユーザ名(ID)でログイン
クイックログイン:Facebookのアカウントで即時ログイン(ログイン情報保持オプション:ON) / 新規登録


お問い合わせ

© 2016-2018 Matsuesoft Corporation

マツエソフトをフォローする