『もう二度と、絶対にMongoDBを使うべきじゃない理由』というのがあるらしい - 中年engineerの独り言 - crumbjp
記事 https://fa-works.com/blog/why-you-should-never-ever-ever-use-mongodb なかなか香しいな。 というよりコイツ他のブログも結構ヒドイｗ とりあえず不満をぶちまけるタイプのようだ。 で、、事の本質はプロダクトの設計がちゃんと出来ない人はどんな場合でも選択を間違えるという事だ。 実際MongoDBは使いどころがかなり限られている。 MongoDBが得意なケース"以外"では絶対MongoDBを使ってはならない WriteConcernはあくまでAdditionalな機能であって本来やりたい事では無い。（RDBMSなら２フェーズコミットだぜ？） 実際、最近追加されたReadConcernもヒドイ実装である。 殆どのケースではORMが完備してるフレームとMySQLを使うのが鉄板なのは間違いない。 じゃあ具体的にいつ使うのか？という
Rubyコンテキストスイッチの不思議 - 中年engineerの独り言 - crumbjp
仕事上、ROMAに関わっているので、稀にはRubyもやります。 今回検証に使ったソースは此方 https://github.com/crumbjp/Personal/tree/master/study/ruby こんな感じで動くはずです gem install eventmachine bash run.sh Rubyスレッドのコンテキストスイッチの話 Rubyのスレッドはご存じの様に、1.8系は疑似スレッド、1.9系ではネイティブスレッドだけれど並列処理はしない（逐次実行）実装となっている。 疑似スレッド(green threads) OS上のスレッドを利用せずメインスレッドをRubyインタプリタで切り替えている。 本当の意味での並列処理を行わない。 コンテキストスイッチはsignalがトリガとなっており、特定出来ないタイミングで切り替わる（※と思っていた） しかし特にExtension
転職しました。。 - 中年engineerの独り言 - crumbjp
退職エントリーが流行の様なので・・・ ９月末付けで楽天を退社しました。 楽天は、６年間お世話になりました。 非常に働き易く良い会社だったと思います。 それまでは、長くても同じ職場には２年は居つかなかったのですが 特に大きな不満もなく、居心地が良すぎてツイツイ長居してしまった。 今までの職場ではやりたい事はスグやり終えてしまい、退屈でした。 楽天には沢山ありましたね。。やり切れないほどに・・・ 楽天台湾進出プロジェクト、インフォシークの大改修など 数多くの得がたい機会と経験をさせて頂き感謝しております。 さて、、では何故退社したのか？ 一言でというと 『私にとって楽天は大きく成り過ぎた』 大きな会社は必然的に動きが鈍くなります。 これは『誰が悪い』とか、『どうしたら良い』とかの問題ではありません。 組織が大きくなれば、それなりにガバナンスコストが上がり そのコストが時間に跳ね返るというだけの
MongoDBが適さないケース - 中年engineerの独り言 - crumbjp
> 原文(Why MongoDB is a bad choice for storing our scraped data) 私自身はMongoDBを推進する立場なのだが、確かにMongoDBに適さないケースはある。 闇雲に推進しても結局は全員がアンハッピーになるので、この様なネタもどんどん紹介していこうと思う。 この記事はMongoDBを徹底的に使い尽くしたエンジニアが書いている様で状況が良く解った。 ちょっと難しい所もあるので要点を意訳して、軽く解説を書いてみる。 （もちろん是非原文で読むのをお勧めする） 状況 最初はMongoDBでうまく動いていたが、だんだん苦労が増えてきて 元々のアーキテクチャを刷新するタイミングでMongoDBから別のプロダクトに乗り換える事にした。 システムの規模 詳しく書かれていないが、１ノード辺り数TBとあるのでSharding環境ではないかと思われる。
MongoDB 2.4 の性能 徹底評価 - 中年engineerの独り言 - crumbjp
まとめ 超長くなったのでまとめを上に持ってきた。 巷で言われているチューニングは結構嘘が多い事が解ってきた。 ツール等 workingSet Analyzer は信用ならない。（overSecondsはまあ良い） mongoperfの値は完全に参考にならない。 insert mongoperfの値はinsert性能と関連しない。（何を測ってるんだ？） カラムのプリアロケーションによるUPDATE時のデータ肥大化回避($setOnInsert)はMUST。 クリティカルな時間帯にストレージファイル(2GB)の生成を避けるチューニングの効果は懐疑的。 レコードプリアロケーション・チューニングは頑張る価値が無い。(むしろ逆効果) update 上記の通り必ずin-placeになるようにする。 paddingFactorが動くようだとお話にならない性能劣化 remove かなり高速。 全件削除の場
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
