Casual Compression on MongoDB

Casual Compression
on
-present at MongoDB Casual Talks-

@just_do_neet

Today’s Agenda
今日のお題目

•MongoDBの課題

•MongoDBでのデータ圧縮

•まとめ

MongoDB Casual Talks #1 2

MongoDB
MongoDB

http://www.mongodb.org/

http://www.mongodb.jp/

•10gen社が主体として開発しているオープンソース
所謂「NoSQL」の一つ

MongoDB is over?
MongoDBはオワコン？

http://suzuzuzuru.blogspot.jp/2012/04/mongodb.html

http://blog.engineering.kiip.me/post/20988881092/a-year-with-mongodb


MongoDB is over?
MongoDBはオワコン？

http://www.zopyx.com/blog/goodbye-mongodb


Cons.
MongoDBの欠点（主観含む）

•トランザクション未サポート

•トランザクションは甘え (ﾄﾞﾔｧ

•Global Lock（2.2からCollection Lockに？）

•システムリソースが肥大化（メモリ、ディスク）

•データ圧縮未対応（通信、データストア共）

•セキュリティ周りが弱い etc.


Cons.

•トランザクション未サポート

•トランザクションは甘え (ﾄﾞﾔｧ

•Global Lock（2.2からCollection Lockに？）

•システムリソースが肥大化（メモリ、ディスク）

•データ圧縮未対応（通信、データストア共）

•セキュリティ周りが弱い etc.


Compress
圧縮関連のJIRA

•BSONデータの圧縮→not supported!

https://jira.mongodb.org/browse/SERVER-164


Compress
圧縮関連のJIRA

•通信路の圧縮→not supported!

https://jira.mongodb.org/browse/SERVER-3018


Compress
Quoraに掲載されている「最も興味があるMongoDBのJIRA」

http://www.quora.com/MongoDB/What-are-the-most-interesting-MongoDB-JIRA-issues


Compress vs Not Compress
圧縮：非圧縮のデータサイズの差

•下記例は同一フォーマットの文字列データを格納
した際の比較（MongoDB / HBase）

•MongoDBはHBase（snappy圧縮時）の三倍強。
700000000 MongoDB
600000000 MongoDB(fragment)
500000000 HBase
HBase(fragment)
400000000 HBase(snappy)
300000000
200000000
100000000
0
size(1,000,000 record)


Cons.

•Big Dataを扱う環境にはあまり向かない。

•スケールするが故に、下手にそれなりの規模の
システムに導入するとサーバー無限増殖の刑
に...


圧縮


Casual Compression
MongoDBでのカジュアルなデータ圧縮

•以下について試してみました。
1.フィールド名をできるだけ短くする

2.特定のデータをbinary形式で保存

3.小さい正整数の整数符号化


#1 To shorten ﬁled name
フィールド名の短縮

•MongoDBはBSON形式でデータを保存

•BSONは１つのドキュメントの中にフィールド名
情報を持つ。

•複数のレコードが同一のフィールド名を持って
いても、１レコードごとに情報を持つ。



http://bsonspec.org/#/speciﬁcation



100万件で

約8MBの差


参考ブログ

http://christophermaier.name/blog/2011/05/22/MongoDB-key-names


OR Mapperを用いたﬁeld nameのマッピング

•OR Mapperでﬁeld nameのマッピングを行うと名
前が短すぎる弊害は多少抑制できる。

•JavaではMorphiaがオススメ。
http://code.google.com/p/morphia/

•Spring Dataは重厚すぎる気がする。


OR Mapperを用いたﬁeld nameのマッピング

@Data
@Entity(value = "slim")
class TestDTOSlim {
@Id
ObjectId id;
@Property(value = "u")
long uuid;
@Property(value = "n")
String name;
@Property(value = "d")
Date date;
}


#2 Convert to binary
特定のデータをbinary形式に変換

•MongoDBが圧縮をサポートしていないのでアプ
リケーション側で圧縮をしてbinaryで保存。

•特定のフィールドを圧縮

•BSON以外の構造化フォーマットを用いて複数
フィールドをまとめてシリアライズ→圧縮


検証に使用したデータモデル

public class NormalModel {
@Id
ObjectId oid;
long uuid;
int id;
char flag;
String name;
String description;
}


検証で使用した圧縮アルゴリズム

•Deﬂate(Best Compression)

•LZO

•Google Snappy

•LZ4


Google Snappy

•2011/4ごろにGoogleがオープンソースとして公開
した圧縮アルゴリズム。
高速な圧縮・伸張が特徴。

•http://code.google.com/p/snappy/


LZ4

•Google Snappyよりも圧縮・伸張速度が速いと言
われている圧縮アルゴリズム。

•http://code.google.com/p/lz4/


BSON以外のシリアライズ手法

•Message Pack
http://msgpack.org/


検証条件

•以下の条件で比較

1.何もしない

2.フィールド名の短縮

3. 2 + 特定のフィールドの圧縮

4.複数のフィールド情報をMessagePackでシリ
アライズ

5. 4.+圧縮

検証結果

normal
short key
short key + msgpack

1500000

1200000

900000

600000

300000

0
none deflate lzo snappy lz4


検証結果

normal
short key
1,2, 4（非圧縮） short key + msgpack

1500000

1200000

900000

600000

300000

0


検証結果

normal
short key
short key + msgpack

1500000 3,5（圧縮）

1200000

900000

600000

300000

0


検証結果

normal
short key
short key + msgpack

1500000

1200000

900000

600000

300000

0


検証結果

•「複数のフィールドをMessagePackでシリアライ
ズ＋圧縮アルゴリズムで圧縮」
の組み合わせで最大2/3の省サイズ化に成功。

•データパターン／データモデルによって傾向は
様々だと思う。

•圧縮・シリアライズのオーバーヘッドに注意。

•独自binary化すると後戻りできないので注意。


#3 Integer Encoding
整数値符号化

•たとえば数字の「１」を数バイト使用して表現す
るのはもったいない。→整数値符号化

•Variable Byte Code

•Simple9

•Simple16

•etc...


#3 Integer Encoding
Variable Byte Code

•整数値の値を最小１バイトで表現するための符号
化方式。数値部7bit(0~127)と、数値終端を表すフ
ラグ1bitの組み合わせで数値を符号化します。

•https://gist.github.com/3003981
• 0x00-0x7f ： 1xxxxxxx

• 0x80-0x3fff ： 0xxxxxxx 1xxxxxxx

• 0x4000-0x1fffff ： 0xxxxxxx 0xxxxxxx 1xxxxxxx
※「x」は0、もしくは1


#3 Integer Encoding
検証に使用したデータモデル

public class NormalModel{
! @Id
! ObjectId oid;
! @Property(value = "id")
! int id; //もしくはlong
}


#3 Integer Encoding
検証条件

•以下の条件で比較

1. 整数値をinteger(4byte)で保存

2. 整数値をlong(8byte)で保存

3. 整数値をVariable Byte Codeで変換して保存


#3 Integer Encoding
検証結果

integer long
variable byte code

37000000

36000000

35000000

34000000

33000000

32000000

31000000

30000000
max : 128 max : 16384 max : 2097152


#3 Integer Encoding
検証結果

•整数値符号化で保存をしたら、逆にIntegerよりも
サイズが大きくなった・・・

•BSONの仕様が関係
int32 : 4bytes
int64 : 8bytes
binary : int32 subtype(byte*)


Casual Compression
MongoDBでのカジュアルなデータ圧縮

•以下について試してみました。
1.フィールド名をできるだけ短くする
→◎

2.特定のデータをbinary形式で保存
→⃝

3.小さい正整数の整数符号化
→☓


参考情報


HBase
HBaseなら圧縮をサポートしてます

•HBaseなら....

•データの圧縮に標準で対応
（圧縮したいTableのFamilyごとに指定可能。
アルゴリズムも複数選択可能）

•可変長整数値に標準で対応
(VIntWritable / VLongWritable）

•大きいデータを扱う場合はHBaseを(ｒｙ


まとめ


Conclusion
まとめにかえて

•MongoDBはデータサイズが肥大化しがちです
が、アプリケーション側のカジュアルな工夫で多
少はデータサイズの削減ができます。

•用途に応じて、適切な現場でMongoDBを使いま
しょう。

•個人的にはRedisが好きです。


ご清聴
ありがとうございました


Casual Compression on MongoDB

More Related Content

What's hot

Similar to Casual Compression on MongoDB

More from moai kids

Casual Compression on MongoDB