Casual Compression on MongoDB

Casual Compressionon　　　

-present at MongoDB Casual Talks-

@just_do_neet

MongoDB Casual Talks #1

Today’s Agenda

•MongoDBの課題

•MongoDBでのデータ圧縮

•まとめ

今日のお題目

2


MongoDB

http://www.mongodb.org/

http://www.mongodb.jp/

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

3

MongoDB






MongoDB is over?

4

MongoDBはオワコン？

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

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






MongoDB is over?

5

MongoDBはオワコン？

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




Cons.

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

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

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

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

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

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

MongoDBの欠点（主観含む）

6


Cons.

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

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

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

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

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

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


7


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

Compress圧縮関連のJIRA

8

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




•通信路の圧縮→not supported!

Compress圧縮関連のJIRA

9





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

10

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




Compress vs Not Compress

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

•MongoDBはHBase（snappy圧縮時）の三倍強。

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

0100000000200000000300000000400000000500000000600000000700000000

size(1,000,000 record)

MongoDBMongoDB(fragment)HBaseHBase(fragment)HBase(snappy)

11


Cons.

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

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


12


圧縮

13


Casual Compression

•以下について試してみました。

1.フィールド名をできるだけ短くする

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

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

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

14


#1 To shorten filed name

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

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

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

フィールド名の短縮

15


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

16

http://bsonspec.org/#/specification





17



18

100万件で

約8MBの差


#1 To shorten filed name参考ブログ

19

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




#1 To shorten filed name参考ブログ

20





#1 To shorten filed name

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

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

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

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

21

http://code.google.com/p/morphia/

http://code.google.com/p/morphia/


#1 To shorten filed nameOR Mapperを用いたfield nameのマッピング

22

@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

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

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

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

特定のデータをbinary形式に変換

23


#2 Convert to binary検証に使用したデータモデル

24

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



•Deflate(Best Compression)

•LZO

•Google Snappy

•LZ4

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

25



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

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

Google Snappy

26

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

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



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

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

LZ4

27

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

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



•Message Packhttp://msgpack.org/

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

28

http://msgpack.org/

http://msgpack.org/



•以下の条件で比較

1.何もしない

2.フィールド名の短縮

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

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

5. 4.+圧縮

検証条件

29


#2 Convert to binary検証結果

30

0

300000

600000

900000

1200000

1500000

none deflate lzo snappy lz4

normalshort keyshort key + msgpack



31

0

300000

600000

900000

1200000

1500000


normalshort keyshort key + msgpack1,2, 4（非圧縮）



32

0

300000

600000

900000

1200000

1500000



3,5（圧縮）



33

0

300000

600000

900000

1200000

1500000





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

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

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

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

検証結果

34


#3 Integer Encoding

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

•Variable Byte Code

•Simple9

•Simple16

•etc...

整数値符号化

35


#3 Integer Encoding

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

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

• 0x80-0x3fff ： 0xxxxxxx 1xxxxxxx

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

Variable Byte Code

36

https://gist.github.com/3003981

https://gist.github.com/3003981


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

37

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で変換して保存

検証条件

38


#3 Integer Encoding検証結果

39

30000000

31000000

32000000

33000000

34000000

35000000

36000000

37000000

max : 128 max : 16384 max : 2097152

integer longvariable byte code


#3 Integer Encoding

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

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

検証結果

40


Casual Compression

•以下について試してみました。

1.フィールド名をできるだけ短くする→◎

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

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

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

41


参考情報

42


HBase

•HBaseなら....

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

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

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

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

43


まとめ

44


Conclusion

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

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

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

まとめにかえて

45


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

46

Documents

Casual Compression on MongoDB