回答:
リレーショナルデータベースはACIDを適用します。したがって、スキーマベースのトランザクション指向のデータストアができます。実績があり、実際のアプリケーションの99％に適しています。リレーショナルデータベースを使用すれば、実質的に何でもできます。
ただし、大規模な高可用性データストアに関しては、速度とスケーリングに制限があります。たとえば、GoogleとAmazonは、テラバイト単位のデータをビッグデータセンターに保存しています。RDBMのブロッキング/スキーマ/トランザクションの性質のため、これらのシナリオではクエリと挿入はパフォーマンスがよくありません。これが、パフォーマンスを大幅に向上させ、スケーラビリティを実現するために独自のデータベース（実際にはキーと値のストア）を実装した理由です。
NoSQLデータベースは長い間存在してきました-用語が新しいだけです。いくつかの例は、グラフ、オブジェクト、列、XML、ドキュメントデータベースです。
2番目の質問：同じサイトで両方を使用しても大丈夫ですか？
何故なの？どちらも異なる目的を果たしますか？
NoSQLソリューションは通常、リレーショナルデータベースが適さない、（Oracleのように）使用するには高すぎる、またはとにかくデータベースのリレーショナル性を壊すものを実装する必要があるという問題を解決するためのものです。
利点は通常、使用方法に固有ですが、RDBMSでのデータのモデリングに何らかの問題がない限り、NoSQLを選択する理由はわかりません。
私自身、MongoDBとRiakを使用して、RDBMSが実行可能なソリューションではない特定の問題について、MySQL（またはテスト用のSQLite）を使用する他のすべてのものについて使用しています。
通常それについて知っているNoSQLデータベースが必要な場合、考えられる理由は次のとおりです。
NoSQLソリューションが必要ない場合、これらのソリューションはRDBMSの代替としてではなく、前者が失敗した場合の代替手段であり、さらに重要なことに、比較的新しいため、まだ多くのバグがあり、不足している機能。
ああ、そして2番目の質問に関しては、テクノロジーを別のテクノロジーと組み合わせて使用するのはまったく問題ないので、私の経験からすれば、MongoDBとMySQLが同じマシン上にない限り、うまく機能します。
マーティンファウラーは、NoSQLデータベースについて説明する優れたビデオを公開しています。リンクはそれらを使用する理由に直接つながっていますが、ビデオ全体には優れた情報が含まれています。
NoSQLは適切にスケーリングできるように設計されているため、1つの物理サーバーにすべてを収めることができない場合は特に、大量のデータがあります。
オブジェクトリレーショナルインピーダンスの不一致 -ドメインオブジェクトは、リレーショナルデータベーススキーマにうまく適合しません。NoSQLを使用すると、データをドキュメント（またはグラフ）として永続化できます。ドキュメントは、データモデルにより密接にマップできます。
NoSQLは、データがドキュメント（MongoDB）、キーと値のペア（MemCache、Redis）、グラフ構造フォーム（Neo4J）に編成されるデータベースシステムです。
多分ここに「NoSQLに行くとき」のための可能な質問と答えがあります：
柔軟なスキーマが必要ですか、それともツリーのようなデータを処理しますか？
一般に、アジャイル開発では、すべての要件を事前に把握せずにシステムの設計を開始します。その後、開発データベースシステム全体で頻繁な設計変更に対応し、MVP（Minimal Viable製品）を紹介する必要があります。または、動的なデータスキーマを扱っています。たとえば、システムログ、非常に正確な例はAWSクラウドウォッチログです。
データセットは広大ですか？
はいNoSQLデータベースは、データベースがパフォーマンスを犠牲にすることなく数百万または数十億ものレコードを管理する必要があるアプリケーションのより良い候補です。
一貫性に対するスケーリングのトレードオフ
RDMSとは異なり、NoSQLデータベースはあちこちで小さなデータを失う可能性があります（注：確率は.x％です）が、パフォーマンスの点でスケーリングは簡単です。例：これは、インスタントメッセージングアプリでオンラインになっている人を格納したり、dbにトークンを保存したり、Webサイトのトラフィック統計をログに記録したりするのに適しています。
地理位置情報操作の実行：MongoDBは、ジオクエリと地理位置情報操作を実行するための豊富なハッシュサポートを提供します。MongoDBのこの機能は本当に気に入りました。
簡単に言えば、MongoDBは、動的な構造化データを大規模に格納できるアプリケーションに最適です。
質問に答えるために欠けている重要な情報がいくつかあります：データベースはどのユースケースをカバーできなければなりませんか？既存のデータ（OLAP）から複雑な分析を実行する必要がありますか、それともアプリケーションは多くのトランザクション（OLTP）を処理できる必要がありますか？データ構造とは何ですか？それは質問時間の終わりからほど遠いです。
私の考えでは、大胆な流行語に基づいてテクノロジーの決定を下すことは間違っています。NoSQLは、そのスケーラビリティーで賞賛されることがよくあります。ただし、水平方向のスケーリング（複数のノードにわたる）にも価格があり、無料ではないことも知っておく必要があります。次に、結果整合性などの問題に対処し、データベースレベルで解決できない場合にデータの競合を解決する方法を定義する必要があります。ただし、これはすべての分散データベースシステムに適用されます。
NoSQLで「スキーマレス」という言葉を持つ開発者の喜びも、最初は非常に大きなものです。この流行語は、テクニカル分析後すぐに劣化します。これは、書き込み時にスキーマを正しく必要とせず、読み取り時に機能するためです。これが、「読み取り時のスキーマ」である必要がある理由です。自分の裁量でデータを書き込むことができるのは魅力的かもしれません。しかし、既存のデータはあるが、新しいバージョンのアプリケーションが異なるスキーマを想定している場合、どうすればこの状況に対処できますか？
ドキュメントモデル（MongoDBなど）は、データ間に多くの関係があるデータモデルには適していません。結合はアプリケーションレベルで実行する必要があります。これは追加の作業であり、なぜデータベースが実行すべきことをプログラムする必要があるのですか。
従来のRDBMSではデータのフラッドを処理できなくなったため、GoogleとAmazonが独自のデータベースを開発したと主張した場合、あなたはGoogleとAmazonではないと言うことができます。これらの企業が中心的存在であり、従来のデータベースがもはや適切ではないシナリオの0.01％ですが、それ以外の世界ではそうです。
重要ではないこと：SQLは40年以上前から存在し、何百万時間もの開発がOracleやMicrosoft SQLなどの大規模システムに費やされてきました。これは、いくつかの新しいデータベースで実現する必要があります。時には、MongoDBの誰かよりもSQL管理者を見つける方が簡単な場合もあります。これは私たちに維持管理の問題をもたらします。正確にはセクシーではありませんが、それはテクノロジーの決定の一部です。
RDBMSの設計から逸脱する説得力のある根拠を探しているときに、この質問に出くわしました。
分散システムの制約に光を当てるJulian Brownによる素晴らしい投稿があります。この概念はブリューワーのCAP定理と呼ばれ、要約すると次のようになります。
分散システムの3つの要件は、一貫性、可用性、およびパーティションの許容範囲（略してCAP）です。ただし、一度に持てるのは2つだけです。
そして、これは私が自分のためにそれを要約した方法です：
一貫性が犠牲になっている場合は、NoSQLを選択することをお勧めします。
NoSQLデータベースを使用してソリューションを設計および実装しました。SQLまたはドキュメント指向のNoSQLを使用するかどうかを決定するためのチェックポイントリストを次に示します。
してはいけないこと
SQLは廃止されておらず、場合によってはより優れたツールであり続けます。ドキュメント指向のNoSQLの使用を正当化するのが難しい場合
する
これらの条件がないか緩和できる場合は、NoSQLを利用できる2つの理由を次に示します。
より詳しい情報
私のブログ投稿で、理由を詳しく説明します。
注：上記は、ドキュメント指向のNoSQLにのみ適用されます。NoSQLには他のタイプがあり、他の考慮事項が必要です。
多数の読み取り書き込み操作の処理
高速に拡張する必要がある場合は、NoSQLデータベースに目を向けてください。そして、通常、いつ高速でスケーリングする必要がありますか？
Webサイトに多数の読み取り/書き込み操作があり、大量のデータを処理する場合、NoSQLデータベースはこれらのシナリオに最適です。オンザフライでノードを追加できるため、レイテンシを最小限に抑えながら、より多くの同時トラフィックと大量のデータを処理できます。
データモデリングによる柔軟性
2番目の手掛かりは、データモデル、データベース設計について確信が持てない開発の初期段階であり、状況は急速に変化することが予想されます。NoSQLデータベースにより、柔軟性が向上します。
強い整合性に対する最終的な整合性
強い整合性をあきらめても問題がなく、トランザクションが不要な場合は、NoSQLデータベースを選択することをお勧めします。
この良い例は、Twitterのようなソーシャルネットワーキングウェブサイトです。有名人のツイートが爆発し、誰もが世界中からそれを好きでリツイートしているとき。いいねの数が少しの間増減したかどうかは重要ですか？
セレブは、実際の500万件の「いいね」の代わりに、システムが「いいね」の件数を500万件250と短時間表示したとしても、まったく気にしません。
大規模なアプリケーションが世界中に広がる数百台のサーバーに展開されると、地理的に分散したノードがグローバルな合意に達するまでに時間がかかります。
コンセンサスに達するまで、エンティティの価値は一貫していません。エンティティの値は、しばらくすると最終的には整合性が取れます。これが結果整合性です。
ただし、この不整合は、何らかのデータ損失があることを意味するものではありません。それは、データが海底のインターネットケーブルを介して世界中を移動し、グローバルなコンセンサスに達して整合性を保つまでに少し時間がかかることを意味します。
私たちは常にこの行動を経験しています。特にYouTubeで。多くの場合、再生回数が10回、高評価数が15の動画が表示されます。これはどのようにして可能ですか？
そうではありません。実際の見解はすでに同類以上のものです。ビューの数に一貫性がなく、更新されるまで少し時間がかかります。
データ分析の実行
NoSQLデータベースは、大量のデータの流入に対処する必要があるデータ分析のユースケースにも最適です。