Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (16)
Semelhante a ローカルストレージでの永続化キューの方式を本気で比較してみた
Semelhante a ローカルストレージでの永続化キューの方式を本気で比較してみた (20)
Mais de Study Group by SciencePark Corp.
Mais de Study Group by SciencePark Corp. (20)
Último
Último (7)
ローカルストレージでの永続化キューの方式を本気で比較してみた
- 2. • ID：suusanex（ connpass・Twitter・GitHub共通） • 名前：須藤圭太 • サイエンスパーク株式会社という独立系ソフトウェアベンダーに所属 • 4年ほど受託開発で、上流から下流まで全部を回す • ここ6年ほどは、自社製品開発を担当 勉強会、今後も開いていきます。 https://sciencepark.connpass.com/ 自己紹介 2
- 3. • C#で、永続化キューを作りたい • 失われてはならないデータをストレージに保存するキュー • 処理の重さやメモリストレージの使用量も大事だが、コーディングのしやすさや保守 性も重視したい • 単純なバイナリファイルに自力で保存するキューを一つの基準として、他の方法を比 較検討してみた • SQLite • Redis • MongoDB やりたいこと 3
- 4. • 基本的には単純なFIFOのキュー • ただし、キューから取り出したデータの処理に失敗した場合はストレージから消して はならないという要件がある • つまり、デキュー処理は参照と削除を分けられるか、もしくは削除したものをキュー に戻す必要がある キューの要件 4
- 5. • ゼロ点方式：参考値。計測器自体のゼロ点計測（永続化しない場合でも最低限必要に なる所要時間の計測） • バイナリ：独自フォーマットのバイナリファイルを使用し、スクラッチで実装を行う 方式。最も目的に合わせて無駄がない処理になるが、保守性は低い。 • SQLite：組み込みRDB代表。トランザクションなどは工夫せず即座にストレージに 反映する • Redis：NoSQLの一つ。サーバー型なのでローカルにサーバーを立てて使用する。 • MongoDB：Redisと同様 • 測定に使用したソースコードはここにあります • https://github.com/suusanex/sample_persistence_queue_benchmark_test 測定方式 5
- 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. • 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. • 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. • Redisはかなり良いパフォーマンスを出したが・・・ • 完全なインメモリDBであり、ストレージにデータを移せない（ミラーリングのみ） • 単一目的でメモリを使い切れるサーバー環境なら良いが、クライアントには不向き • 今回は用途に合わなかったので脱落とした Redisは用途の都合で脱落 9
- 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. • MongoDBはバイナリファイルに処理速度で劣らず、むしろ負荷が上がるほど勝る • MongoDBはバイナリファイルよりもメモリ使用量が多いが、上限を250MBに設定 しても十分に早い • 実装はMongoDBがシンプル（元々キューに近いI/F） • ↓ • バイナリファイルも良いが、MongoDBは保守性で勝るのでより良い 計測結果まとめ 11
- 13. SP2004-E04-01