Markdownじゃなきゃダメな体に・・・
引っ越して来ました。。。
もうMarkdownじゃなきゃやってらんないよね。。
へー色サポートしてるのね
ES6 transpiler すると壊れる問題
webpack + babel で一見ちゃんとtranspilerできるのだが、動かしてみるとエラる。
Uncaught TypeError: Cannot read property 'TYPED_ARRAY_SUPPORT' of undefined.
色々調べたが解決方法には辿り着かなくて何とかひねり出したのがこれ。
plugins: [ new webpack.DefinePlugin({ global: {} }),
capistrano-bundle_rsync の :repo_tree がちゃんと動かない・・・
こうじゃないと動かないと思うんだが、これだけ使われてるライブラリでこんな５分で治る奴が放置されているとも思えんのだ・・・
だれか教えて偉い人！！
https://github.com/sonots/capistrano-bundle_rsync/pull/15/files
MongoDB の チューニンガソン環境を作った。
例のGoogle compute engine ６０日トライアル の$300 分をどう使おうか・・・と考えていたのだが、MongoDBのチューニンガソンに使えるんじゃないか！？と思って週末に一気に作ってみた。
いきなり超負荷を掛けると、色々問題が起きるので、Stage1 ~ 4 まで別けて、ある程度チューニングが進んでから、だんだん負荷が掛かる構造にした。
| stage1 | 5秒以内に一連のクエリーが完了すること。プロファイルの取り方と基本的なindex知識 |
| stage2 | 5秒以内に一連のクエリーが完了すること。複雑なindexが張れるか？ |
| stage3 | 2~3秒の間で難易度を調整中。かなり突っ込んだindexを張れないとクリア出来ない |
| stage4 | 最終ステージ。負荷が一気に増え、クリアではなくスコア（qps）での競争。MongoDB周りならなんでもあり。 |
| stage5 | 構想段階。アプリ側も含めたチューン |
恐らくstage3 まで行く人は既に普通には困らないだけの知識を持っているし、stage3 をクリアする人はマスターレベルだと思われる。
一旦、何人かにβテストの挑戦をして貰いたい。
興味がある人はfacebookで声を掛けて欲しい！！！！
SSHが出来るホストをお渡しして好きにチューンして貰う感じになります~
mongosが腐る・・・
mongosの後ろのshardでstepdownが起きたときにmongosが追随せずに以降のクエリーが全て刺さり続けることがある。
こうなるともう自動で復活はしないようだ。
すべてのmongosが腐る訳ではなく、stepdown時に高負荷だったmongosが腐る傾向にある。
shardConnPoolStats コマンドではmasterが変わった事が認識できているので、何かしらのrace condition のバグがあると思われる。
少なくとも2.6系,3.0系で起きる。3.2系は不明だが恐らく起きるだろう。
本番クラスの負荷がかからないと再現しないので原因特定もかなり覚悟が要る。。。
とりあえず、監視スクリプト書いて自動再起動させる事にするが。。
jiraにも上がってなさそうだし、こんなバグ誰も気づかないんだろうか・・・
MongoDBクラスタ間の同期
node-mongosync
https://www.npmjs.com/package/node-mongosync
ステージング環境へのデータ同期や、MongoDB引っ越しの際に便利。
そうそう引っ越さないけど・・
以前 mongoshellで実装したものの焼き直しだ。
node-native-driverでは、tailable cursor の closeが検知出来たり、oplogの読み込みと同期先への書き込みが非同期に同時進行出来るため、性能的に有利だった。
反面CPU処理能力は若干劣るため、フックを差し込む機構は今の所諦めている。
あとnpmを使えるので導入が楽だ。
これが一番大きな理由かもしれない。
npmjs のREADME.md の表示がやたら汚いのがつらい・・・ githubの方みてね・・・
『もう二度と、絶対にMongoDBを使うべきじゃない理由』というのがあるらしい
記事
https://fa-works.com/blog/why-you-should-never-ever-ever-use-mongodb
なかなか香しいな。
というよりコイツ他のブログも結構ヒドイｗ
とりあえず不満をぶちまけるタイプのようだ。
で、、事の本質はプロダクトの設計がちゃんと出来ない人はどんな場合でも選択を間違えるという事だ。
実際MongoDBは使いどころがかなり限られている。
MongoDBが得意なケース"以外"では絶対MongoDBを使ってはならない
WriteConcernはあくまでAdditionalな機能であって本来やりたい事では無い。（RDBMSなら２フェーズコミットだぜ？）
実際、最近追加されたReadConcernもヒドイ実装である。
殆どのケースではORMが完備してるフレームとMySQLを使うのが鉄板なのは間違いない。
じゃあ具体的にいつ使うのか？というと
Dirty read が許され、且つ、Readが支配的な場合
だ。
性能面に関しては、スタンドアローン型のストレージに劣る。
これはレプリケーション機構があるので（例えその機能を切ったとしても）そのオーバーヘッドに拠るものが大きい。但し実装も良くない。
しかしPostgreSQLねぇ・・・運用するんだ・・・がんばれ〜
大丈夫！イザとなったらRedShiftがあるさ。。
