リレーショナルデータベースの代わりにNoSQLデータベースを使用する場合同じサイトで両方を使用しても大丈夫ですか？
NoSQLデータベースを使用する利点は何ですか？私は最近それらについて多くのことを読みましたが、なぜそれを実装したいのか、どのような状況でそれを使用したいのかまだわかりません。
リレーショナルデータベースは [〜＃〜] acid [〜＃〜] を強制します。したがって、スキーマベースのトランザクション指向のデータストアができます。実績があり、実世界のアプリケーションの99％に適しています。リレーショナルデータベースを使用すると、実質的に何でもできます。
ただし、大規模な高可用性データストアに関しては、速度とスケーリングに制限があります。たとえば、GoogleとAmazonには、テラバイトのデータがビッグデータセンターに保存されています。 RDBMのブロッキング/スキーマ/トランザクションの性質のため、これらのシナリオではクエリと挿入は実行されません。それが、彼らが独自のデータベース（実際には、キーと値のストア）を実装して、パフォーマンスとスケーラビリティを大幅に向上させた理由です。
NoSQLデータベースは長い間使用されてきました-ただ用語は新しいです。いくつかの例は、グラフ、オブジェクト、列、XML、ドキュメントデータベースです。
2番目の質問：同じサイトで両方を使用しても大丈夫ですか？
何故なの？両方とも異なる目的を果たしますか？
NoSQLソリューションは、通常、リレーショナルデータベースが適していない、使用するのに費用がかかりすぎる（Oracleなど）、またはとにかくデータベースのリレーショナル性を壊す何かを実装する必要があるという問題を解決することを目的としています。
通常、利点は使用法に固有のものですが、RDBMSでデータをモデル化する際に何らかの問題がない限り、NoSQLを選択する理由はわかりません。
私自身はMongoDBとRiakを使用して、RDBMSが実行可能なソリューションではない特定の問題に、MySQL（またはテストにSQLite）を使用する他のすべてのことを行います。
needよく知っているNoSQL dbの場合、考えられる理由は次のとおりです。
- クライアントは、トラフィックの多いサイトで99.999％の可用性を望んでいます。
- sQLではデータが意味をなさないため、情報にアクセスするために複数のJOINクエリを実行していることに気付きます。
- リレーショナルモデルを破り、非正規化されたデータを格納するCLOBがあり、そのデータを検索するための外部インデックスを生成します。
NoSQLソリューションが必要ない場合は、これらのソリューションはRDBMSの代替ではなく、前者が失敗する代替手段であり、さらに重要なことに、比較的新しいため、多くのバグと欠落している機能。
ああ、2番目の質問については、他のテクノロジーと組み合わせて使用することはまったく問題ありません。したがって、MongoDBとMySQLが同じマシン上にない限り、MygoDBとMySQLが正常に機能するようになります。
Martin Fowlerには優れた video があり、NoSQLデータベースについての良い説明を提供しています。リンクはそれらを使用する彼の理由に直接行きますが、ビデオ全体には良い情報が含まれています。
大量のデータがあります-特に、NoSQLは適切に拡張できるように設計されているため、1台の物理サーバーにすべてを収めることができない場合。
オブジェクトリレーショナルインピーダンスの不一致 -ドメインオブジェクトが関連するデータベーススキーマにうまく適合しません。 NoSQLを使用すると、データをドキュメント（またはグラフ）として保持し、データモデルにより密接にマッピングできます。
NoSQLは、データがドキュメント（MongoDB）、キーと値のペア（MemCache、Redis）、グラフ構造フォーム（Neo4J）に編成されるデータベースシステムです。
たぶん、「NoSQLを使用するタイミング」に対する可能な質問と回答があります。
柔軟なスキーマが必要か、データのようなツリーを扱いますか？
一般に、アジャイル開発では、すべての要件を事前に知らずにシステムの設計を開始します。開発データベースシステム全体で、頻繁な設計変更に対応し、MVP（最小実行可能製品）を紹介する必要があります。または、本質的に動的なデータスキーマを扱っています。例えばシステムログ、非常に正確な例は、AWSクラウドウォッチログです。データセットが膨大/大きいですか？
はいNoSQLデータベースは、パフォーマンスを犠牲にすることなく、データベースで数百万または数十億ものレコードを管理する必要があるアプリケーションに適しています。スケーリングと一貫性のトレードオフ
。例：これは、インスタントメッセージングアプリでオンラインのユーザー、dbのトークン、Webサイトのトラフィック統計のログを保存するのに適しています。Geolocation操作の実行：GeoQueryingおよびGeolocation操作を実行するためのMongoDBハッシュリッチサポート。 MongoDBのこの機能が本当に気に入りました。
一言で言えば、MongoDBは動的な構造化データを大規模に保存できるアプリケーションに最適です。
質問に答えるためのいくつかの重要な情報が欠落しています。データベースがカバーできる必要があるユースケースはどれですか？既存のデータから複雑な分析を実行する必要があるか（ [〜＃〜] olap [〜＃〜] ）、またはアプリケーションが多くのトランザクションを処理できる必要があるか（ [〜＃ 〜] oltp [〜＃〜] ）？データ構造とは何ですか？それは質問の時間の終わりにはほど遠いです。
私の考えでは、大胆な流行語に基づいてテクノロジーの決定を下すのは間違っています。 NoSQLは、そのスケーラビリティが高く評価されることがよくあります。ただし、水平スケーリング（複数のノードにわたる）にも価格があり、無料ではないことも知っておく必要があります。次に、 結果整合性 などの問題に対処し、データベースレベルで解決できない場合にデータの競合を解決する方法を定義する必要があります。ただし、これはすべての分散データベースシステムに適用されます。
NoSQLの「スキーマレス」というWordを使用した開発者の喜びも、最初は非常に大きなものです。この流行語は、テクニカル分析の後にすぐに幻滅します。これは、書くときにスキーマを正しく必要としないが、読むときに作用するからです。それが、「スキーマon read」である必要がある理由です。自分の裁量でデータを書きたいと思うかもしれません。しかし、既存のデータはあるが、アプリケーションの新しいバージョンが異なるスキーマを想定している場合、どうすれば状況に対処できますか？
ドキュメントモデル（MongoDBなど）は、データ間に多くの関係があるデータモデルの場合、 適切ではありません です。結合はアプリケーションレベルで実行する必要がありますが、これは追加の作業であり、データベースが実行すべきことをプログラムする必要がある理由です。
従来のRDBMSが大量のデータを処理できなくなったために、GoogleとAmazonが独自のデータベースを開発したと主張するなら、あなたは言うことができます。あなたはGoogleとAmazonではありません。これらの企業は先駆者であり、従来のデータベースがもはや適切ではないシナリオの約0.01％ですが、その他の世界ではそうです。
重要ではないこと： [〜＃〜] sql [〜＃〜] は40年以上にわたって存在し、何百万時間もの開発がOracleやMicrosoft SQLなどの大規模システムに導入されています。これは、いくつかの新しいデータベースによって実現する必要があります。 MongoDBの人よりもSQL管理者を見つける方が簡単な場合もあります。メンテナンスと管理の問題に私たちをもたらします。正確にセクシーではないが、それは技術決定の一部です。
RDBMS設計から逸脱する説得力のある根拠を探しているときに、この質問に出会いました。
ジュリアン・ブラウンによる素晴らしい post があり、分散システムの制約に光を当てています。この概念は、要約すると次のとおりです。ブリューワーのCAP定理と呼ばれます。
分散システムの3つの要件は次のとおりです。一貫性、可用性、およびパーティション耐性（略してCAP）。ただし、一度に2つしか持てません。
そして、これは私が自分でそれを要約した方法です：
一貫性が犠牲になっている場合は、NoSQLを選択した方がよいでしょう。