時系列データとMongoDB2.4の新機能Hash based sharding - 中年engineerの独り言 - crumbjp
実は数年前（MongoDB 1.6〜1.8の時期）にログをリアルタイムに全てmongodbに叩き込んで期間毎に解析する仕組みを作ろうとして挫折した事がある。 理由は幾つかあったのだが主に cappadコレクションでは解析時の負荷とログ投入負荷が重なってしまう。 → 最終的には書き込みが負けてoplogが溢れる。 時系列カラムをshard keyにするとchunk migrationが辛すぎる。 そもそもshardingの信頼性が・・・ という理由だった。 今ならストレージエンジンが早くなったし再挑戦しても良いかもしれない。 ログは非同期に準リアルタイムに拾って投入。 出力元＋時間でshard key。 なるべくグループコミットの効率が上がる塊を作る。 とか、、 お題 ともかく、今回は 時系列データを投入した時chunk migrationがどう動くのか？ の話。 そもそも時系列カラムをsh
MongoDBの薄い本
2.6対応版 MongoDBの薄い本 The Little MongoDB Book Karl Seguin 著 / 濱野 司 訳 i 目次 目次 i この本について iii ライセンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii 著者について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii 最新バージョン . . . . . . . . . . . . . . . . . .
MongoDBが適さないケース - 中年engineerの独り言 - crumbjp
> 原文(Why MongoDB is a bad choice for storing our scraped data) 私自身はMongoDBを推進する立場なのだが、確かにMongoDBに適さないケースはある。 闇雲に推進しても結局は全員がアンハッピーになるので、この様なネタもどんどん紹介していこうと思う。 この記事はMongoDBを徹底的に使い尽くしたエンジニアが書いている様で状況が良く解った。 ちょっと難しい所もあるので要点を意訳して、軽く解説を書いてみる。 （もちろん是非原文で読むのをお勧めする） 状況 最初はMongoDBでうまく動いていたが、だんだん苦労が増えてきて 元々のアーキテクチャを刷新するタイミングでMongoDBから別のプロダクトに乗り換える事にした。 システムの規模 詳しく書かれていないが、１ノード辺り数TBとあるのでSharding環境ではないかと思われる。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
