Redisの速度を検証してみよう。

Redisの速度を検証してみよう。

この記事は、2020年3月16日に編集し、約 5 分で読めます。

始まり

先日上司にこう言われた。

「redisのリスト型は数が多くなると重くなるので注意」

しかし私は重くなるといわれると具体的にどれくらい重くなるのか知りたい派。

具体的なスピードが分からなければ、

どこまでがセーフなのか?

どこからがアウトなのか?

妥協ラインは?

仕様が分からないのならば、作りたいものも作れない。

なので自分の環境で実際に検証してみよう。

そもそもredisとは

メモリで管理するデータベースです。とても早い。

しかし、SQLみたいにデータをテーブルとしてまとめるのは苦手

リスト型は数が増える程、追加は遅くなるのか

予想ではそこまで遅くなるような事はないであろうと思っている。

でもLpushかRpushかで速度は変わるかもしれない。

 

以下の条件で検証する。

尚、今回要素に書き込む値は全て「true」です。

検証単位も秒です。同じ命令を100回繰り返してるので、実際はもっと早いです。

・要素数0のリスト型に100回データを追加する

・要素数100のリスト型に100回データを追加する

・要素数200のリスト型に100回データを追加する

.....

・要素数900のリスト型に100回データを追加する

要素数の数に応じて追加速度が遅くなるのならば速度は低下するハズである。

検証結果

0~100     0.0028040409088135

100~200    0.0028679370880127

200~300    0.0027220249176025

300~400    0.0028030872344971

400~500    0.0024170875549316

.....

2900~3000  0.0027751922607422

多少ばらつきはあるものの、要素数によって恐らくなる傾向はなかった。

Lpush、Rpushで試したがそこまで違いはなかった。

結論:要素数によって書き込む速度は変わらない

ガンガン書き込もう。

 

要素数が多いほど全件参照速度は遅くなるのか。

本題である。要素数が増えるほど速度は遅くなるのか。

以下の条件で検証する。

・要素数0で全件参照を100回行う

・要素数500で全件参照を100回行う

・要素数1000で全件参照を100回行う

・要素数1500で全件参照を100回行う

・要素数2000で全件参照を100回行う

・要素数2500で全件参照を100回行う

・要素数3000で全件参照を100回行う

各方法で10回行い、最速時間で比較する

検証結果

要素数0    0.0025110244750977

要素数500  0.016954898834229

要素数1000  0.031013011932373

要素数1500 0.046410083770752

要素数2000 0.06744909286499

要素数2500 0.086562871932983

要素数3000 0.13561391830444

 

凄い勢いで増えていったので、さらに検証した

要素数4000 0.17251300811768

要素数5000 0.23781895637512

要素数10000 0.51502299308777

結論:要素数の数に比例して増えるのではなく、数が増える程、遅延も増える

要素の増やしすぎは危険。

 

要素数が多いほど、単体参照速度は遅くなるのか。

上の全件参照は全件参照するので当然遅くなる。

では、数ある要素の中からインデックスを指定して1つだけ取得する場合、それは遅くなるのか?

遅くなるであろうが、全件参照程遅くはならないであろうと思っている。

以下の条件で検証する。

・要素数1000で500件目の要素を参照を100回行う

・要素数1500で750件目の要素を参照を100回行う

・要素数2000で1000件目の要素を参照を100回行う

 中略

・要素数5000で2500件目の要素数を参照を100回行う

検証結果

要素数500  0.0033140182495117

要素数1000  0.002723217010498

要素数1500 0.0029160976409912

要素数2000 0.0030660629272461

要素数2500 0.0031499862670898

要素数3000 0.0033440589904785

要素数5000 0.0034210681915283

要素数10000 0.0043261051177979

結論:要素数に応じて若干負荷が増えていくが、全件取得に比べたら圧倒的に早い。

思ってた以上に早い。

 

要素数に応じて、要素数の取得速度は遅くなるのか。

先ほどは要素数の内容を全件取得すると、速度が劇的に遅くなることが分かった。

では要素数の取得は遅くなるのだろうか?

以下の条件で検証する。

・要素数0で要素数の取得を100回行う

・要素数1000で要素数の取得を100回行う

・要素数2000で要素数の取得を100回行う

・要素数3000で要素数の取得を100回行う

中略

・要素数10000で要素数の取得を100回行う

検証結果

要素数0  0.0023350715637207

要素数1000  0.002424955368042

要素数2000 0.0023620128631592

要素数3000 0.0023491382598877

要素数5000 0.0026330947875977

要素数10000 0.0022468566894531

結論

要素数が増えても速度はそこまで変わらない。

検証の結果はどう役立つか

今回の検証の結果、リスト型からランダムに値を1回取得する場合、

全件参照して取得したデータ配列の中からランダムに選ぶよりも、

要素数を取得後、0から要素数の間のランダムな数字を選択し、単体参照する方が圧倒的に速い事が分かった。

前者の場合、1万件を全件取得 の時点で0.515秒かかるが、

後者の場合 要素数を取得(0.002秒)+単体取得(0.0043秒)なので速度が段違いである。

※今回は同じ命令を100回行って実行速度を検証しているので実際の速度はもっと早いです

 

次回に続くかもしれない。

 

システム開発やWebサイトのことでお悩みなら I-SEED にご相談ください!

I-SEED ではWebシステムやスマホアプリなどのシステム開発から、コーポレートサイトやECサイトなどのWeb制作、SEO対策やオウンドメディア構築・運用などのWebマーケティングまで、Webに関するさまざまなお悩みを解決します。

I-SEED では随時採用も行っています。エンジニア、ディレクター、デザイナー、ライター、マーケターなどの職種にご興味がある方は以下のページもご覧ください。

ブログページに戻る