MongoDB3.2 ReleaseNote所感 - 中年engineerの独り言 - crumbjp
そろそろ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上にハイパフォーマンスMongoDBを構築する方法 - 中年engineerの独り言 - crumbjp
AWSインスタンスの選定 AWSインスタンスタイプ一覧 以下のインスタンスボリュームが付随しているプロダクトラインが候補になる。 個人的にはi2.xxx が好みである。 r3.xxx メモリ最適化インスタンス i2.xxx SSD容量最適化インスタンス ただし、インスタンスボリュームはスナップショットが取れず、揮発性なので取り回しが悪い。 Provisioned IOPS (SSD) ボリュームも検討候補になるが、高くつく事になるのでお金持ちの人用。。 バックアップ戦略 流石にバックアップを全く取らずに運用する事は出来ないので 以下様にレプリカセット構成を組み、バックアップを取る。 Primary: i2.xxx Secondary: i2.xxx Secondary(hidden): 適当なインスタンス + SSD 最後のノードはバックアップ専用なので、SSD以外は非力出よい。 ただしあ
MongoDB3系(WiredTiger)の現状 - 中年engineerの独り言 - crumbjp
ご無沙汰してます。 最近全然更新出来てない訳ですが、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 リリースノート斜め読み - 中年engineerの独り言 - crumbjp
遂にMongoDB 3.0 が正式リリースされました！！ 例によってリリースノートを斜め読みします。 http://docs.mongodb.org/master/release-notes/3.0/ が、、最初に一言で纏めると、まあ、、 目玉機能はロックレベルの話だけですよー でわ。。 Pluggable Storage Engine AP 以下の２つからストレージエンジンを選べる。 MMAPv1 これまでのストレージエンジン。デフォルト WiredTiger 3.0から追加されたストレージエンジン WiredTiger MongoDBの全ての機能をサポートしている。 MMAPv1とフォーマットが違うので既存のアップデートの場合、移行する際に色々必要。 ドライバも最新に上げないとダメ。 ドキュメントレベルロックが可能！！ touchコマンドはサポートしてない MMAPv1 Improve
Mongoクエリー・ベース・レプリケーション - 中年engineerの独り言 - crumbjp
レプリカセット間レプリケーション MongoDBではレプリカセットを跨いでデータを同期する手段が無い。 そもそもレプリカセット自体が冗長構成を目的としているので設計に組み込まれていないのだろう。 しかし現実は Staging環境や、PV系／集計系の分離など、用途はある。 今は、レプリカセットのslaveを１台切り離してそこで何かするしかない。 フレッシュデータじゃないし運用も面倒。 monmo-repl https://github.com/monmo/monmo-repl なければ作れば良いので作った。 oplogベースの同期を行う。-s で指定したレプリカセットのPRIMARYのoplogを読み、-d で指定したレプリカセットに反映していく。 PRIMARYダウン時の挙動など、まだ未テストの部分は多いが 『とりあえず動く』 程度の完成度。 例 ReplicaSet1 =sync=> R
MongoDB 2.4 => 2.6 アップデートした - 中年engineerの独り言 - crumbjp
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リリースノート斜め読み！ - 中年engineerの独り言 - crumbjp
ご存知の通りMongoDB2.6がリリースされました！ 相変わらず乱文で解説！！ Aggregation Enhancements Aggregationが強化された。 db.collection.aggregate() がカーソルを返却するようになった 今まで最終結果には64MBの制約があったが、解消されたようだ。 というかそれが普通。。。 パイプラインがexplainをサポート 今までは感覚で是非を判断していたので嬉しい改善！ ディスクソートが効率的になった $out オペレータで指定のコレクションに結果出力が可能 今までは結果をforで回して入れなおしてたのでこれも便利。 $redact でパイプライン中にデータの微修正ができる あんまり使う機会が思い当たらない。。 多分この様な用途でMongoDBを使うこと自体が詰んでる。 新しいoperator $let, $map $liter
MongoDB vs MySQL性能比較 - 中年engineerの独り言 - crumbjp
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を凌駕す
Aggregation FW機能、SQLとの比較 - 中年engineerの独り言 - crumbjp
使い方や例など詳細は本家のドキュメントを参照してください。 基本機能 オペレータ SQL相当 説明 $project SELECT 集計用のフィールドの削除・追加・定義など $match WHERE 絞込み条件を指定 $limit LIMIT 対象行数指定 $skip LIMIT 読み飛ばし行数指定 $unwind - 配列フィールドを複数ドキュメントに展開（使わない使えない使いたくない） $group GROUP BY 集計 $sort ORDER BY ソート $geoNear - 座標フィールド近傍検索+ソート 集計($group)機能 集計オペレータ SQL相当 説明 $first - SQLでもやりたい事は多いのでうれしい $last - 同上 $max MAX $min MIN $avg AVG $sum SUM {$sum:1}でCOUNTを代用できる $push - 全要素
自然言語解析 in MONMO（後編） - 中年engineerの独り言 - crumbjp
一連の自然言語処理をMONMOちゃん上で実現する試みの第３弾 前回はベクタライズまで行った。 今回は、形態素解析結果から、そのドキュメントの特徴を表す『ベクトル』を算出する、ベクタライズを行う。 monmo-NLProcessing github https://github.com/monmo/monmo-NLProcessing k-means 非階層型のクラスタリング手法。 シンプルで軽量。 ある程度の分散処理も可能。 概要 初期値として、仮重心を複数与え、各ベクトルは一番近い重心に所属するものとし、それらの平均値を新たな重心とする。 これを繰り返す事で、仮重心は移動して行き、最終的に動かなくなる。それが本当の重心と言える。 但し、初期値として与える仮重心の個数や値ににより、結果が大きく変わる。 canopy 非常にシンプルで荒っぽいクラスタリング手法 分散処理は難しい。 k-mea
自然言語解析 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 (
時系列データとMongoDB2.4の新機能Hash based sharding - 中年engineerの独り言 - crumbjp
実は数年前（MongoDB 1.6〜1.8の時期）にログをリアルタイムに全てmongodbに叩き込んで期間毎に解析する仕組みを作ろうとして挫折した事がある。 理由は幾つかあったのだが主に cappadコレクションでは解析時の負荷とログ投入負荷が重なってしまう。 → 最終的には書き込みが負けてoplogが溢れる。 時系列カラムをshard keyにするとchunk migrationが辛すぎる。 そもそもshardingの信頼性が・・・ という理由だった。 今ならストレージエンジンが早くなったし再挑戦しても良いかもしれない。 ログは非同期に準リアルタイムに拾って投入。 出力元＋時間でshard key。 なるべくグループコミットの効率が上がる塊を作る。 とか、、 お題 ともかく、今回は 時系列データを投入した時chunk migrationがどう動くのか？ の話。 そもそも時系列カラムをsh
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環境ではないかと思われる。
アパッチ・モジュールのログTips - CustomLog編 - 中年engineerの独り言 - crumbjp
今回のお題はアパッチのCustomLogです。 前回は分量が多過ぎて力尽きたので今回からは少なめで・・・ アパッチのログ機構 アパッチは二系統(3種)のログ機構を持っています。 ErrorLog ログレベルによる出力制御が可能なログ。 CustomLog リクエスト毎に出力されるログ。所謂アクセスログです。出力項目をhttpd.confから制御可能。 実はSetEnvIfと組み合わせて条件付きで出力も出来なくはありませんが、ココでは説明しません。 TransferLogはCustomLogの一種です。*1 他にも各モジュールで独自にログ機構を提供している場合もあります。 ですがやはりココでは解説しません。 有名なものはこの辺でしょうか。。 RewriteLog mod_rewriteのデバッグ用 ScriptLog mod_cgiのデバッグ用 モジュール開発に関係するのは主にErrorLo
最小構成のアパッチモジュール解説 - 中年engineerの独り言 - crumbjp
今回は、実用的モジュールの最小構成として次の解説をします。 httpd.confからモジュールに設定情報を与える方法。(command_rec) 必要なリクエストのみモジュールを動作させる方法。(SetHandler) ログを出力する方法。 細かいそれぞれの設定のバリエーションに関しては 次回一覧にする予定なので今回は典型的な例だけ説明します。 説明の為、前回の日記 アパッチモジュールの初歩・その壱 - LinuxとApacheの憂鬱 で生成したソースを少し改造します。 mod_mytest.c /* プロトタイプ宣言を追加 */ #include "httpd.h" /* ログ出力用ヘッダ(追加) */ #include "http_log.h" #include "http_config.h" #include "http_protocol.h" #include "ap_config
アパッチモジュールの初歩・その壱 - 中年engineerの独り言 - crumbjp
これからはモジュールの話に入ります。 今回はapxsによるモジュールスケルトンの生成。 次回以降は生成したモジュールソースの解説や モジュール開発のTipsを紹介していきます。 さて早速始めます。 今回の内容は書くと長くなりますが 作業自体はストレートに進めれば3分と掛かりません。 まず前提の環境ですが、以前の日記の通りです。 Linux/Apache事始め-ビルド編- - LinuxとApacheの憂鬱 apxs アパッチの標準ツール。 モジュールの開発/ビルド/インストール利用する。 manも用意されているので、詳しく知りたい場合はこちら。 $ export MANPATH=/usr/local/apache2/man:$MANPATH $ man apxs主に仕様するオプションは以下の３つ。 -g モジュールのスケルトンを生成。 -c モジュールをビルド。 -i モジュールをインスト
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
