Best of the MongoDB Blog - Docs-Japanese - 10gen Confluence
based on the blog articles (2011/01/03 更新) - オリジナル NOVEMBER 18, 2009 MongoDBでの高速アップデート (その場で更新) MongoDBのすぐれた特長の一つに、アップデートを「その場で」行える点があります。このときデータベースは、領域を割り当てて、オブジェクト全体の新たなコピーを書き込んだりする必要がありません。 このことは頻繁にアップデートが発生するケースで、高いパフォーマンスを発揮します。例えば、カウンタをインクリメントする場合です。サーバからドキュメントを取ってくる必要はなく、単純に以下の要領でインクリメント操作を行えばよいのです: db.my_collection.update( { _id : ... }, { $inc : { y : 2 } } ); // yに対し2のインクリメントを行う いっぽうMong
ユースケース - Docs-Japanese - 10gen Confluence
based on v34 (2011/01/30 更新) - オリジナル ※Shutterfly、foursquare、bit.ly、Etsy、SourceForge といった企業がどのようにMongoDBを利用しているかについては、プロダクション展開 (Production Deployments)のページもご覧ください。 非常に向いているケース WEBサイトの操作データの蓄積 MongoDBはリアルタイムでのインサート、アップデート、そしてクエリーにおいて大変優れています。大規模なwebサイトのリアルタイムデータを格納する上で不可欠となる、スケーラビリティとレプリケーションも用意されています。以下は具体的なwebでのユースケース例です: コンテンツ管理 コメントの格納、管理、投票 ユーザ登録、プロファイル、セッションデータ キャッシュ 高いパフォーマンスを実現する潜在能力のため、
mongo - インタラクティブシェル - Docs-Japanese - 10gen Confluence
紹介 MongoDBの配布パッケージに含まれている bin/mongo は、MongoDBのインタラクティブシェルです。このユーティリティは、Javascriptのシェルで、コマンドラインからMongoDBのコマンドを発行することができます。(基本的に、 SpiderMonkey を拡張したものです。) このシェルは以下のことをするときに便利です。 データベースのコンテンツの調査 クエリーのテスト インデックスの作成 その他の管理系機能 このwikiのサンプルコードでのJavascriptのようなものは、シェル上での実行例です。 それぞれの例の他の各言語での例は driver syntax table を参照してください。 その他の情報 シェル 概要 シェル リファレンス シェル API シェル上でのデータタイプの注意点 数字 デフォルトでは、シェルはすべての数を浮動小数(floating
クエリー - Docs-Japanese - 10gen Confluence
based on v23 (2010-10-03更新) - オリジナル MongoDBのすばらしいところの一つとして、ダイナミック(ad-hocな)なクエリーのサポートがあります。これはデータを探すのに特別なindedxとかを必要としません。ユーザは、好きな条件で検索することができます。リレーショナルデータベースでは、ダイナミッククエリーは普通のことです。リレーショナルデータベースからMongoDBに移動する場合に、たくさんのSQLクエリーが簡単にMongoDBのドキュメントベースのクエリー言語に変換できます。 クエリ記述オブジェクト MongoDBは、データ取得のために多くの種類の クエリーオブジェクト をサポートしています。クエリーは、BSONドキュメントで表現します。たとえば、MongoDBシェルを使って、 users コレクションに入っているすべてのドキュメントを取得したいとします
インデックス - Docs-Japanese - 10gen Confluence
based on v49 インデックスはクエリーのパフォーマンスを(とても)向上させます。有効なインデックスを定義するためには、アプリケーションが必要とするクエリについてよく知ることが大切です。それさえできていれば、MongoDBでインデックスを作成するのは簡単です。 MongoDBのインデックスは、MySQLのようなRDBMSのインデックスと概念的に似ています。MySQLでインデックスを付けたいような場所に、MongoDBでもインデックスを付けることになるでしょう。 基本 インデックスは、コレクションの中のドキュメントの特定のフィールドの値について集めたデータ構造です。このデータ構造はMongoのクエリオプティマイザによって、コレクション内のドキュメントを、素早く検索したりソートするために使われます。正式な言い方で言うと、インデックスは"B-Tree"で実装されています。 シェル 上で、
インデックス関連コマンド - Docs-Japanese - 10gen Confluence
Based on v11 (2010-10-08更新) - Original インデックスの作成 ensureIndex() がインデックスの作成のためのヘルパーファンクションです。 system.indexes テーブルにインデックスの情報を加えることで、indexを作成します。 > db.myCollection.ensureIndex(<keypattern>); > // 同じです > db.system.indexes.insert({ name: "name", ns: "namespaceToIndex", key: <keypattern> }); 注意: 一度、インデックスが作成されると、すでにコレクションの中にあるドキュメントと、今後インサートされるドキュメントのすべてがインデックス化されます。もし巨大なコレクションがある場合、これは他の操作を長い間ブロックすることにな
Mongoでのデータ更新 - Docs-Japanese - 10gen Confluence
save() で、Mongoシェルの中でドキュメントを更新する 前のセクションで示されているように、 save() はコレクションにドキュメントを保存するために使われます。 save() をコレクション内の既存ドキュメントを更新するためにも使えます。 前のセクションの example データベースをここでも使いましょう。まず、 新しい情報を {name:"mongo"} に加えましょう。 > var mongo = db.things.findOne({name:"mongo"}); > print(tojson(mongo)); {"_id" : "497dab624ee47b3a675d2d9c" , "name" : "mongo"} > mongo.type = "database"; database > db.things.save(mongo); > db.things.fi
アップデート - Docs-Japanese - 10gen Confluence
Based on v72 (2010-11-14更新) - オリジナル MongoDBは、ドキュメント全体を入れ替える通常のアップデートと、アトミックでin-place(その場で)のアップデートをサポートします。 update() update() は、与えられた条件にマッチするドキュメント全体を新しいオブジェクトで置き換えます。一部の項目だけ更新したい場合には、下記のmodifierを使います。 これがMongoDBの update() のシンタックスです。 db.collection.update( criteria, objNew, upsert, multi ) 引数: criteria - アップデートするレコードを選択するためのクエリー objNew - 対象のオブジェクトを、アップデートするオブジェクト、または $オペレータ($incなど) upsert - レコードが存
スキーマデザイン - Docs-Japanese - 10gen Confluence
導入 Mongoでは、リレーショナルデータベースのデザインでするような"正規化"はそれほど必要ありません。サーバサイドでの"join"がないからです。一般的には、1つの最上位のオブジェクトレベルに対して、1つのデータベースコレクションを作ることになるでしょう。 すべての"class"について、コレクションを作ることはあまりしません。代わりにembedオブジェクトを使います。例えば、下記の図では、studentsとcoursesの2つのコレクションがあります。studentドキュメントは、courseコレクションを参照する"address"ドキュメントをembedします。 scoreを他のテーブルに入れ、外部キーとしてstudentテーブルにリレーションを持つことになるであろうリレーショナルなスキーマと対比してみてください。 Embed (組み込み) vs. Reference (参照) M
大量のコレクションを扱う - Docs-Japanese - 10gen Confluence
Based on v6 (2010-11-02更新) オリジナル 場合によっては、一つのコレクションに情報を格納するより、複数のコレクションに分けるのも一つのテクニックです。これをすることで、オブジェクト間で同じデータを持つ必要がなくなりますし、キーについているインデックスも取り除けるかもしれません。さらに大切なのは(場合によっては)、パフォーマンスのために、グループ毎にデータがクラスタリングされることです。 たとえば、データベースにログのためのオブジェクト/ドキュメントを格納することを考えてみてください。複数の種類のログを格納したいです(開発ログ、デバッグログ、操作ログ、etc)。 ここで、一つの'logs'コレクションにそれらすべてを格納することも可能でしょう。例えば，
アトミックな操作 - Docs-Japanese - 10gen Confluence
MongoDBは、 一つのドキュメント でのアトミックな操作をサポートしていますが、伝統的なロックと複雑なトランザクションを以下のいくつかの理由からサポートしていません。 まず、分散された環境で、ロックの情報を分散させるのは、コストが高く、そして遅いです。MongoDBの目標は、軽く速いことです。 私たちはデッドロックという考えかたが嫌いです。 そういうことがない、シンプルでわかりやすいシステムにしたいです。 私たちは、MongoDBを、リアルタイムな問題に対して、よく動くようにしたいです。オペレーションが大量のデータをロックしてしまうと、長い時間、軽い小さなクエリーを止めてしまうことがあります。("リアルタイム"に関しては、MongoDBはまだ完璧だとは言えません。しかし、ロックがあると、それをさらに難しくします。) MongoDBは、一つのドキュメントをアトミックに操作するための、下記
Shardingの設定 - Docs-Japanese - 10gen Confluence
based on v72 (2010/12/29 更新) - オリジナル Introduction このドキュメントでは基本的なshardingクラスターのセットアップ手順を紹介していきます。shardingクラスターは最小構成でも3つのコンポーネントが必要です； 1. 2つ以上のshard 2. 1つ以上のconfigサーバー 3. mongos ルーティングプロセス テストの目的では、上記の全てのコンポーネントを1つのサーバーに集約させることも可能です。プロダクション環境では、いくつかのserver configurationsを持つことが出来ます。 1度、shards・configサーバー・ mongos プロセスが起動すれば、shardingを可能にするためにconfigurationを行いますが、簡単な一連のコマンドを発行するだけで済みます。ここまでのクラスターの構築が完
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
モニターと診断 - Docs-Japanese - 10gen Confluence
HTTPインターフェース - Docs-Japanese - 10gen Confluence
シェル リファレンス - Docs-Japanese - 10gen Confluence
高度なクエリー - Docs-Japanese - 10gen Confluence
クエリーとカーソル - Docs-Japanese - 10gen Confluence
シェル 概要 - Docs-Japanese - 10gen Confluence
findAndModifyコマンド - Docs-Japanese - 10gen Confluence
集約 - Docs-Japanese - 10gen Confluence