MongoDB FAQ #1: MongoDB の基礎情報

サポートプラットフォームの一覧はこちらSupported Platforms をご参照ください。

はい。 MongoDB Atlas はクラウドホストの database-as-a-service (DbaaS) です。 詳細はこちらをご覧ください：MongoDB Atlas docs

MongoDB database ではデータをテーブルではなくコレクションに保管します。 コレクションは1つもしくはそれ以上の BSON ドキュメントを保持します。 ドキュメントはリレーショナルデータベーステーブルのレコードや列に類似したものです。ドキュメントは1つもしくはそれ以上のフィールドを保持しており、フィールドはリレーショナルデータベーステーブルのカラムに類似したものです。　

こちらもご参照ください：SQL から MongoDB へのマッピングチャート、MongoDB のご紹介　

データベースが存在しない場合、そのデータベース用のデータを初めて保管するときに MongoDB がデータベースを作成します。コレクションが存在しない場合、そのコレクション用のデータを初めて保管するときに MongoDB がコレクションを作成します。[1] したがって、存在しないデータベースに（<dbname>を使用して）スイッチし、以下の操作を行うことができます：

use myNewDB 

db.myNewCollection1.insertOne( { x: 1 } )

db.myNewCollection2.createIndex( { a: 1 } )

データベースもしくはコレクションが存在しない場合、insert操作によってmyNewDBデータベースおよびmyNewCollection1コレクションが作成されます。 createIndex操作は、myNewDBが作成された後に動作し、もしそのコレクションが存在しない場合に、インデックスおよびmyNewCollection2コレクションが作成されます。 もしmyNewDbが存在しない場合、createIndex操作もまた myNewDBを作成します。

[1] db.createCollectionを使用して明示的にコレクションを作成することも可能です。maximum size や document validation rulesなどの細かなオプションを指定したい場合に使用できます。

MongoDBではコレクションのスキーマを指定する必要はありません。 コレクション中のドキュメントは、大概共通の構造を持つことが一般的ですが、それは必要条件ではありません。すなわち： 1つのコレクション内のドキュメントは、同じフィールドセットを持つ必要はありません。 フィールドのデータタイプもまた、1つのコレクション内のドキュメント間で異なることが可能です。1つのコレクション内のドキュメント間で異なったフィールドを保持することも可能です。

一つのコレクション内のドキュメント構造を変更するには、ドキュメントを新しい構造に更新します。 つまり、新しいフィールドを追加し、既存のフィールドを削除するか、あるいはフィールドの値を新しい型に更新するのです。

version 3.2における変更: MongoDB 3.2 以降では更新およびインサート操作中に、コレクションに対してドキュメント検証ルールを適用できます。

コレクションのいくつかのプロパティ、例えば最大サイズ等はコレクションの作成中に明示的に指定および変更ができます。db.createCollection と collModをご参照ください。それらのプロパティを指定しない場合、コレクションを明示的に作成する必要はありません。なぜならば、MongoDB はあなたがコレクションに初めてコレクション用のデータを保管しようとするときに新規のコレクションを作成するからです。

直接的にはサポートしていません。 しかしながら、MongoDB は自前の豊富なクエリ言語をサポートしています。 MongoDB のクエリ言語の使用例については、 MongoDB CRUD Operations をご参照ください。

MongoDBコレクションに対してSQLクエリを実行するために、MongoDB Connector for BIを使用することもできます。

SQL to MongoDB Mapping Chart もご参照ください。

ドキュメントは関係スキーマを有し、別れている親子テーブルをまたがってドキュメントを運ぶことができます。関連データがもしそのように動かされない場合は、関連スキーマの個々の親子テーブルを横断してモデルされます。したがって、MongoDB のアトミックなシングルドキュメントオペレーションは、それ単体で、大多数のアプリケーションのデータ整合性ニーズに応えるトランザクション・セマンティックス を供給しています。1つの操作で、1つもしくはそれ以上のフィールドが書込まれます。これには複数のサブ・ドキュメントおよび配列の個別の要素の更新も含まれます。 ドキュメントの更新に関する完全な保障がMongoDBによって提供されています。(ドキュメントの更新時に)エラーが発生すると、更新前の状態にロールバックするため、クライアントはドキュメントに関する一貫性のあるビューが得られることが保証されています。

MongoDB 4.0で予定されているマルチドキュメントトランザクションについては、開発者が「RDBで慣れ親しんだトランザクションだ」とお感じになるでしょう。マルチ・ステートメントである点、シンタックスが似ている点、アプリへの追加が容易である点、等。トランザクションはスナップショット隔離によって、グローバルで常に安定したデータビューを提供し、all-or-nothing 実行を可能にします。またそれはトランザクションを必要としないワークロードのパフォーマンスに影響を与えません。マルチドキュメントトランザクションの追加によって、開発者によるMongoDBの適用がさらに容易になります。beta program はこちら。

注：

当社製品の機能の開発・リリース・および時期についての説明の一切の裁量は当社にあるものとします。 ここに記載している情報は当社製品の大まかな方向性を要約したものであり、ご購入の決定に使用されるべきものではありません。また本情報はマテリアル、コード、機能を提供するコミットメント、確約、法的責任を生じさせるものでもありません。

はい。MongoDBはRAMに最も直近に使用されたデータをキャッシュします。もしクエリに対してインデックスを作成し、ワーキングデータセットがRAM が受容できる量であれば、MongoDB は全クエリをメモリから読み出します。

MongoDBは個別にキャッシュされたクエリ結果を戻すためにクエリ結果をキャッシュすることはしません。

MongoDB およびメモリ使用に関する更なる情報はこちらをご参照ください。 WiredTiger and Memory Use , MMAPv1 and Memory Use

BSON

MongoDB ではクライアントプログラムがクエリを内部的に構成するにあたって string ではなく BSON オブジェクトを構築します。したがって、従来のSQL インジェクションアタックの問題はありません。本件の詳細およびニュアンスは以下をご覧ください。

MongoDBはクエリの内部表現としてBSONオブジェクトを使用します。通常クライアントライブラリが、それらのオブジェクトのビルドのために、便利かつインジェクションフリーなプロセスを提供します。 次の C++ 例を見てみましょう。

BSONObj my_query = BSON( "name" << a_name );

auto_ptr<DBClientCursor> cursor = c.query("tutorial.persons", my_query);

ここでは、my_query は { name : "Joe" } といった値を持ちます。もしmy_queryが特殊なキャラクター、例えば 「,」や「:」 や「 { 」などを保有している場合は、クエリはどのドキュメントともマッチしません。例えば、ユーザーがクエリをハイジャックして上記の検索クエリを削除クエリに変更するようなことはできません。

JavaScript

注：

設定によって全てのサーバサイドのJavaScriptの実行を禁止することができます。コマンドラインに “--noscripting” オプションを追加するか、設定ファイル内の security.javascriptEnabled オプションを変更します。

次のMongoDB 操作では、任意のJavaScript 表現を直接サーバーに実行することができます。

• $where
• mapReduce
• group

これらのケースではユーザーが悪意のJavaScript を送信しないよう、注意が必要です。

幸いMongoDB ではほとんどのクエリをJavaScript なしで表現できます。JavaScript を必要とするJavaScript については、一つのクエリ内でJavaScript と非JavaScript を混在させることが可能です。BSON にユーザーが指定する全フィールドを直接配置し、JavaScript コードを$where フィールドに渡します。

もしユーザーが指定する値を$where句にパスする必要がある場合は、CodeWScopeメカニズムを使用してそれらの値をエスケープさせる退避させることができます。スコープドキュメントでユーザー指定の値を変数として設定すれば、データベースサーバ上での値の評価を回避できます。