この投稿では、私の
失敗したパフォーマンステストについて
説明し 、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バイト
いくつかの連続したコマンドでテスト済み：
| 特徴 | 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,831 | 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ドル）
ありがとう、私の時間を無駄にした誰かに役立つことを願っています。