MongoDB 2.4 の性能 徹底評価（レコード長による評価） - 中年engineerの独り言 - crumbjp
前回のMongoDB 2.4 の性能 徹底評価の反響が大きかったので続編。 今回の調査対象 ドキュメントサイズ毎の性能を評価する。 今回の検証用にベンチを書いた。 性能見積りにも使えると思うので、紹介しておきます。 MongoDB-JP/mongo_bench 今回の検証も、Sakura VPS 2G で行った。 専用環境ではないので、ある程度まわりの影響を受けている。（何度もベンチを取って極力排除はしたが、、） また、記事に載せた以外にも色々と検証しており、その結果も少し混ざっていたり。。 オンメモリデータの処理が高速な事は解っているので 今回の検証の肝は『ディスクアクセス』 MongoDBはメモリ以上のデータを扱う為のプロダクトなのでなるべく性能が出ない様な条件＝ワーストケースを狙った。 2GBメモリに対して40GBのデータを扱い、データ全体を万遍なく使うようなクエリーを発行する。 評
MongoDBが適さないケース - 中年engineerの独り言 - crumbjp
> 原文(Why MongoDB is a bad choice for storing our scraped data) 私自身はMongoDBを推進する立場なのだが、確かにMongoDBに適さないケースはある。 闇雲に推進しても結局は全員がアンハッピーになるので、この様なネタもどんどん紹介していこうと思う。 この記事はMongoDBを徹底的に使い尽くしたエンジニアが書いている様で状況が良く解った。 ちょっと難しい所もあるので要点を意訳して、軽く解説を書いてみる。 （もちろん是非原文で読むのをお勧めする） 状況 最初はMongoDBでうまく動いていたが、だんだん苦労が増えてきて 元々のアーキテクチャを刷新するタイミングでMongoDBから別のプロダクトに乗り換える事にした。 システムの規模 詳しく書かれていないが、１ノード辺り数TBとあるのでSharding環境ではないかと思われる。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
