n-segaのブックマーク - はてなブックマーク

転職しました。。 - 中年engineerの独り言 - crumbjp

退職エントリーが流行の様なので・・・９月末付けで楽天を退社しました。楽天は、６年間お世話になりました。非常に働き易く良い会社だったと思います。それまでは、長くても同じ職場には２年は居つかなかったのですが特に大きな不満もなく、居心地が良すぎてツイツイ長居してしまった。今までの職場ではやりたい事はスグやり終えてしまい、退屈でした。楽天には沢山ありましたね。。やり切れないほどに・・・楽天台湾進出プロジェクト、インフォシークの大改修など数多くの得がたい機会と経験をさせて頂き感謝しております。さて、、では何故退社したのか？一言でというと『私にとって楽天は大きく成り過ぎた』大きな会社は必然的に動きが鈍くなります。これは『誰が悪い』とか、『どうしたら良い』とかの問題ではありません。組織が大きくなれば、それなりにガバナンスコストが上がりそのコストが時間に跳ね返るというだけの

n-sega 2013/10/02

おお！！

リンク

MongoDB 2.4 の性能徹底評価（Memory vs DISK） - 中年engineerの独り言 - crumbjp

大体欲しいデータは揃ったのと、Mongo DBの気持ちが解ってきたのでMongo DB2.4の性能調査は今回で最後の予定実は前回Mongo DB 2.4 の性能徹底評価（レコード長による評価）のFETCHバイト数（1.5GB）実は今回のOn-memoryデータ vs DISKリードに繋げる事を意図した大きさだった。システムの2GBメモリに収まるだろう。と・・・しかし、、測れど測れど、意図した通りの結果にならない・・・それで気付いた。インデックスの大きさを勘違いしていたのだ。 Mongo DBのインデックスは単なるコレクションでは無いようだ！ 1億件の数値型インデックスは2.3GBにもなる。という訳で、1億件のコレクションのインデックスはそもそもメモリーに入らない。。１ドキュメント辺り25〜26byte インデックス数値型８バイト＋ドキュメントへのポインタ８バイト＋メタ情報？ _i

n-sega 2013/06/10

リンク

MongoDBが適さないケース - 中年engineerの独り言 - crumbjp

> 原文(Why Mongo DB is a bad choice for storing our scraped data) 私自身はMongo DBを推進する立場なのだが、確かにMongo DBに適さないケースはある。闇雲に推進しても結局は全員がアンハッピーになるので、この様なネタもどんどん紹介していこうと思う。この記事はMongo DBを徹底的に使い尽くしたエンジニアが書いている様で状況が良く解った。ちょっと難しい所もあるので要点を意訳して、軽く解説を書いてみる。（もちろん是非原文で読むのをお勧めする）状況最初はMongo DBでうまく動いていたが、だんだん苦労が増えてきて元々のアーキテクチャを刷新するタイミングでMongo DBから別のプロダクトに乗り換える事にした。システムの規模詳しく書かれていないが、１ノード辺り数TBとあるのでSharding環境ではないかと思われる。

n-sega 2013/05/20

リンク

MongoDB 2.4 の性能徹底評価（レコード長による評価） - 中年engineerの独り言 - crumbjp

前回のMongo DB 2.4 の性能徹底評価の反響が大きかったので続編。今回の調査対象ドキュメントサイズ毎の性能を評価する。今回の検証用にベンチを書いた。性能見積りにも使えると思うので、紹介しておきます。 Mongo DB-JP/mongo_bench 今回の検証も、Sakura VPS 2G で行った。専用環境ではないので、ある程度まわりの影響を受けている。（何度もベンチを取って極力排除はしたが、、）また、記事に載せた以外にも色々と検証しており、その結果も少し混ざっていたり。。オンメモリデータの処理が高速な事は解っているので今回の検証の肝は『ディスクアクセス』 Mongo DBはメモリ以上のデータを扱う為のプロダクトなのでなるべく性能が出ない様な条件＝ワーストケースを狙った。 2GBメモリに対して40GBのデータを扱い、データ全体を万遍なく使うようなクエリーを発行する。評

n-sega 2013/05/16

リンク

MongoDB 2.4 の性能徹底評価 - 中年engineerの独り言 - crumbjp

まとめ超長くなったのでまとめを上に持ってきた。巷で言われているチューニングは結構嘘が多い事が解ってきた。ツール等 workingSet Analyzer は信用ならない。（overSecondsはまあ良い） mongoperfの値は完全に参考にならない。 insert mongoperfの値はinsert性能と関連しない。（何を測ってるんだ？）カラムのプリアロケーションによるUPDATE時のデータ肥大化回避($setOnInsert)はMUST。クリティカルな時間帯にストレージファイル(2GB)の生成を避けるチューニングの効果は懐疑的。レコードプリアロケーション・チューニングは頑張る価値が無い。(むしろ逆効果) update 上記の通り必ずin-placeになるようにする。 paddingFactorが動くようだとお話にならない性能劣化 remove かなり高速。全件削除の場

n-sega 2013/04/19

リンク

MongoDB2.4 リリース（和訳） - 中年engineerの独り言 - crumbjp

Mongo DB 2.4 released を和訳（＆少々所感）しました。和訳 The Mongo DB Engineering Team is pleased to announce the release of Mongo DB 2.4. This is the latest stable release, following the September 2012 release of Mongo DB 2.2. This release contains key new features along with performance improvements and bug fixes. We have outlined some of the key features below. For additional details about the release: 2.4 release