ubuntu に mongodb をインストール - with pymongo / vs couchdb

一段落ついたので、couchdb に引き続き mongodb もインストールしてみた。環境は同じく VMWare 上の ubuntu。シングルサーバ、シングルクライアント (python) な環境で比較することに。

というのも、設定に誤りがあるためか、 couchdb が期待できるようなパフォーマンスが出なかったため。100 万件のデータを insert 処理するストレステスト (本番バッチ処理環境を考慮) をしているのですが、途中で conflict -> socket error -> down になってしまう。途中 sleep を入れると socket error は出なくなるけど、それだと遅いのと、なんだか気持ち悪い。前ポストで書いたように、0.8.0, 0.11.0b, 0.10.0 で試したけど、結果は同じでした。何が悪いのだろう・・・。

気は取り直して、mongodb は期待する結果が得られたので、インストールと pymongo 経由での処理方法です。

  1. 依存パッケージ類のインストール 
    sudo aptitude install tcsh git-core scons g++
sudo aptitude install libpcre++-dev libboost1.37-dev libreadline-dev libmozjs-dev
  2. git から mongodb のダウンロードとインストール (/opt/mongo へ) 
    cd /usr/src/
git clone git://github.com/mongodb/mongo.git
cd mongo
sudo scons all
sudo scons --prefix=/opt/mongo install
  3. mongo ユーザの追加 
    sudo adduser --system --home /opt/mongo/ --no-create-home --shell /bin/bash --group --gecos "mongoDB Administrator" mongo
  4. db データディレクトリーの追加とパーミッション設定 
    sudo mkdir -p /data/db
sudo chown -R mongo:mongo /data/
sudo chmod a+x /data/db/
    データディレクトリは任意だけど、デフォルトのパスは上記のディレクトリになってる
  5. デーモン monbod の起動 
    sudo /opt/mongo/bin/mongod
    もしデータディレクトリを別の場所にしている場合は、--dbpath オプションで渡してやる 
    sudo /opt/mongo/bin/mongod --dbpath /path/to/db
    バックグラウンドプロセスで起動するために、末尾に "&" をつけてやる。
    もし、そのまま起動してしまった場合は <Ctrl>+z でプロセスを停止し、 bg でバックグラウンドプロセスに放り込む
    正常に起動した場合は、以下のようなメッセージが標準出力に表示される。 
    Fri Nov  6 11:43:02 Mongo DB : starting : pid = 3558 port = 27017 dbpath = /data/db master = 0 slave = 0  32-bit

** NOTE: when using MongoDB 32 bit, you are limited to about 2 gigabytes of data
**       see http://blog.mongodb.org/post/137788967/32-bit-limitations for more

Fri Nov  6 11:43:02 *** warning: spider monkey build without utf8 support.  consider rebuilding with utf8 support
Fri Nov  6 11:43:02 db version v1.1.3-, pdfile version 4.5
Fri Nov  6 11:43:02 git version: 9ecceafbca1c0f88ec69aa659f12a7098f563095
Fri Nov  6 11:43:02 sys info: Linux wb01 2.6.28-16-generic #55-Ubuntu SMP Tue Oct 20 19:48:24 UTC 2009 i686
Fri Nov  6 11:43:02 waiting for connections on port 27017
  6. mongodb の停止
    mongo プロンプトからやるか ps からプロセスIDを取得して kill するらしい。プロンプトでやろう (笑 
    sudo /opt/mongo/bin/mongo

> use admin
switched to db admin
> db.shutdownServer()
Fri Nov  6 11:55:57 terminating, shutdown command received
Fri Nov  6 11:55:57  dbexit:
Fri Nov  6 11:55:57      shutdown: going to flush oplog...
Fri Nov  6 11:55:57      shutdown: going to close sockets...
Fri Nov  6 11:55:57      shutdown: waiting for fs...
Fri Nov  6 11:55:57      shutdown: closing all files...
Fri Nov  6 11:55:57      closeAllFiles() finished
Fri Nov  6 11:55:57      shutdown: removing fs lock...
Fri Nov  6 11:55:57  dbexit: really exiting now
ERROR: Client::shutdown not called!
server should be down...
Fri Nov  6 11:55:57 trying reconnect to 127.0.0.1
Fri Nov  6 11:55:57 reconnect 127.0.0.1 ok
Fri Nov  6 11:55:57 JS Error: Error: error doing query: failed (anon):99
> exit
bye
[3]-  Done                    sudo /opt/mongo/bin/mongod
  7. pymongo のインストール (setuptools を使う) 
    sudo easy_install pymongo
  8. pymongo を使ってみる (pymongo のドキュメント通りにやってみる) 
    >>> from pymongo.connection import Connection
>>> connection = Connection("localhost", 27017)
Fri Nov  6 12:02:30 connection accepted from 127.0.0.1:29390 #2
Fri Nov  6 12:02:30 end connection 127.0.0.1:29390
>>> db = connection.test
>>> db.name()
u'test'
>>> db.my_collection
Collection(Database(Connection('localhost', 27017), u'test'), u'my_collection')
>>> db.my_collection.save({"x": 10})
Fri Nov  6 12:03:12 connection accepted from 127.0.0.1:29646 #3
Fri Nov  6 12:03:12 allocating new datafile /data/db/test.ns, filling with zeroes...
ObjectId('4af391f07ad5bd0fc4000000')
>>> Fri Nov  6 12:03:12 done allocating datafile /data/db/test.ns, size: 16MB, took 0.102 secs
Fri Nov  6 12:03:12 allocating new datafile /data/db/test.0, filling with zeroes...
Fri Nov  6 12:03:13 done allocating datafile /data/db/test.0, size: 64MB, took 0.55 secs
Fri Nov  6 12:03:13 building new index on { _id: ObjId(000000000000000000000000) } for test.my_collection...
Fri Nov  6 12:03:13 Buildindex test.my_collection idxNo:0 { name: "_id_", ns: "test.my_collection", key: { _id: ObjId(000000000000000000000000) } }
Fri Nov  6 12:03:13 done for 0 records 0.257secs
Fri Nov  6 12:03:12 insert test.my_collection 913ms

>>> db.my_collection.save({"x": 8})
ObjectId('4af392067ad5bd0fc4000001')
>>> db.my_collection.save({"x": 11})
ObjectId('4af392107ad5bd0fc4000002')
>>> db.my_collection.find_one()
{u'x': 10, u'_id': ObjectId('4af391f07ad5bd0fc4000000')}
>>> for item in db.my_collection.find():
...   print item["x"]
...
10
8
11
    最初に my_connection にアクセスした際に、test バイナリーファイルが作成されるみたいですね。
    適当に connection.foo, db.bar とかやっても動きます。
  • couchdb は CPU 使用率やメモリ使用率は少ないです。それと比較すると mongodb はストレステストの間中 99.9% の CPU を消費していました
  • couchdb はストレスをかけると comflict -> socket error -> down になりましたが、mongodb は落ちずにより高速に処理できました

ちょっと今回の検証では couchdb を使いこなせなかった感じです。とりあえず、mongodb を使うことにしましたが、 couchdb についてももうちょっと勉強したいと思います。あっ tokyo tyrant も。

コメント

コメントを投稿

このブログの人気の投稿

Python から Win32 API 経由で印刷する

Win32 API から印刷をするためには、プリンタデバイスコンテキスト (Printer DC) を利用します。具体的には以下のような順序で印刷します。 プリンタドライバからハンドルを取得する プリンタドライバのステータス API から印刷可能か同かを取得する プリンタデバイスコンテキストを作成する ドキュメントを開始する 必要であればフォント等を設定し、印字、改ページ処理などをする ドキュメントを終了する (この時点でプリンタスプールサービスに登録されるようです) プリンタデバイスコンテキストを開放する プリンタドライバのステータス API を監視し、印刷が正常に終了したかを取得する プリンタドライバのハンドルを解放する 太字の手順 (3 - 7) は Win32 API で共通ですが、それ以外の手順 (1, 2, 8, 9) はプリンタドライバに依存しているため、Python から制御したい場合はライブラリを作成する必要があります。これについては、ドライバマニュアルとにらめっこしながら ctypes.windll でがんばります・・・。プリンタ接続、用紙切れ、ミスフィード等のプリントエラーを制御する必要がなければ、書く必要はありません (排他制御が必要なプリンタを除く)。プリンタドライバ毎に変わる部分は置いといて、太字の Win32 API の部分の覚書です。 プリンタデバイスコンテキストを作成する import win32ui import win32con PRINTER_NAME = '[コンパネ -> プリンタとFAX -> に登録しているプリンター名]' PIXELS_PER_INCH = 1440 # 1 インチ毎のピクセル数 INCH_PER_POINT = 72 # 1 インチ毎のポイント数 SCALE_FACTOR = int(PIXELS_PER_INCH / INCH_PER_POINT) #　わざわざ計算せず 20 と指定する場合が多い dc = win32ui.CreateDC() dc.CreatePrinterDC(PRINTER_NAME) # 指定したプリンタ名のプリンタデバイスコンテキストを作成する self.dc.SetMapMode(win32con.MM...
続きを読む

Disqus のスケール - Django 編

イメージ
やり直し。2010 年の Django Con のスライド より。 Disqus は多くのサイトに組み込まれているサービスのため、メンテナンスによる停止が難しい。 >>> サーバの構成 エッジロードバランサーに HAProxy: heartbeat 構成。レポートが素敵。 HTTP ゲートウェイキャッシュに Varnish Django サーバとして Apache + mod_wsgi: 30 台ぐらい。メモリリークを防ぐために maximum-requests をセット。Ganglia で監視 キャッシュに memcached: 25 台ぐらい PostgreSQL ロードバランサーに HAProxy/ PgBouncer : コネクションプール用。 PostgreSQL: 10 台ぐらい。 Slony-I で非同期レプリケーションとフェイルオーバー。 ログは syslog-ng: pgFouine でスロークエリーをロギング。 全部でサーバ 100 台ぐらい。他にユーティリティサーバ 15 台、後は HAProxy と heartbeat 用に 20 台ぐらいの構成。Varnish と syslog-ng を除けば Django のデプロイ手順に掲載されているような教科書通り (良い意味です) の構成です。(なんで Apache なの？nginx + gunicorn 速いよって突っ込まれてますね >>> データベースのパーティショニング Django はアプリケーションレベルで簡単に 垂直 パーティショニングができます。アプリケーションごとに DB 分けたり、DB をアプリケーションレベルでルーティングできます ( ドキュメント )。 水平パーティショニング (a.k.a シャーディング) もアプリケーションで 書ける (なるほど・・・)。 >>> キャッシュの削除 Django は QuerySet の結果をキャッシュするけど、それがかなりメモリを消費する。なので SkinnyQuerySet を作った (たぶん Johnny Cache の方が有名？...
続きを読む

Disqus のスケール - Django で月間80億PVを処理する

私が把握してる限り Django で一番大きなサービス Disqus のスケール (執筆時点ではサービスダウンしてる)。元ネタは Scaling Django to 8 Billion Page Views です。 月間80億PV 、 45k req/s のほぼすべてのトラフィックを Django で処理しているとのこと。抄訳になるかな。 WAF は 高速開発とパフォーマンス 、 新しい人が入ってすぐに開発に参加できることとカスタマイズ 等のトレードオフがあります。この記事ではそのトレードオフである高速開発とパフォーマンスをどう両立させるか、Disqus のノウハウが紹介されています。 >>> なぜ WAF (Web Application Framework) は遅いのか 最初に思い浮かぶのは、アプリケーションに必要ではないボイラープレート ( django.contrib とか?) や不要なコードがあるため。そもそも Django の思想が Python 同様 " バッテリー同梱 (batteries included) " のため、Django は他の Python 製 WAF よりボイラープレートが多いです。Disqus 曰く "実は 言語や WAF は遅さにあまり関係ない " それより " ネットワーク内の他のサービスとの通信 " のオーバーヘッドが原因とのこと。これは一般的によく言われてることですし、大規模になればなるほどそう。Disqus の場合は PostgreSQL, redis, Cassandra , Memcached 等のサービスが使われているそうです。DB へのスロークエリーやネットワークのレイテンシーは Django のようなボイラープレートによるオーバーヘッドを軽く上回ります。この待ち時間を回避する一番メジャーな方法はキャッシュの使用です。Django では キャッシュフレームワーク を使用します。Django でキャッシュを使うのは簡単ですし、バックエンドに Memcached を使うと充分高速化できます。 はい。ここまでは一般的な話です。こっから。 >>> 45k req/seq を処理する キャッシュしたところで...
続きを読む