IT168コメント]背景用SQLのみNoSQLの掘り下げたい人には大変な作業のように、MySQLとMongoDBのが一般的にオープンソースのデータベースを使用しているようですが、MySQLは従来のリレーショナルデータベースであり、MongoDBはまた、非リレーショナルデータベースです文書データベース、NoSQLのデータベースと呼ばれます。彼らは、自分の長所、任意の場所で使用するキーを持っています。
どのような状況下では、MongoDBは最良の選択でしょうか？
多くの人が信じられないほど強力にMongoDBは、スケーラブルな、ユーザーフレンドリーな対話的なデータベースソリューションだと思います。開発者はデータベース環境を管理するために必要がある場合、MongoDBは良い選択です。少なくとも、中小企業や新興企業で、それがあります。でBSON MongoDBの（バイナリJSON）に格納された情報。BSONは、バイナリ形式で格納されたJSON形式でそれのように、バイナリJSON、JSONと呼ばれ、ドキュメントオブジェクトおよび埋め込みオブジェクトの配列をサポートするが、何らBSONは、日付とBINDATAタイプなどのいくつかのJSONデータ型を持っていません。JSONは、多くの開発者がJSONでの経験を使っている他のプログラミング言語と関連付けることは容易です。
あなたがプログラムが多くのトラフィックを持って書くとき、MongoDBは良い選択です。これは、MySQLがMongoDBのは比較的簡単ですということだけ言って、頻繁に書かれた環境に対処するには良い選択ではないと言っているわけではありません。オーバーロードされた環境を書き込むためのFacebookは（ベンチマークでこの点を証明する）性能も良いですが、RocksDBストレージエンジンを設計しました。
あなたはモデル、あるいは全くモデル柔軟なデータ構造を必要とする場合、MongoDBは良い選択です。MongoDBはNoSQLのソリューションセールスポイントであり、相対的な容易さと寛容のデータ構造を変更します。オンラインスキーマの変更は、構造を定義せずに作成したレコードだけはMongoDBのの柔軟性を高め、MySQLの世界で可能となるようにする多くの改良点があります。
もう一つの理由は、それがMongoDBのレプリケーション環境の設定、断片化および自動選択の組み込み関数を選択したことです。MongoDBのレプリケーション環境に配置された、簡単で、自動選択プロセスは、プライマリ・データベースの障害が発生した場合に、データベースから引き継ぐことができます。内蔵の断片化は、単純な横方向の広がりが可能になります。MySQLの環境管理では、構成設定が複雑になることがあります。
どのような状況下でのMongoDBを選択することはできませんか？
いくつかのユースケースでは、MongoDBは良い選択ですが、それは万能薬ではありません。データが高度に構造化との関係である場合には、MongoDBは最良の選択ではありません。MongoDBは、トランザクションをサポートしていますが、ドキュメントレベルでは、原子しません。レプリケーション環境の場合は、コンフィギュレーションノートに関する質問は、価格、性能を犠牲にして書かれています。情報の書かれた用語のコピーが書かれていることを確認し、デフォルトでは、MongoDBは確認のみではなく、コピーを要求しているホストコンピュータに要求を書き込みます。問題のコピーがある場合ので、整合性の問題につながります。
どちらの構造の違いは何ですか？
概念の多くは、MongoDBのの文書構造でSQLに関連しています。のが良いのMongoDBのレイアウトを理解するために、単純な構造のMongoDB環境を見てみましょう。
以下の表は、MySQLやMongoDBの違いを関連付けます：
また、もう一つの興味深い場所はのmongodプロセスです。これは、デーモンプロセスデータ要求である、とMySQLのmysqldプロセスがほぼ同じである、MongoDBのデータベースアクセス要求のプロセスを監視および管理することです。そして、MySQLは、のような、のmongodプロセスが起動オプションをたくさん持っています。最も重要な設定オプションの一つは、インスタンスをmongodは、設定ファイルに専用されている設定ファイル、です。そして、MySQLは、このファイルはYAMLフォーマットを使用して、わずかに異なっています。次は、例のMongoDBプロファイルです。それは、任意の本番データベース用に最適化されていない、このプレゼンテーションがフォーマットされていることに注意してください。
定義によると、MongoDBは、分散ファイル・ストレージベースのデータベースです。ドキュメントは、テーブルを作成し、定義された構造なしにデータを追加することなく、即座に収集に挿入することができます。これはMongoDBの、より柔軟に比べてのMySQLの利点の一つです。この柔軟性はMongoDBのが楽に強力な組織のMongoDBデータベースを提供することを意味しないことに注意してください。任意のデータベースを選択し、データベースの構造と目的を考慮すべきです。
＃のmongod.conf、MongoDBのためのPerconaサーバー
すべてのオプションのドキュメントの＃は、以下を参照してください。
＃http://docs.mongodb.org/manual/reference/configuration-options/
＃どこで、どのようにデータを格納します。
ストレージ：
DBPATH：は/ var / libに/ MongoDBの
ジャーナル：
有効：真
エンジン：rocksdb
＃どこログデータを書き込みます。
systemlog：
先：ファイル
logAppend：真
パス：/var/log/mongodb/mongod.log
processManagement：
フォーク：真
pidFilePath：/var/run/mongod.pid
＃ネットワークインタフェース
ネット：
ポート：27017
Bindip：127.0.0.1
注意：YAMLフォーマットはタブを処理しない、インデントするスペースを使用。
クエリの違いは何ですか？
シェルを通って、SQLデータベースと対話するには、以下のSQLからのみのユーザテーブルは、関連のユーザー名とIDを使用しているMongoDBのクエリ例に翻訳され、わずかに異なっています。
SQLには：
ここで、ID = 2のユーザからユーザ名を選択します。
MongoDBのには：
db.user.find（{_ ID：2}、{「ユーザ名」：1}）
JSON形式では、コレクションを照会するユーザーを指定し、私たちの関心に関連付けられたドキュメントIDを指定します。最後に、取得するには、このクエリは、ユーザー名2のユーザIDのためになる、そこからフィールドの値を指定します。
概要
MongoDBはMySQLがゆっくりと一緒に二つのデータベースの開発と、に代わるものではありません、そして彼らの長所と短所は、MySQLの影ではありません。MySQLのユーザーは、MongoDBの上のさまざまなインスタンスをテストすることができますが、柔軟性のMongoDBの盲目の追求を奨励していません。電子商取引でのMongoDBとゲームの世界が、それは水平拡張のために大量のデータを活用することができますので、人気のある選択肢です。