企業に適したタイプのデータベースを選択する方法

テクノロジーを多用するデータベースのレビューは何百もありますが、データベースを選択する最初のステップである特定のアプリケーションに最適な一般的なタイプを選択するための明確なガイダンスを常に提供しているわけではありません。すべてのデータベースが同じように作成されるわけではありません。それぞれに特定の長所と短所があります。ほとんどのプロジェクトでお気に入りのデータベースを機能させるための回避策が存在することは事実ですが、これらのトリックを使用すると、不必要な複雑さが加わります。

特定のデータベースを検討する前に、手元のプロジェクトを最もよくサポートするタイプを検討してください。問題は「SQLとNoSQL」よりも深くなります。最も一般的なデータベースタイプの概要、それぞれの相対的なメリット、およびどれが最適かを判断する方法について読んでください。

リレーショナルデータベース管理システム(Oracle、MySQL、MS Server、PostgreSQL)

リレーショナルデータベースは、生成されるデータの増加する洪水を処理するために1970年代に開発されました。それらは確かな基礎理論を持っており、今日使用されているほぼすべてのデータベースシステムに影響を与えてきました。

リレーショナルデータベースは、データセットを「リレーション」として格納します。つまり、すべての情報が特定のセルの値として格納される行と列を持つテーブルです。RDBMSのデータは、SQLを使用して管理されます。さまざまな実装がありますが、SQLは標準化されており、一定レベルの予測可能性と有用性を提供します。

初期のベンダーの洪水が、あまりリレーショナルではない製品でシステムの人気を利用しようとした後、作成者のEF Coddは、すべてのリレーショナルデータベース管理システムが従わなければならない一連のルールの概要を説明しました。コッドの12の規則は、厳密な内部構造プロトコルを課し、検索で要求されたデータが確実に返されるようにし、構造の変更を防止することを中心に展開しています(少なくともユーザーによる)。このフレームワークにより、リレーショナルデータベースは今日まで一貫性と信頼性が確保されています。

強み

リレーショナルデータベースは、高度に構造化されたデータの処理に優れており、ACID(Atomicity、Consistency、Isolation、およびDurability)トランザクションのサポートを提供します。データは、SQLクエリを使用して簡単に保存および取得できます。既存のデータを変更せずにデータを追加するのは簡単なので、構造をすばやくスケールアップできます。

特定のユーザータイプがアクセスまたは変更できるものに制限を作成することは、RDBMSの構造に組み込まれています。このため、リレーショナルデータベースは、階層型アクセスを必要とするアプリケーションに最適です。たとえば、顧客は自分のアカウントを表示でき、エージェントは必要な変更を表示して行うことができます。

弱点

リレーショナルデータベースの最大の弱点は、それらの最大の強みの鏡です。彼らは構造化データの処理に長けていますが、非構造化データでは苦労しています。RDBMSの範囲内では、コンテキストで実世界のエンティティを表すことは困難です。「スライスされた」データは、テーブルからより読みやすいものに再構築する必要があり、速度に悪影響を与える可能性があります。固定スキーマも変更にうまく反応しません。

コストはリレーショナルデータベースでの考慮事項です。それらは、セットアップと成長に費用がかかる傾向があります。水平スケーリング、またはサーバーを追加することによるスケーリングは、通常、サーバーにリソースを追加する垂直スケーリングよりも高速で経済的です。ただし、リレーショナルデータベースの構造はプロセスを複雑にします。リレーショナルデータベースをスケールアウトするには、シャーディング(データが水平方向に分割され、マシンのコレクション全体に分散される)が必要です。ACIDコンプライアンスを維持しながら、リレーショナルデータベースをシャーディングすることは困難な場合があります。

次の目的でリレーショナルデータベースを使用します。

  • データの整合性が絶対的に最優先される状況(つまり、金融アプリケーション、防衛とセキュリティ、および個人の健康情報)
  • 高度に構造化されたデータ
  • 内部プロセスの自動化

ドキュメントストア(MongoDB、Couchbase)

ドキュメントストアは、JSON、BSON、またはXMLドキュメントにデータを格納する非リレーショナルデータベースです。それらは柔軟なスキーマを特徴としています。ユーザーがデータを挿入する前にテーブルのスキーマを宣言する必要があるSQLデータベースとは異なり、ドキュメントストアはドキュメント構造を強制しません。ドキュメントには、必要な任意のデータを含めることができます。キーと値のペアがありますが、クエリを簡単にするために属性メタデータも埋め込まれています。

強み

ドキュメントストアは非常に柔軟です。半構造化データと非構造化データを適切に処理します。ユーザーは、セットアップ中にどのタイプのデータが保存されるかを知る必要がないため、どの種類のデータが受信されるかが事前に明確でない場合に適しています。

ユーザーは、すべてのドキュメントに影響を与えることなく、特定のドキュメントに目的の構造を作成できます。スキーマはダウンタイムを発生させることなく変更できるため、高可用性につながります。書き込み速度も一般的に高速です。

柔軟性に加えて、開発者はドキュメントストアが好きです。なぜなら、ドキュメントストアは水平方向に簡単に拡張できるからです。水平スケーリングに必要なシャーディングは、リレーショナルデータベースよりもはるかに直感的であるため、ドキュメントストアは迅速かつ効率的にスケールアウトします。

弱点

ドキュメントデータベースは、柔軟性のためにACIDコンプライアンスを犠牲にします。また、クエリはドキュメント内で実行できますが、ドキュメント間で実行することはできません。

次の目的でドキュメントデータベースを使用します。

  • 非構造化または半構造化データ
  • コンテンツ管理
  • 詳細なデータ分析
  • ラピッドプロトタイピング

Key-Valueストア(Redis、Memcached)

Key-Valueストアは、各値が特定のキーに関連付けられている非リレーショナルデータベースの一種です。連想配列とも呼ばれます。

「キー」は、値にのみ関連付けられた一意の識別子です。キーは、DBMSで許可されているものであれば何でもかまいません。たとえば、Redisでは、キーは512MBまでの任意のバイナリシーケンスです。

「値」はblobとして格納され、事前定義されたスキーマは必要ありません。数値、文字列、カウンター、JSON、XML、HTML、PHP、バイナリ、画像、短い動画、リスト、さらにはオブジェクトにカプセル化された別のキーと値のペアなど、ほぼすべての形式をとることができます。一部のDBMSではデータ型を指定できますが、必須ではありません。

強み

このスタイルのデータベースには多くの利点があります。非常に柔軟性があり、非常に幅広いデータ型を簡単に処理できます。キーは、インデックスの検索や結合を行わずに値に直接移動するために使用されるため、パフォーマンスが高くなります。移植性は別の利点です。Key-Valueストアは、コードを書き直すことなく、あるシステムから別のシステムに移動できます。最後に、水平方向の拡張性が高く、全体的な運用コストが低くなります。

弱点

柔軟性には代償が伴います。値はblobとして保存され、そのようにのみ返されるため、値をクエリすることはできません。これにより、値の一部のレポートや編集が困難になります。すべてのオブジェクトをキーと値のペアとしてモデル化するのも簡単ではありません。

次の目的でKey-Valueストアを使用します。

  • 推奨事項
  • ユーザープロファイルと設定
  • 製品レビューやブログコメントなどの非構造化データ
  • 大規模なセッション管理
  • 頻繁にアクセスされるが、頻繁には更新されないデータ

ワイドカラムストア(Cassandra、HBase)

列ストアまたは拡張可能なレコードストアとも呼ばれるワイド列ストアは、動的な列指向の非リレーショナルデータベースです。これらは、Key-Valueストアの一種と見なされることもありますが、従来のリレーショナルデータベースの属性も備えています。

ワイド列ストアは、スキーマの代わりにキースペースの概念を使用します。キースペースには、列ファミリー(テーブルに似ていますが、構造がより柔軟です)が含まれ、各ファミリーには、異なる列を持つ複数の行が含まれています。各行は、同じ数またはタイプの列である必要はありません。タイムスタンプは、データの最新バージョンを決定します。

強み

このタイプのデータベースには、リレーショナルデータベースと非リレーショナルデータベースの両方の利点がいくつかあります。構造化データと半構造化データの両方を他の非リレーショナルデータベースよりも適切に処理し、更新が簡単です。リレーショナルデータベースと比較して、水平方向にスケーラブルであり、大規模で高速です。

列データベースは、行ベースのシステムよりも圧縮率が高くなります。また、大規模なデータセットは簡単に探索できます。たとえば、ワイド列ストアは集計クエリに特に適しています。

弱点

書き込みは小さなものでは高価です。更新は一括で行うのは簡単ですが、個々のレコードをアップロードして更新するのは困難です。さらに、トランザクションを処理する場合、ワイド列ストアはリレーショナルデータベースよりも低速です。

ワイドカラムストアを次の目的で使用します。

  • スピードが重要なビッグデータ分析
  • ビッグデータのデータウェアハウジング
  • 大規模プロジェクト(このデータベーススタイルは、平均的なトランザクションアプリケーションには適していません)

検索エンジン(Elasticsearch)

データベースの種類に関する記事に検索エンジンを含めるのは奇妙に思えるかもしれません。ただし、Elasticsearchは、開発者が検索ラグを削減する革新的な方法を模索しているため、この分野で人気が高まっています。Elastisearchは、データの保存と迅速な検索のために特別に配置および最適化された、非リレーショナルのドキュメントベースのデータ保存および検索ソリューションです。

強み

Elastisearchは非常にスケーラブルです。全文検索、提案、複雑な検索式などの高度な検索オプションを備えた、柔軟なスキーマとレコードの高速検索を備えています。

最も興味深い検索機能の1つはステミングです。ステミングは、単語の語根形式を分析して、別の形式が使用されている場合でも関連するレコードを見つけます。たとえば、雇用データベースで「有料の仕事」を検索しているユーザーは、「有料」と「有料」のタグが付けられたポジションも検索します。

弱点

Elastisearchは、プライマリデータベースというよりも、仲介ストアまたは補足ストアとして使用されます。耐久性が低く、セキュリティも劣ります。固有の認証やアクセス制御はありません。また、Elastisearchはトランザクションをサポートしていません。

Elastisearchのような検索エンジンを使用して次のことを行います。

  • より高速な検索結果によるユーザーエクスペリエンスの向上
  • ロギング

最終的な考慮事項

一部のアプリケーションは、1つの特定のデータベースタイプの長所にうまく適合しますが、ほとんどのプロジェクトでは、2つ以上のデータベース間で重複があります。そのような場合、競合するスタイルの特定のデータベースが適切な候補であるかどうかを確認すると便利です。ベンダーは、データベースを個々の標準に合わせて調整するための幅広い機能を提供しています。これらのいくつかは、セキュリティ、スケーラビリティ、コストなどの要因に関する不確実性を解決するのに役立つ場合があります。