Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
ローカルストレージでの永続化キューの方式を本気で比較してみた
サイエンスパーク株式会社 須藤圭太
1
• ID:suusanex( connpass・Twitter・GitHub共通)
• 名前:須藤圭太
• サイエンスパーク株式会社という独立系ソフトウェアベンダーに所属
• 4年ほど受託開発で、上流から下流まで全部を回す
• ここ6年ほどは、...
• C#で、永続化キューを作りたい
• 失われてはならないデータをストレージに保存するキュー
• 処理の重さやメモリストレージの使用量も大事だが、コーディングのしやすさや保守
性も重視したい
• 単純なバイナリファイルに自力で保存するキューを一...
• 基本的には単純なFIFOのキュー
• ただし、キューから取り出したデータの処理に失敗した場合はストレージから消して
はならないという要件がある
• つまり、デキュー処理は参照と削除を分けられるか、もしくは削除したものをキュー
に戻す必要があ...
• ゼロ点方式:参考値。計測器自体のゼロ点計測(永続化しない場合でも最低限必要に
なる所要時間の計測)
• バイナリ:独自フォーマットのバイナリファイルを使用し、スクラッチで実装を行う
方式。最も目的に合わせて無駄がない処理になるが、保守性は低...
• 10msごとに1つ、合計1000個のレコードを発生させた場合の計測結果
• どの方式も大差なし(MongoDBは計測漏れだが、おそらく同じようなもの)
10ms間隔
6
方式 所要時間[s] ストレージ使用量
[MB]
メモリ使用量
[MB...
• 1msごとに1つ、合計10000個のレコードを発生させた場合の計測結果
• SQLiteはここで脱落
1ms間隔
7
方式 所要時間[s] ストレージ使用量
[MB]
メモリ使用量
[MB]
ゼロ点方式 10 0 104
バイナリファイル
...
• 0.1msごとに1つ、合計100000個のレコードを発生させた場合の計測結果
• シンプルなバイナリファイルは速度が劣り始める
0.1ms間隔
8
方式 所要時間[s] ストレージ使用量
[MB]
メモリ使用量
[MB]
ゼロ点方式 11 ...
• Redisはかなり良いパフォーマンスを出したが・・・
• 完全なインメモリDBであり、ストレージにデータを移せない(ミラーリングのみ)
• 単一目的でメモリを使い切れるサーバー環境なら良いが、クライアントには不向き
• 今回は用途に合わなか...
• 0.1msごとに1つ、合計100000個のレコードを発生させた場合、かつpop後に即座
に処理に失敗し、キューへ戻した場合。(キューへの負荷を最大化したもの)
• MongoDBのメモリ使用量上限は250MBに設定
• MongoDBが優れ...
• MongoDBはバイナリファイルに処理速度で劣らず、むしろ負荷が上がるほど勝る
• MongoDBはバイナリファイルよりもメモリ使用量が多いが、上限を250MBに設定
しても十分に早い
• 実装はMongoDBがシンプル(元々キューに近いI...
• 探してみると、単純にバイナリファイルで実装する以外にも良い方法はある
• 良いライブラリを使って、楽に良い機能を作りましょう!
まとめ
12
SP2004-E04-01
Upcoming SlideShare
Loading in …5
×

of

ローカルストレージでの永続化キューの方式を本気で比較してみた Slide 1 ローカルストレージでの永続化キューの方式を本気で比較してみた Slide 2 ローカルストレージでの永続化キューの方式を本気で比較してみた Slide 3 ローカルストレージでの永続化キューの方式を本気で比較してみた Slide 4 ローカルストレージでの永続化キューの方式を本気で比較してみた Slide 5 ローカルストレージでの永続化キューの方式を本気で比較してみた Slide 6 ローカルストレージでの永続化キューの方式を本気で比較してみた Slide 7 ローカルストレージでの永続化キューの方式を本気で比較してみた Slide 8 ローカルストレージでの永続化キューの方式を本気で比較してみた Slide 9 ローカルストレージでの永続化キューの方式を本気で比較してみた Slide 10 ローカルストレージでの永続化キューの方式を本気で比較してみた Slide 11 ローカルストレージでの永続化キューの方式を本気で比較してみた Slide 12 ローカルストレージでの永続化キューの方式を本気で比較してみた Slide 13
Upcoming SlideShare
What to Upload to SlideShare
Next
Download to read offline and view in fullscreen.

0 Likes

Share

Download to read offline

ローカルストレージでの永続化キューの方式を本気で比較してみた

Download to read offline

勉強会で発表した資料。
https://sciencepark.connpass.com/event/172442/

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to like this

ローカルストレージでの永続化キューの方式を本気で比較してみた

  1. 1. ローカルストレージでの永続化キューの方式を本気で比較してみた サイエンスパーク株式会社 須藤圭太 1
  2. 2. • ID:suusanex( connpass・Twitter・GitHub共通) • 名前:須藤圭太 • サイエンスパーク株式会社という独立系ソフトウェアベンダーに所属 • 4年ほど受託開発で、上流から下流まで全部を回す • ここ6年ほどは、自社製品開発を担当 勉強会、今後も開いていきます。 https://sciencepark.connpass.com/ 自己紹介 2
  3. 3. • C#で、永続化キューを作りたい • 失われてはならないデータをストレージに保存するキュー • 処理の重さやメモリストレージの使用量も大事だが、コーディングのしやすさや保守 性も重視したい • 単純なバイナリファイルに自力で保存するキューを一つの基準として、他の方法を比 較検討してみた • SQLite • Redis • MongoDB やりたいこと 3
  4. 4. • 基本的には単純なFIFOのキュー • ただし、キューから取り出したデータの処理に失敗した場合はストレージから消して はならないという要件がある • つまり、デキュー処理は参照と削除を分けられるか、もしくは削除したものをキュー に戻す必要がある キューの要件 4
  5. 5. • ゼロ点方式:参考値。計測器自体のゼロ点計測(永続化しない場合でも最低限必要に なる所要時間の計測) • バイナリ:独自フォーマットのバイナリファイルを使用し、スクラッチで実装を行う 方式。最も目的に合わせて無駄がない処理になるが、保守性は低い。 • SQLite:組み込みRDB代表。トランザクションなどは工夫せず即座にストレージに 反映する • Redis:NoSQLの一つ。サーバー型なのでローカルにサーバーを立てて使用する。 • MongoDB:Redisと同様 • 測定に使用したソースコードはここにあります • https://github.com/suusanex/sample_persistence_queue_benchmark_test 測定方式 5
  6. 6. • 10msごとに1つ、合計1000個のレコードを発生させた場合の計測結果 • どの方式も大差なし(MongoDBは計測漏れだが、おそらく同じようなもの) 10ms間隔 6 方式 所要時間[s] ストレージ使用量 [MB] メモリ使用量 [MB] ゼロ点方式 10 0 99 バイナリファイル 方式 10 0.2 100 Redis AOF(EverySec) 12 6 115 SQLite 12 6 115 MongoDB - - -
  7. 7. • 1msごとに1つ、合計10000個のレコードを発生させた場合の計測結果 • SQLiteはここで脱落 1ms間隔 7 方式 所要時間[s] ストレージ使用量 [MB] メモリ使用量 [MB] ゼロ点方式 10 0 104 バイナリファイル 方式 13 0.2 107 Redis AOF(EverySec) 16 3 115 SQLite 110 0.3 123 MongoDB 14 0.6 293
  8. 8. • 0.1msごとに1つ、合計100000個のレコードを発生させた場合の計測結果 • シンプルなバイナリファイルは速度が劣り始める 0.1ms間隔 8 方式 所要時間[s] ストレージ使用量 [MB] メモリ使用量 [MB] ゼロ点方式 11 0 138 バイナリファイル 方式 53 19 152 Redis AOF(EverySec) 34 139 MongoDB 42 2 279
  9. 9. • Redisはかなり良いパフォーマンスを出したが・・・ • 完全なインメモリDBであり、ストレージにデータを移せない(ミラーリングのみ) • 単一目的でメモリを使い切れるサーバー環境なら良いが、クライアントには不向き • 今回は用途に合わなかったので脱落とした Redisは用途の都合で脱落 9
  10. 10. • 0.1msごとに1つ、合計100000個のレコードを発生させた場合、かつpop後に即座 に処理に失敗し、キューへ戻した場合。(キューへの負荷を最大化したもの) • MongoDBのメモリ使用量上限は250MBに設定 • MongoDBが優れている • (メモリ使用量が多いのは、計測ツールとDBの2つのプロセスがある分) 0.1ms間隔(処理即時エラー) 10 方式 所要時間[s] ストレージ使用量 [MB] メモリ使用量 [MB] ゼロ点方式 107 0 533 バイナリファイル 方式 532 200 181 MongoDB 425 164 489
  11. 11. • MongoDBはバイナリファイルに処理速度で劣らず、むしろ負荷が上がるほど勝る • MongoDBはバイナリファイルよりもメモリ使用量が多いが、上限を250MBに設定 しても十分に早い • 実装はMongoDBがシンプル(元々キューに近いI/F) • ↓ • バイナリファイルも良いが、MongoDBは保守性で勝るのでより良い 計測結果まとめ 11
  12. 12. • 探してみると、単純にバイナリファイルで実装する以外にも良い方法はある • 良いライブラリを使って、楽に良い機能を作りましょう! まとめ 12
  13. 13. SP2004-E04-01

勉強会で発表した資料。 https://sciencepark.connpass.com/event/172442/

Views

Total views

71

On Slideshare

0

From embeds

0

Number of embeds

12

Actions

Downloads

0

Shares

0

Comments

0

Likes

0

×