AmazonでNoSQLデータベースのパフォーマンスを誤ってテストする方法

この投稿では、私の失敗したパフォーマンステストについて説明し 、Amazon EC2コンテナーに埋め込まれたLMDBからのいくつかの誤った ARDBパフォーマンスの数字も示しています。

足はどこから成長しますか

このプロジェクトでは、データベースに数千の行を可能な限り短時間で書き込むことが必要になる場合があると考えています。 もちろん、少し掘り下げてLMDBが気に入ったので、メインデータベースをロードしたくありません。 ARDBは、Redisとして最後に到達できるようにするラッパーです



残念ながら、Amazon ec2でこの奇跡のパフォーマンステストを見つけることができなかったので、自分で調べてみることにしました。

免責事項

投稿はNoSQLデータベースの選択に関するものではありません... 1つのデータベースのみが異なる構成でテストされました

設備と設置

4つの構成で実行されたテスト

• 2つのt2.microインスタンス（無料利用枠のフレームワーク内）-ローンがある場合、インスタンスは弱くなります-1つのCPUの100％を提供し、基本的なパフォーマンスは10％CPUです
  
  
  • GP2 SSDボリューム -最も遅いSSD、基本速度は100 IOPS、
    
    （ ただし、時折最大300,000 IOPSを与えることができます ）
  • IO2 SSDボリューム+ 3000プロビジョニングされたIOPS-毎秒3,000のディスク操作を保証
  • IO2 SSDボリューム+ 6000プロビジョニングされたIOPS-毎秒6,000のディスク操作を保証
  
  
  
• i3.large DB + m4.xlargeユーザー-i3.largeインスタンスには専用のNVMe SSDがあり、これは非常に高速です

テスト用のすべてのコンポーネントはソースからコンパイルされました。



典型的なインストールシナリオ：

yum install git yum install gcc git checkout git://smth cd smth make
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

間違い

主な間違い-計画はありませんでした...アイデアだけがありました。 また、アクティブな使用の開始時にほとんどのサービスがバーストするAmazonの機能を考慮しなかったため、パフォーマンスが低下します。これは以下に適用されます。

• ディスク速度
• ネットワーク速度
• 生産性が向上したインスタンスのCPU速度
• RAMにはほとんどありませんが、すべてが可能です

インスタンスの誤った選択の結果-テストされたサーバーのCPUが完全にロードされていないことがよくありました



理想的には、実際の使用方法を模倣する価値がありますが、いつものように時間がありません...



これらのすべての点を除いて、以下の図はすべて、あくまでも指標であり、合成紳士です。

測定

小さなデータセット

データセットは控えめで、待つことは望んでいませんでしたが、見積もりを得るために-はい、望みました。



キーの数：1,000,000キー（データベース内の650kエントリを読み取ります）

顧客：50

レコードサイズ：3,000バイト



いくつかの連続したコマンドでテスト済み：

 #   ./redis-benchmark -n 1000000 -r 1000000 -h ec2-xx-xx-xx-xx.eu-west-2.compute.amazonaws.com -p 16379 -t set -d 3000 #    100k ./redis-benchmark -n 1000000 -r 100000 -h ec2-xx-xx-xx-xx.eu-west-2.compute.amazonaws.com -p 16379 -t get -d 3000 #    1m ./redis-benchmark -n 1000000 -r 1000000 -h ec2-xx-xx-xx-xx.eu-west-2.compute.amazonaws.com -p 16379 -t get -d 3000
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

特徴	t2.micro			i3.large
	GP2	IO1
		3000 PIOPS	6000 PIOPS
サーバー価格	10ドル	10ドル	10ドル	130ドル
ディスク価格	1ドル	9ドル**	18ドル**	1ドル
PIOPS価格	-	195ドル	390ドル	-
価格、合計	11ドル	214ドル	418ドル	131ドル
CPU	10-100％	10-100％	10-100％	200％
RAM	1GB	1GB	1GB	16GB
IOPS	100、 バーストで最大300,000	3,000	6,000	100,000
記録、一定の負荷	700（ディスク調整済み） 1,700（CPUスロットル）	1,300	2,300	27,000 ***
記録、バースト	2,700	10,000	> 10,000
100kセットからの読み取り、安定した負荷	<4,000	11,000 *	21,000 *
100kセットからの読み取り、バースト	35,000
1mセットからの読み取り、安定した負荷	<4,000	3,000	5,000	43,000 *、 ***
1mセットからの読み取り、バースト	6,000

*すべてのデータはRAMに配置されます

** Amazonの制限、ギガバイトあたり50 PIOPS以下

***「以上」と読みます。これらのテストのボトルネックは、redis-benchmarkが起動されたサーバーからの伝送速度です。

i3.large

ここでは、さまざまなサイズのデータ​​ベースでテストが行​​われました

特徴	DBサイズ、キー
	10万	1m	10m	30m
読み取り速度	41,407	42,977	43,220	17,286 *
読み取り遅延、最大1ミリ秒	60.14％	62.34％	60.27％	2.88％
読み取りレイテンシ、最大5ms	99.97％	100.00％**	99.99％	99.16％
最大読み取り遅延	6ms **	3ms **	13ms **	14ms **
書き込み速度	34,83​​1	26,911	15,967 *	10,353 *
記録遅延、最大1ミリ秒	11.96％	8.66％	5.22％	2.88％
記録遅延、最大5ms	99.53％	97.50％	96.15％	82.65％
記録遅延、最大50ミリ秒	100％	99.99％	99.74％	99.68％
記録遅延、最大100ミリ秒	100％**	99.99％	99.84％	99.75％
記録遅延、最大300ミリ秒	100％**	99.99％	99.94％	99.87％
録音遅延、最大500ミリ秒	100％**	100％	99.96％	99.91％
最大記録遅延	17ms **	604ms	3104ms	5059ms

*「以下」と読みます。これらのテストのボトルネックは、redis-benchmarkが起動されたサーバーからの転送速度です。

**明確な理由で正確に200ミリ秒間遅延した結果がスローされた; Amazonのせいだ

結論

• gp2ディスクを備えたt2.microインスタンスの良好なパフォーマンス、月11ドルで、1秒あたり1,000の書き込み要求を安定して処理するデータベースを取得できます。また、多くのアプリケーションに十分な3,000 WPSを時々提供します。
• 理論的には、データベースにすでに100万のレコードがある場合のARDB + LMDBの書き込みパフォーマンスは、「diskIOPS / 3」とみなすことができます
• プロビジョンドIOPSを備えたIO1ディスクは成果を上げていません。ローカルSSDで最適化されたインスタンスを取得する方がはるかに安価です
• i3.largeインスタンスの場合-適切な数（月額130ドル）

ありがとう、私の時間を無駄にした誰かに役立つことを願っています。