自然言語解析 in MONMO（中編） - 中年engineerの独り言 - crumbjp
一連の自然言語処理をMONMOちゃん上で実現する試みの第２弾 前回は形態素解析まで行った。 今回は、形態素解析結果から、そのドキュメントの特徴を表す『ベクトル』を算出する、ベクタライズを行う。 monmo-NLProcessing github https://github.com/monmo/monmo-NLProcessing TF-IDF 自然言語処理における代表的なベクタライズ手法。 考え方 ドキュメント中、何回も出現する単語はそのドキュメントを表す重要な単語である。 多くのドキュメント中に出現する単語は普遍的な単語なので重要ではない。 シンプルだ。 TF-IDFの要素 N 総ドキュメント数 TF[a] ある単語（a）がその１ドキュメント中に現れた回数 DF[a] ある単語が現れたドキュメント数 IDF[a] log( N / DF[a] ) TF-IDF[a] TF[a] x I
自然言語解析 in MONMO（前編） - 中年engineerの独り言 - crumbjp
前回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 - 中年engineerの独り言 - crumbjp
お盆が暇だったので 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投入側にはスクリプトを
MongoDBはＤＢではない。環境である！ - 中年engineerの独り言 - crumbjp
勢いで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 (
/proc/[pid]/stat まとめ - 中年engineerの独り言 - crumbjp
いつも忘れるので、まとめておくことにした 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
![/proc/[pid]/stat まとめ - 中年engineerの独り言 - crumbjp](https://cdn-ak-scissors.b.st-hatena.com/image/square/6e8c00444c21320e56b79d3580a74c72010e2fb6/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F10328749687194688875%2F10328749687194689513%2F1479310246)
MongoDB 2.4 の性能 徹底評価（Memory vs DISK） - 中年engineerの独り言 - crumbjp
大体欲しいデータは揃ったのと、MongoDBの気持ちが解ってきたのでMongoDB2.4の性能調査は今回で最後の予定 実は前回MongoDB 2.4 の性能 徹底評価（レコード長による評価）のFETCHバイト数（1.5GB） 実は今回のOn-memoryデータ vs DISKリードに繋げる事を意図した大きさだった。 システムの2GBメモリに収まるだろう。と・・・ しかし、、測れど測れど、意図した通りの結果にならない・・・ それで気付いた。 インデックスの大きさを勘違いしていたのだ。 MongoDBのインデックスは単なるコレクションでは無いようだ！ 1億件の数値型インデックスは2.3GBにもなる。 という訳で、1億件のコレクションのインデックスはそもそもメモリーに入らない。。 １ドキュメント辺り25〜26byte インデックス数値型８バイト＋ドキュメントへのポインタ８バイト＋メタ情報？ _i
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
前回のMongoDB 2.4 の性能 徹底評価の反響が大きかったので続編。 今回の調査対象 ドキュメントサイズ毎の性能を評価する。 今回の検証用にベンチを書いた。 性能見積りにも使えると思うので、紹介しておきます。 MongoDB-JP/mongo_bench 今回の検証も、Sakura VPS 2G で行った。 専用環境ではないので、ある程度まわりの影響を受けている。（何度もベンチを取って極力排除はしたが、、） また、記事に載せた以外にも色々と検証しており、その結果も少し混ざっていたり。。 オンメモリデータの処理が高速な事は解っているので 今回の検証の肝は『ディスクアクセス』 MongoDBはメモリ以上のデータを扱う為のプロダクトなのでなるべく性能が出ない様な条件＝ワーストケースを狙った。 2GBメモリに対して40GBのデータを扱い、データ全体を万遍なく使うようなクエリーを発行する。 評
MongoDB 2.4 の性能 徹底評価 - 中年engineerの独り言 - crumbjp
まとめ 超長くなったのでまとめを上に持ってきた。 巷で言われているチューニングは結構嘘が多い事が解ってきた。 ツール等 workingSet Analyzer は信用ならない。（overSecondsはまあ良い） mongoperfの値は完全に参考にならない。 insert mongoperfの値はinsert性能と関連しない。（何を測ってるんだ？） カラムのプリアロケーションによるUPDATE時のデータ肥大化回避($setOnInsert)はMUST。 クリティカルな時間帯にストレージファイル(2GB)の生成を避けるチューニングの効果は懐疑的。 レコードプリアロケーション・チューニングは頑張る価値が無い。(むしろ逆効果) update 上記の通り必ずin-placeになるようにする。 paddingFactorが動くようだとお話にならない性能劣化 remove かなり高速。 全件削除の場
Scheme design in MongoDB. - 中年engineerの独り言 - crumbjp
非常に参考になる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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
