対象データは全国の郵便番号(12万件)をキーに住所を入力しています。
kumofs+spymemcachedでは、大量のデータをいっぺんに投げると接続が不安定になります。
一応接続方法を DefaultConnectionFactory から、KetamaConnectionFactory (蹴球?)に変えたら多少良くなったような気がしました。(が、たまにエラーでます)
やり方は前回のサービスの一部を変更↓
def void afterPropertiesSet() {
memcachedClient = new MemcachedClient(new KetamaConnectionFactory(60000,60000), AddrUtil.getAddresses("localhost:11211"))
// memcachedClient = new MemcachedClient(AddrUtil.getAddresses("localhost:11211"))
}
コメントアウトしたところが元のソースです。
念のためバッファ等もあげてあります。
CouchDBはRESTですべて行えるので、Grailsからはサクサク使えるのですが、Java用のライブラリがあったので試してみました。
勢いのあるjcouchdbを使っています。
インポートはこんな感じで書きました
Database db = new Database("localhost", "postal");
def doc=new BaseDocument()
doc.setId(key)
doc.setProperty("val",val)
db.createDocument(doc);
・結果はこんな感じ
データインポート
kumofs | CouchDB | HSQLDB |
---|---|---|
21,917ms | 980,457ms | 41,883ms |
18,785ms | 1,008,333ms | 33,800ms |
18,205ms | 955,118ms | 35,256ms |
17,387ms | 3回で心が折れました | 31,735ms |
18,062ms | 32,539ms |
取得した結果はこちら
kumofs | CouchDB | HSQLDB |
---|---|---|
51,357ms | 564,257ms | 2,803,802ms |
45,988ms | 590,907ms | 2,764,875ms |
50,615ms | 539,712ms | 2回で心が折れました |
46,966ms | 3回で心が折れました | |
48,286ms |
・ちなみにDBの容量はこんな感じになりました。
元のテキスト 12mb
kumofs 22mb
couchDB 600mb
couchDBは差分もてたりする分情報が多いのは理解出来ますが、ちょっとありえないサイズになってますね・・・
・まとめるとこんな感じ
(そもそも単純なKVSであるkumofsとMapReduce出来るCouchDBを比べるのも変かも知れませんが・・・あえてTokyoTryrantとかとは比べないのがうちっぽいという事で)
速度だけでみたらkumofsが最速(安定性に不安があるけど・・・)
CouchDBは想像以上に遅かったですね、、、特に書き込み。
ってそういう見方もあるけど、CouchDB良い所はKVSやSQL文になじみのない人がチームにいても理解しやすいって所だと思います。
RDBMS(今回はHSQL使ってます)の読み込みの遅さは正直壊れたのかと思うぐらい遅かったです・・・
まあINDEXもチューニングも何もしていない状態だとこんなものでしょうか。
そこらへんはプログラマならやって当然の事なんですが、そういう事考えなくても早いDBってのも良い物ですよね。
次回はkumofsをスケールアウトしてみます、果たして更なる速度向上はあるのか!?
0 件のコメント:
コメントを投稿