サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
コーヒー沼
crumbjp.hateblo.jp
経緯 app.wercker.com 今までwercker を使っていたのだが、数年前は良いサービスだったのにOracleなんかに買われたせいで最近はインスタンスが目に見えて遅かったり、不安定だったりやってられないので、引っ越しを検討していた。 比較したサービス wercker 最近明らかに遅いインスタンスが混ざり込む様になった (超相乗り状態?) 並列実行数=2 1vCPU 2GB RAM 無料プランのみ?? 情報が出てこない・・・ CircleCI circleci.com 言わずと知れた最大手。CI業界の基準 ピュアなコンテナ環境ではなさそう(chrootっぽい何か?) その影響か、ホストのカーネルの問題か解らないが、稀にCircleCI無いでしか起きないSEGV等が起きたり互換性周りの面倒事が起きる。 実行環境のリソースは細かく選択でき、料金が異なる。 料金はクレジットの単位で設定
最近、根詰めて触っているので詳しくなって来たついでに解説記事を書いてみた Faissとは Facebookが開発しているC++NNS(Nearest neighbor search)エンジン 手に入るライブラリの中では最高峰の速度 高次元ベクトルで問題になりがちなメモリー問題に対応できる機能群 億を超える数のベクトルを想定した多種のインデックスアルゴリズム これらを組み合わせる事で柔軟に用途にマッチしたトレードオフ戦略が取れる 簡単に言えば、どんなケースでも利用できる超柔軟なライブラリである。 NNSとANN(Approximate nearest neighbor)の超基礎 NNS 高次元のベクトルでは、あるベクトル群から、任意のベクトルに近いベクトルを抽出する場合には、総当りが第一選択肢だ。 低次元ならば、グリッドやハッシュなどの工夫によって効率良く抽出できる。高次元ではこれらの工夫は
問題 構成 突発的に、1台のサーバーで5秒間だけ、502 Bad Gateway が数百〜数千出て困った。(②の部分) nginx.conf proxy_connect_timeout 5; 5秒はnginx設定によるモノなのだろうが、なんで一瞬だけ出るのか全然解らなかった。 nginxのerror.log にはこう出てて、これってproxy_passの設定ミスってる時の奴だよな。。と。。(③の部分) /var/log/nginx/error.log upstream prematurely closed connection while reading response header from upstream, client: 172.XX.XX.XX, server: _, request: "GET / HTTP/1.1", upstream: ... 一瞬、nginx -> no
例のGoogle compute engine 60日トライアル の$300 分をどう使おうか・・・と考えていたのだが、MongoDBのチューニンガソンに使えるんじゃないか!?と思って週末に一気に作ってみた。 mongo-tuningason.crumb.jp" いきなり超負荷を掛けると、色々問題が起きるので、Stage1 ~ 4 まで別けて、ある程度チューニングが進んでから、だんだん負荷が掛かる構造にした。 stage1 5秒以内に一連のクエリーが完了すること。プロファイルの取り方と基本的なindex知識 stage2 5秒以内に一連のクエリーが完了すること。複雑なindexが張れるか? stage3 2~3秒の間で難易度を調整中。かなり突っ込んだindexを張れないとクリア出来ない stage4 最終ステージ。負荷が一気に増え、クリアではなくスコア(qps)での競争。MongoDB周り
記事 https://fa-works.com/blog/why-you-should-never-ever-ever-use-mongodb なかなか香しいな。 というよりコイツ他のブログも結構ヒドイw とりあえず不満をぶちまけるタイプのようだ。 で、、事の本質はプロダクトの設計がちゃんと出来ない人はどんな場合でも選択を間違えるという事だ。 実際MongoDBは使いどころがかなり限られている。 MongoDBが得意なケース"以外"では絶対MongoDBを使ってはならない WriteConcernはあくまでAdditionalな機能であって本来やりたい事では無い。(RDBMSなら2フェーズコミットだぜ?) 実際、最近追加されたReadConcernもヒドイ実装である。 殆どのケースではORMが完備してるフレームとMySQLを使うのが鉄板なのは間違いない。 じゃあ具体的にいつ使うのか?という
そろそろ3.2も手を付けようと思うので、検証がてらつらつらと。。 リリースノート https://docs.mongodb.org/manual/release-notes/3.2/ 非常に丁寧な日本語訳があるので、こちらもどうぞ http://qiita.com/fetaro/items/cd570d70623b58b5deef WiredTiger as Default まあ規定路線なので、特に気にする必要なし。 Replication Election Enhancements Primaryが落ちた時の検知が早くなった。 どういうシチュエーションでどの位早くなるのかはまだ検証してない。 少なくとも今迄の落ち認定10秒をカスタマイズ可能になった。 その他色々timeout値が弄れるようになった様だが、これはまだ実験段階なんだろう。と読む事もできる。 要注目 Sharded Clust
AWSインスタンスの選定 AWSインスタンスタイプ一覧 以下のインスタンスボリュームが付随しているプロダクトラインが候補になる。 個人的にはi2.xxx が好みである。 r3.xxx メモリ最適化インスタンス i2.xxx SSD容量最適化インスタンス ただし、インスタンスボリュームはスナップショットが取れず、揮発性なので取り回しが悪い。 Provisioned IOPS (SSD) ボリュームも検討候補になるが、高くつく事になるのでお金持ちの人用。。 バックアップ戦略 流石にバックアップを全く取らずに運用する事は出来ないので 以下様にレプリカセット構成を組み、バックアップを取る。 Primary: i2.xxx Secondary: i2.xxx Secondary(hidden): 適当なインスタンス + SSD 最後のノードはバックアップ専用なので、SSD以外は非力出よい。 ただしあ
ご無沙汰してます。 最近全然更新出来てない訳ですが、MongoDBに愛想が尽きて、離れていた訳ではありません。 むしろガッツリ嵌ってます。。 最近は MongoDB3 系 WiredTiger を使いながら頑張っている訳ですが・・・ キリの良い所で書こうと思っていたのに、メドが立たないので近況だけでも書いておこうかと思った次第。。 で、、mongo3... コイツすぐ落ちる!! まあ、普通にメモリーリークですが、、ちょっと目を離すと Tasks: 169 total, 1 running, 168 sleeping, 0 stopped, 0 zombie %Cpu(s): 12.4 us, 0.7 sy, 0.0 ni, 86.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 62916396 total, 62567524 used, 3488
遂にMongoDB 3.0 が正式リリースされました!! 例によってリリースノートを斜め読みします。 http://docs.mongodb.org/master/release-notes/3.0/ が、、最初に一言で纏めると、まあ、、 目玉機能はロックレベルの話だけですよー でわ。。 Pluggable Storage Engine AP 以下の2つからストレージエンジンを選べる。 MMAPv1 これまでのストレージエンジン。デフォルト WiredTiger 3.0から追加されたストレージエンジン WiredTiger MongoDBの全ての機能をサポートしている。 MMAPv1とフォーマットが違うので既存のアップデートの場合、移行する際に色々必要。 ドライバも最新に上げないとダメ。 ドキュメントレベルロックが可能!! touchコマンドはサポートしてない MMAPv1 Improve
だいぶ空いてしまったが、久々の更新! Aggregate周りを色々検証したので載せておく。 基本的なTAG構造。 TAGを扱う上でオーソドックスなクエリーと性能を調査。 性能は、people 2000万件、hobies 3200万件、完全ランダムデータで計測。 月数千円で手に入るコンピューティングリソースを使ってます。 Model Mike :性別:男 :趣味: 映画、テレビ Cate :性別: 女 :趣味: テニス Bob :性別: 男 :趣味: 映画、テレビ、テニス Data RDBMSではこんな感じの正規化をする。 people _id name sex 1 Mike male 2 Cate female hobbies pid name 1 TV 1 cinema 2 tenis 3 TV 3 tenis BSON 一方MongoDBではこんな感じで持つだろう { _id: 1,
MongoDB 2.6 からIndex intersectionという機能が追加された。 1つのクエリーで2つのインデックスを使う(かもしれない)機能で、より効率的にクエリーを処理できる。 (どう効率的なのか?はこのへんが詳しい) さて、じゃあ実際に見てみようというのが今回の趣旨。 元データ 国土地理院が公開している住所情報が手元にあったのでこれを使うことにした。 大体1000万件/4GB弱のデータ。 > db.block_master.stats().count 11700898 > db.block_master.stats().size 3713899792 > db.block_master.findOne() { "_id" : ObjectId("52b8378dab3de2fd4abb193f"), "full" : "北海道 札幌市中央区 南七条西十一丁目 1281", "
レプリカセット間レプリケーション MongoDBではレプリカセットを跨いでデータを同期する手段が無い。 そもそもレプリカセット自体が冗長構成を目的としているので設計に組み込まれていないのだろう。 しかし現実は Staging環境や、PV系/集計系の分離など、用途はある。 今は、レプリカセットのslaveを1台切り離してそこで何かするしかない。 フレッシュデータじゃないし運用も面倒。 monmo-repl https://github.com/monmo/monmo-repl なければ作れば良いので作った。 oplogベースの同期を行う。-s で指定したレプリカセットのPRIMARYのoplogを読み、-d で指定したレプリカセットに反映していく。 PRIMARYダウン時の挙動など、まだ未テストの部分は多いが 『とりあえず動く』 程度の完成度。 例 ReplicaSet1 =sync=> R
2.6.1(人柱バージョン)にチャレンジ 2.4.4 => 2.6.1 バージョンアップ手順 今回データファイルには互換性があるので超簡単 ディレクトリ構成 /usr/local/mongo |- bin -> mongodb-linux-x86_64-2.4.4/bin |- mongodb-linux-x86_64-2.4.4 |- data |- logs |- conf |- mongod.conf 手順 Download & extract $ cd /tmp $ wget http://fastdl.mongodb.org/linux/mongodb-linux-x86_64-2.6.1.tgz $ cd /usr/local/mongo $ tar xzvf /tmp/mongodb-linux-x86_64-2.6.1.tgz 既存のmongodを落とす $ kill `c
ご存知の通りMongoDB2.6がリリースされました! 相変わらず乱文で解説!! Aggregation Enhancements Aggregationが強化された。 db.collection.aggregate() がカーソルを返却するようになった 今まで最終結果には64MBの制約があったが、解消されたようだ。 というかそれが普通。。。 パイプラインがexplainをサポート 今までは感覚で是非を判断していたので嬉しい改善! ディスクソートが効率的になった $out オペレータで指定のコレクションに結果出力が可能 今までは結果をforで回して入れなおしてたのでこれも便利。 $redact でパイプライン中にデータの微修正ができる あんまり使う機会が思い当たらない。。 多分この様な用途でMongoDBを使うこと自体が詰んでる。 新しいoperator $let, $map $liter
MongoDB Aggregation FWシリーズの最後 - Aggregation FW機能、SQLとの比較 - Aggregation FWの特徴と地雷 - (今回)MongoDB vs MySQL性能比較 Aggregation FWについては、大体、把握している情報を吐き出したと思う。 MongoDBのRDBMSライクな機能について性能を比較してみた。 その前に。。 NoSQL 基本的には、RDBMSから機能を削り、別の部分に特化することで ハイパフォーマンスを実現しながらも実用に耐える品質に仕上げたプロダクトである。 MongoDB vs Other NoSQL MongoDBはNoSQLの中では低速な部類に入る。 これは他のNoSQLに比べて豊富な機能が提供されているからで『RDBMSからJOINを除いた相当の機能』と言っても良いくらいの豊富さだ。部分的にはRDBMSを凌駕す
退職エントリーが流行の様なので・・・ 9月末付けで楽天を退社しました。 楽天は、6年間お世話になりました。 非常に働き易く良い会社だったと思います。 それまでは、長くても同じ職場には2年は居つかなかったのですが 特に大きな不満もなく、居心地が良すぎてツイツイ長居してしまった。 今までの職場ではやりたい事はスグやり終えてしまい、退屈でした。 楽天には沢山ありましたね。。やり切れないほどに・・・ 楽天台湾進出プロジェクト、インフォシークの大改修など 数多くの得がたい機会と経験をさせて頂き感謝しております。 さて、、では何故退社したのか? 一言でというと 『私にとって楽天は大きく成り過ぎた』 大きな会社は必然的に動きが鈍くなります。 これは『誰が悪い』とか、『どうしたら良い』とかの問題ではありません。 組織が大きくなれば、それなりにガバナンスコストが上がり そのコストが時間に跳ね返るというだけの
一連の自然言語処理をMONMOちゃん上で実現する試みの第2弾 前回は形態素解析まで行った。 今回は、形態素解析結果から、そのドキュメントの特徴を表す『ベクトル』を算出する、ベクタライズを行う。 monmo-NLProcessing github https://github.com/monmo/monmo-NLProcessing TF-IDF 自然言語処理における代表的なベクタライズ手法。 考え方 ドキュメント中、何回も出現する単語はそのドキュメントを表す重要な単語である。 多くのドキュメント中に出現する単語は普遍的な単語なので重要ではない。 シンプルだ。 TF-IDFの要素 N 総ドキュメント数 TF[a] ある単語(a)がその1ドキュメント中に現れた回数 DF[a] ある単語が現れたドキュメント数 IDF[a] log( N / DF[a] ) TF-IDF[a] TF[a] x I
前回MONMOちゃんの紹介の続き。 今回は(日本語)自然言語解析の第一歩であるトークンナイズ(tokenize)を行う。 monmo-NLProcessing github https://github.com/monmo/monmo-NLProcessing 形態素解析 日本語の解析で一般的に使われるtokenize手法で、辞書を使った文脈解析。 メジャーな形態素解析ライブラリは以下の様なものがある。 mecab https://code.google.com/p/mecab/ lucene-gosen http://code.google.com/p/lucene-gosen/ ちょっと説明 ラテン語圏だと大抵の文章はスペース区切りで表記される。 I want to read it. これをプログラムで扱う場合は、単純にスペースの部分で切れば良い。 I want to read it
お盆が暇だったので MongoDB製Job queue を作った。 名前はMONMOちゃん。 javascriptで手軽に使いたい部分があって個人用で考えていたが 結構マトモなモノが出来上がったので公開する事にする。 またMONMOちゃんを使って、自然言語処理も一式書いてみたが こちらは次回紹介する。 注意 Javascript製ではない。 MongoDB製だ! 繰り返し言おう。 MongoDBは環境である!! About Monmoちゃん github https://github.com/monmo/monmo 概要 全ての処理はMongoDB(mongod) 及び Mongo shell(mongo)上で動作する。 JobはJavascriptで記述する。 MongoDBへJob投入(制御データと実装)すると、予めどこかで起動したWorkerが処理する。 Job投入側にはスクリプトを
勢いでtwiteしたついでに、軽く書いてみた。 MongoDBのfindAndModifyは物凄く便利で色々使い方があるのだが $setOnInsertと組み合わせると、お手軽セマフォになるので こんな感じで簡単にJOB管理に使える訳だ。 全ドキュメントを並列に処理する例 このスクリプトをmongo shell をいくつも立てて実行すれば、同一ドキュメントの重複処理を上手く回避して並列処理できるわけ。 foo 処理対照コレクション foo_job ジョブ管理用コレクション // そのドキュメントが処理中か否か判定する function isVacant(id){ var prev = db.foo_job.findAndModify({ query: {_id:id}, update:{ $setOnInsert:{ tm:ISODate()}}, upsert:true }); if (
Sharding構築手順とポイント 構成 mongos +-----------------+ | 192.168.159.50 | +-----------------+ ConfigDB +-----------------+ +-----------------+ +-----------------+ | 192.168.159.3 | | 192.168.159.4 | | 192.168.159.5 | +-----------------+ +-----------------+ +-----------------+ Shard1 +-----------------+ +-----------------+ +-----------------+ | 192.168.159.100 | | 192.168.159.101 | | 192.168.159.102 | +--
実は数年前(MongoDB 1.6〜1.8の時期)にログをリアルタイムに全てmongodbに叩き込んで期間毎に解析する仕組みを作ろうとして挫折した事がある。 理由は幾つかあったのだが主に cappadコレクションでは解析時の負荷とログ投入負荷が重なってしまう。 → 最終的には書き込みが負けてoplogが溢れる。 時系列カラムをshard keyにするとchunk migrationが辛すぎる。 そもそもshardingの信頼性が・・・ という理由だった。 今ならストレージエンジンが早くなったし再挑戦しても良いかもしれない。 ログは非同期に準リアルタイムに拾って投入。 出力元+時間でshard key。 なるべくグループコミットの効率が上がる塊を作る。 とか、、 お題 ともかく、今回は 時系列データを投入した時chunk migrationがどう動くのか? の話。 そもそも時系列カラムをsh
大体欲しいデータは揃ったのと、MongoDBの気持ちが解ってきたのでMongoDB2.4の性能調査は今回で最後の予定 実は前回MongoDB 2.4 の性能 徹底評価(レコード長による評価)のFETCHバイト数(1.5GB) 実は今回のOn-memoryデータ vs DISKリードに繋げる事を意図した大きさだった。 システムの2GBメモリに収まるだろう。と・・・ しかし、、測れど測れど、意図した通りの結果にならない・・・ それで気付いた。 インデックスの大きさを勘違いしていたのだ。 MongoDBのインデックスは単なるコレクションでは無いようだ! 1億件の数値型インデックスは2.3GBにもなる。 という訳で、1億件のコレクションのインデックスはそもそもメモリーに入らない。。 1ドキュメント辺り25〜26byte インデックス数値型8バイト+ドキュメントへのポインタ8バイト+メタ情報? _i
> 原文(Why MongoDB is a bad choice for storing our scraped data) 私自身はMongoDBを推進する立場なのだが、確かにMongoDBに適さないケースはある。 闇雲に推進しても結局は全員がアンハッピーになるので、この様なネタもどんどん紹介していこうと思う。 この記事はMongoDBを徹底的に使い尽くしたエンジニアが書いている様で状況が良く解った。 ちょっと難しい所もあるので要点を意訳して、軽く解説を書いてみる。 (もちろん是非原文で読むのをお勧めする) 状況 最初はMongoDBでうまく動いていたが、だんだん苦労が増えてきて 元々のアーキテクチャを刷新するタイミングでMongoDBから別のプロダクトに乗り換える事にした。 システムの規模 詳しく書かれていないが、1ノード辺り数TBとあるのでSharding環境ではないかと思われる。
前回のMongoDB 2.4 の性能 徹底評価の反響が大きかったので続編。 今回の調査対象 ドキュメントサイズ毎の性能を評価する。 今回の検証用にベンチを書いた。 性能見積りにも使えると思うので、紹介しておきます。 MongoDB-JP/mongo_bench 今回の検証も、Sakura VPS 2G で行った。 専用環境ではないので、ある程度まわりの影響を受けている。(何度もベンチを取って極力排除はしたが、、) また、記事に載せた以外にも色々と検証しており、その結果も少し混ざっていたり。。 オンメモリデータの処理が高速な事は解っているので 今回の検証の肝は『ディスクアクセス』 MongoDBはメモリ以上のデータを扱う為のプロダクトなのでなるべく性能が出ない様な条件=ワーストケースを狙った。 2GBメモリに対して40GBのデータを扱い、データ全体を万遍なく使うようなクエリーを発行する。 評
いつも忘れるので、まとめておくことにした stat No フィールド scanf 説明 0 pid %d プロセス ID。 1 comm %s 括弧でくくられた実行形式のファイル名。実行形式がスワップアウトされているかどうかによらず、見ることができる。 2 state %c "RSDZTW" のどれか 1 文字。 R は実行中 (running)、 S は割り込み可能な休眠状態 (sleeping in an interruptible wait)、 D は割り込み不可能なディスクスリープの待機状態 (waiting in uninterruptible disk sleep)、 Z はゾンビ状態 (zombie)、 T はトレースされている (traced) か (シグナルにより) 停止している状態 (stopped)、 W はページング中 (paging) を表している。 3 ppid
まとめ 超長くなったのでまとめを上に持ってきた。 巷で言われているチューニングは結構嘘が多い事が解ってきた。 ツール等 workingSet Analyzer は信用ならない。(overSecondsはまあ良い) mongoperfの値は完全に参考にならない。 insert mongoperfの値はinsert性能と関連しない。(何を測ってるんだ?) カラムのプリアロケーションによるUPDATE時のデータ肥大化回避($setOnInsert)はMUST。 クリティカルな時間帯にストレージファイル(2GB)の生成を避けるチューニングの効果は懐疑的。 レコードプリアロケーション・チューニングは頑張る価値が無い。(むしろ逆効果) update 上記の通り必ずin-placeになるようにする。 paddingFactorが動くようだとお話にならない性能劣化 remove かなり高速。 全件削除の場
Working Set Analyzer MongoDB2.4からはサーバリソースの管理・評価にAnalyzerが使えるようになりました。 利用方法は既存のコマンドdb.serverStatus()を叩くだけです。 マニュアル 翻訳 workingSet New in version 2.4. Example:output of the workingSet fields. Note: The workingSet data is only included in the output of serverStatus if explicitly enabled. To return the workingSet use one of the following commands:db.serverStatus( { workingSet: 1 } ) db.runCommand( { se
非常に参考になるMongoDBのノウハウ集を和訳(&少々所感)しました。 内容はデータベースの基本に忠実です。 データサイズを圧縮し、レコードの移動を防ぎ、効率の良いクエリーを発行しろという事です。 突飛な手法では無いので理解し易い。 One of things that makes MongoDB easy to get started with is you don’t have to think about schema design -- just shove data in and it’ll let you query it. That helps initial development and has benefits down the line when you want to change your document structure. That said… Mongo
次のページ
このページを最初にブックマークしてみませんか?
『中年engineerの独り言 - crumbjp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く