2015/11/12開催の 【ヒカ☆ラボ】Node.js×MongoDBでのサービス運用が1時間で分かる！3年間の運用での失敗談とその対策に加えて、運用のハマりどころやツールついてもお話します！ 株式会社サイバーエージェント 橋本 純様の資料です。Read less
Node.js×mongo dbで3年間サービス運用してみた話
2015/11/12開催の 【ヒカ☆ラボ】Node.js×MongoDBでのサービス運用が1時間で分かる！3年間の運用での失敗談とその対策に加えて、運用のハマりどころやツールついてもお話します！ 株式会社サイバーエージェント 橋本 純様の資料です。Read less
MongoDBのSharding機能で遊ぶ - 個人的なまとめ
MongoDBを使っているので、自分でも組めなければと思い勉強中。オライリーでスケーリングMongoDBが電子書籍で売っていたので迷わず購入。 とりあえずはReplicaSetをせずに1台のSharding構成でいってみましょう。 まず、Shardingというのはなにか？というと データを複数サーバへ分割する データの分割はMongoDBがよしなにやってくれる 分割したデータは状況に応じて各Shardを移動する MongoDB利用者(アプリ)は複数サーバを意識しなくてよい ということです。 レプリケーションが同じデータのコピーを複数DBへ持つのに対して、Shardingは違うデータを複数DBへ持ちます。よって、普通の運用はSharding＋ReplicaSet(レプリケーション)の構成となります。 で、今回の構成は下のようにしました。これをAWSのマイクロインスタンス1台で組んでいます。新
MongoDB 2.4 の性能 徹底評価 - 中年engineerの独り言 - crumbjp
まとめ 超長くなったのでまとめを上に持ってきた。 巷で言われているチューニングは結構嘘が多い事が解ってきた。 ツール等 workingSet Analyzer は信用ならない。（overSecondsはまあ良い） mongoperfの値は完全に参考にならない。 insert mongoperfの値はinsert性能と関連しない。（何を測ってるんだ？） カラムのプリアロケーションによるUPDATE時のデータ肥大化回避($setOnInsert)はMUST。 クリティカルな時間帯にストレージファイル(2GB)の生成を避けるチューニングの効果は懐疑的。 レコードプリアロケーション・チューニングは頑張る価値が無い。(むしろ逆効果) update 上記の通り必ずin-placeになるようにする。 paddingFactorが動くようだとお話にならない性能劣化 remove かなり高速。 全件削除の場
MongoDBの単体性能（前編）
はじめに MongoDBは使い始めるのが簡単で、インターフェースもJSONを出し入れするだけとシンプルなため、DBMSに関して知識が少ないアプリ開発者でも簡単にアプリを開発することができます。サクッとアプリを作り、サンプルデータで動作を確認し、いざ本番データで動かしてみたら「あれ？思った以上に性能が出ない」なんてことはないでしょうか？ 「MongoDBはNoSQLなんだから速い」という思い込みは危険です。MongoDBをはじめとするNoSQLは「水平分散(シャーディング)が得意で、水平分散すれば単体構成よりも速い」というのは事実ですが、単体構成が速いかどうかはチューニング次第です。また「NoSQLなんだからRDBMSより速い」という考えもよくありません。単体性能を比較した場合、どちらが速いかは単純には比較できません。 「じゃあ、性能を上げるために水平分散をしよう！」と考えるかもしれませんが
MongoDBのインデックス２ - Carpe Diem
概要 MongoDBのインデックスにはIndex IntersectionやCovered Indexなんてのもあるので調べてみました。 環境 Ubuntu 14.04 MongoDB 2.6.8 Index Intersectionとは １つのクエリーで２つのインデックスを使ってくれる機能で、より効率的にクエリーを処理できる というもの。 簡単に言うと複合インデックスが必要なクエリをMongoDB側でうまくインデックスを組み合わあわせてよろしくやってくれる機能といった感じでしょうか。 基本的な使い方 db.collection.find({a: xxx, b: yyy}) といったクエリを投げるとき、最適なインデックスは ensureIndex({a: 1, b: 1}) ですが、Index Intersectionがあると ensureIndex({a: 1}) ensureIndex
第13回 MongoDBの性能 | gihyo.jp
はじめに 前回、前々回とMongoDBの非機能面に着目してきましたが、今回も非機能に着目して、MongoDBの処理性能について説明します。まず前半では、MongoDBの動作の中で処理性能に影響を与える動作を説明します。それをふまえた上で、後半では処理性能をどのように上げるかを説明します。 なお、今回はMongoDBを単体で使った場合の処理性能を考えています。レプリケーションやシャーディングを行った状態の処理性能については対象外とさせていただきます。 処理性能にかかわるMongoDBの動作 データアクセス MongoDBがどのようにデータにアクセスするかは、MongoDBの処理性能を考える上で非常に重要です。 MongoDBではデータファイルを仮想メモリにマッピング（Linuxではmmapという機能を利用）し、MongoDBのプロセスは仮想メモリにアクセスします。図1のように、アクセスするデ
もう二度と、絶対にMongoDBを使うべきじゃない理由
MongoDBは悪だ。なぜならそれは… …データを無くす（ソース：1、2）。 …実際、長期間、デフォルトでエラーを無視し続け、何があってもすべての単一書き込みが成功したとみなした（ 32ビットのシステムで3GBかそこらを使用したら、MongoDBの制限によって何の警告もなしに全データを失うことになった）。 …宣伝していたユースケースでですら遅く、これが早いと主張するには完全に証拠に欠けている（ソース：3、4）。 …ほぼ全てのユースケースで、暗黙のスキーマという悪しき習慣を強要してくる（ソース：4）。 …ロッキングに問題がある（ソース：4）。 …セキュリティの問題になるくらい、応答時間が酷く遅い。求めてきた人全員に認証なしで全データをさらしてしまうという危険なデフォルト設定をパッチするのに2年かかった（ソース：5）。 …ACID特性に準拠していない（ソース：6）。 …拡張やメンテナンスをする
MongoDBの集計機能が便利過ぎて泣けてくるお話し - Y's note
MongoDBイン・アクション 作者: Kyle Banker,Sky株式会社玉川竜司出版社/メーカー: オライリージャパン発売日: 2012/12/14メディア: 大型本購入: 5人 クリック: 55回この商品を含むブログ (4件) を見る MongoDB集計機能 CentOSでNginxのログをFluentdを使ってMongodbにリアルタイムで格納する - Yuta.Kikuchiの日記 時給3000円のCEOと揶揄されている@yutakikucです。今日は簡単にMongodbのログ集計機能を紹介します。機能が豊富過ぎて泣けてくるんで、ログ解析する人は是非使ってみて下さい。FluentdでMongodbにNginxのLogを流し込む設定は上のエントリーを参照して下さい。次回はAggregationFramework/MapReduce周りについて触れたいと思います。 泣ける話 : 集
第7回 GridFS─大容量のファイルをMongoDBに保存する仕組み | gihyo.jp
GridFSの概要 MongoDBに保存できるドキュメントのサイズは、16Mバイトまでという制限があります。一般的なテキストデータを保存するには十分なサイズですが、巨大なテキストデータや動画などのバイナリデータを保存する用途では、16Mバイトを超える場合が出てきます。MongoDBに16Mバイト以上のファイルを保存したい場合、GridFSというインターフェースを使用します。GridFSを使用することにより、データを複数に分割[1]して保存することが可能となります。 今回はMongoDBでサイズの大きなファイルを扱う仕組みである、GridFSについて説明します。 図1 GridFSの概要図 ファイルをデータベースで管理するメリット ところで、ファイルをデータベースで管理することでどのようなメリットがあるのでしょうか。 多くのシステムでは、画像／音声／動画などサイズの大きなバイナリファイルは、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MongoDB〜その性質と利用場面〜