ドキュメントデータベースとリレーショナルデータベース：選択方法

私はSQLの男ですが、SQL データベースだけでなく、ドキュメントデータベースもほとんどあることを知っています。ほとんどのテクノロジーと同様に、各テクノロジーには長所と短所があります。

私はいくつかの記事を読みましたが、それらは理論的すぎました。私が望むのは、2つの実際のケースです：

1. リレーショナルデータベースからドキュメントデータベースへの切り替えにより改善されたとき
2. ドキュメントデータベースからリレーショナルデータベースへの切り替えにより改善されたとき

改善とは、より良いプログラムを作成するものであり、開発時間、スケーラビリティ、パフォーマンス、プログラミング関連のあらゆるものを減らします。2には注意点があります。「誰もがSQLを知っているのでリレーショナルデータベースにフォールバックする」などの話は良くありません。

過去数年間にNoSQLデータベースを選択した主な理由は、可用性です。アマゾン、グーグル、フェイスブックなどの企業にとっては、1時間程度のダウンタイムは許されません。高可用性を実現するには、単一障害点を減らす必要があります。つまり、コンピューターがクラッシュした場合でも、複数のコンピューターで分散システムを使用する必要があるため、サービスは引き続き利用可能です。

従来のRelationeデータベースは、分散マルチマスター設定ではあまり良くありません。それが、最近NoSQLがとても人気がある理由です。したがって、高可用性が必要な場合は、Riak、Cassandra、HBase、S3、BigTableなどのNoSQLデータベースを選択できます。

AmazonのDynamoに関する優れたブログ投稿があり、これは分散NoSQLデータベースの優れた入門書です。

現在、NoSQLの用語は非常に広いため、配布されていない多くのNoSQLデータベースがあります。しかし、彼らは他の問題を解決します。たとえば、Neo4j-グラフデータベースは、従来のRDBMSが最適化されていない種類のクエリに適しています。または、ドキュメントデータベースの場合のように、ドキュメントにフィールドを追加する場合にスキーマを変更する必要はありません。言い換えれば、ほとんどの投稿（ドキュメント）に異なるフィールドがある場合、ドキュメントデータベースは優れているため、定義済みの列を含むリレーショナルテーブルは使用できません。

ただし、ほとんどのNoSQLデータベースは従来のRDBMSデータベースほど柔軟ではないため、問題を解決できなくなるまで従来のRDBMSデータベースを使用することをお勧めします。

データに最適なデータベースを決定する簡単な方法があります。

私は自分に問いかけます。データベースがないと仮定して、最も重要なデータをドキュメントとして保存するか、スプレッドシートに保存します。

答えが「スプレッドシート」である場合、これは、リレーショナルモデルと従来のRDBMSがほとんどの時間のタスクに最適であることを明確に示しています。キー値のペアまたは単純なテーブルのみのようにデータが本当に単純で、参照整合性がトピックでない場合、NoSQLデータベースはおそらくタスクに最適であり、パフォーマンスを大幅に向上させる可能性があります。

また、共通の構造がまったく見つからない場合は、NoSQLデータベースがタスクに最適です。

データがより明確な関係にある場合、たとえば、明確な関係のない階層構造のテキストデータの場合、すぐに階層構造の文書を簡単に保存できるXMLデータベースを考えます。ただし、ドキュメント管理ソフトウェアを使用するのが最善の場合もあります。

したがって、あなたの両方の質問に具体的かつ簡単な答えを与えるために：それはデータに依存します。

リレーショナルデータベースからドキュメントデータベースへの切り替えにより改善されたとき

階層構造のテキストデータを保持する必要がある場合、Xml-Databaseを使用すると、保守性とおそらくスケーラビリティの面で大きな改善が得られます。

ドキュメントデータベースからリレーショナルデータベースへの切り替えにより改善されたとき

たとえば、データの大部分が表のような形式で、明確な関係があり、整合性を保証する必要がある場合です。

取得するデータには単純で明白な固定された静的スキーマがなかったため、リレーショナルモデルをあきらめなければなりませんでした。

ユーザー（およびユーザーストーリー）には、固定の静的スキーマがありませんでした。

固定の静的なRDBMSスキーマを課そうとしましたが、それは間違いでした。

サードパーティのデータ配信（顧客とベンダーから）はそれぞれ似ていましたが、同一ではありませんでした。固定のリレーショナルスキーマにマッピングしようとしましたが、そのばらつきは大きすぎました。すべてのファイルにフィールドを追加する必要がありました（毎週数回）か、固定の静的リレーショナルスキーマから離れる必要がありました。

各レコードを、要素の共通サブセットと追加のデータ要素の一意の（および不明確な）コレクションを持つ「ドキュメント」と見なすと、はるかに幸せになりました。

データ要素の不適切に定義されたコレクションは、ユーザーがユースケースに実際に必要としたものです。

リレーショナルモデルの固定された静的スキーマは、ユースケースに適合しませんでした。