1。概要
DolphinDBデータベースは、高性能の分散時系列データベース（時系列データベース）であり、C ++で記述された列型リレーショナルデータベースであり、リアルタイムデータの処理に使用できる並列分散コンピューティングフレームワークが組み込まれています。膨大な履歴データ。
DolphinDBは、独自のスクリプト言語を提供するだけでなく、C ++、Java、C＃、Python、Rなどのプログラミング言語APIも提供するため、開発者はさまざまな開発環境でDolphinDBを使用できます。
この記事では、次のシナリオを含め、APIインターフェイス（C ++、Java、C＃、Python、R）とDolphinDBの相互作用のパフォーマンスをテストします。
- シングルユーザーがデータをメモリテーブルにアップロード
- 複数のユーザーが分散（DFS）データベースに同時にデータをアップロードする
- マルチユーザーが同時にDolphinDBからクライアントにデータをダウンロードします
- マルチユーザーは同時に計算タスク（特定の日の特定の株式の分レベルのk-lineを計算する）をDolphinDBに送信し、結果を返します
2.テスト環境
2.1ハードウェア構成
このテストでは、同じ構成の3つのサーバー（SERVER1、SERVER2、SERVER3）を使用し、各サーバーの構成は次のとおりです。
ホスト：PowerEdge R730xd
CPU：E5-265024コア48スレッド
メモリ：512G
ハードディスク：HDD 1.8T * 12
ネットワーク：10ギガビットイーサネット
OS：CentOSLinuxリリース7.6.1810
2.2ソフトウェア構成
C ++：GCC 4.8.5
JRE：1.8.0
C＃：. net 2.2.105
Python：3.7.0
R：3.5.2
DolphinDB：0.94.2
2.3テストフレームワーク
DolphinDBクラスターはSERVER1にデプロイされ、APIプログラムはSERVER2とSERVER3で実行され、テストのためにネットワークを介してSERVER1のDolphinDBデータノードに接続されます。
DolphinDBクラスター構成は次のとおりです。
クラスターには、1つの制御ノードと6つのデータノードが含まれます。
メモリ：32G /ノード* 6ノード= 192G
スレッド：8スレッド/ノード* 6ノード= 48スレッド
ハードディスク：各ノードには、1.8T /ノード* 6 = 9.6Tの独立したHDDハードディスクが装備されています。
3.シングルユーザーアップロードデータパフォーマンステスト
このセクションでは、APIを介してDolphinDBサーバーにデータをアップロードする単一のユーザーをテストします。SERVER1のDolphinDBクラスターにメモリテーブルを作成し、SERVER2でAPIプログラムを実行して、SERVER1のメモリテーブルにデータを書き込みます。
書き込まれるデータテーブルのフィールドには、STRING、INT、LONG、SYMBOL、DOUBLE、DATE、TIMEなどのさまざまなタイプのフィールドが含まれ、合計45列、それぞれ336バイト、合計100万行がアップロードされます。サイズは約336Mbです。毎回10〜100,000行をアップロードするときに、スループットと遅延をテストします。
このシナリオはシングルユーザーであり、ディスク操作を伴わないため、主にAPIプログラムデータ形式からDolphinDBデータ形式への変換パフォーマンスをテストします。CPUパフォーマンスとネットワークは、テスト結果により大きな影響を与えます。各APIのテスト結果は次のとおりです。
表1.C ++ APIシングルユーザーがデータをメモリテーブルにアップロードするテスト結果
表2.JavaAPIシングルユーザーがデータをメモリテーブルにアップロードするテスト結果
表3.C＃APIシングルユーザーがデータをメモリテーブルにアップロードするテスト結果
表4.PythonAPIシングルユーザーがデータをメモリテーブルにアップロードするテスト結果
表5.RAPIシングルユーザーがデータをメモリテーブルにアップロードするテスト結果
表6.メモリテーブルにデータをアップロードする各APIシングルユーザーの書き込み速度の比較（単位：メガ/秒）
図1.APIアップロードデータからメモリテーブルへのパフォーマンスの比較
1人のユーザーによるメモリテーブルへの書き込みのテスト結果から、バッチサイズが大きくなると、パフォーマンスが大幅に向上します。これは、データの合計量が同じである場合、一度にアップロードされるデータの行数が増えるためです。アップロード時間が短くなります。、ネットワーク通信が少なくなります。
C ++のパフォーマンスは最高で、C＃のパフォーマンスは低くなります。PythonとRの基盤となる実装はどちらもC ++で書き直されており、パフォーマンスの傾向は同じです。バッチサイズが小さい場合、C ++モジュールの呼び出し回数が増えるため、パフォーマンスが低下し、パフォーマンスが低下します。バッチサイズが1000行を超えると、パフォーマンスが大幅に向上します。PythonとRを使用してデータをアップロードする場合は、アップロードのバッチサイズを増やすことをお勧めします。
4.マルチユーザー同時アップロードデータのパフォーマンステスト
このセクションでは、テストでAPIを使用して、複数のユーザーがSERVER1のDFSデータテーブルにデータを同時にアップロードします。SERVER2とSERVER3では、複数のユーザーがネットワークを介して同時に書き込み操作を開始します。
各ユーザーは合計500万行を書き込み、各ユーザーは25,000行を書き込み、それぞれは336バイトであるため、各ユーザーが書き込むデータの合計量は840Mbです。同時ユーザー数が1〜128の場合に、同時書き込みの待機時間とスループットをテストします。
SERVER2とSERVER3で実行するユーザー数を均等に分散します。たとえば、16人のユーザーをテストする場合、2台のサーバーがそれぞれ8台のクライアントプログラムを実行します。テストには同時書き込みが含まれ、書き込まれたデータはネットワークを介してSERVER1に送信され、ディスクに保存されます。したがって、DolphinDBシステムがサーバーのCPU、ハードディスク、ネットワーク、およびその他のリソースを最大限に活用できるかどうかをテストできます。各APIのテスト結果は次のとおりです。
表7.DFSテーブルのテスト結果へのデータのC ++ APIマルチユーザー同時アップロード
表8.DFSテーブルへのJavaAPIマルチユーザー同時アップロードデータのテスト結果
表9.C＃APIマルチユーザー同時アップロードデータのDFSテーブルへのテスト結果
表10.DFSテーブルへのPythonAPIマルチユーザー同時アップロードデータのテスト結果
表11.RAPIマルチユーザー同時アップロードデータのDFSテーブルへのテスト結果
表12.さまざまなAPIデータをDFSテーブルにアップロードしたテスト結果の比較（単位：メガ/秒）
図2.DFSテーブルへのAPIアップロードデータのパフォーマンス比較
テスト結果は、ユーザー数が16未満の場合、C ++とJavaのパフォーマンス上の利点は明らかですが、PythonとC＃のパフォーマンスはわずかに悪く、スループットは基本的に直線的に増加することを示しています。ユーザー数が16を超えると、ネットワーク伝送が限界に達し、パフォーマンスのボトルネックになり、スループットは基本的にネットワークの限界に維持されます。ネットワークは1Gの制限がある10ギガビットイーサネットですが、送信データが圧縮されているため、システムスループットは最大1.8G /秒に達する可能性があります。
5.マルチユーザー同時ダウンロードデータパフォーマンステスト
このセクションでは、APIを介して複数のユーザーがDolphinDBから同時にデータをダウンロードする速度をテストします。データベースはSERVER1にデプロイされ、複数のユーザーがSERVER2とSERVER3に同時にデータをダウンロードし、各ユーザーが接続するデータノードをランダムに選択します。各ユーザーがダウンロードするデータの合計量は500万行、各行は45バイト、合計225Mb、各ダウンロードデータは25,000行であり、同時ユーザー数が1〜128のシナリオでの同時パフォーマンステストされます。
次の2つのシナリオで、同時クライアントダウンロードデータのパフォーマンスをテストしました。
- 5年間のデータ量：5年間のデータからダウンロードする日付と記号をランダムに選択します。関連するデータの量は約12Tです。データの量はシステムメモリを大幅に超えるため、ダウンロードするたびにディスクからデータをロードする必要があります。
- 1週間のデータ量：先週のデータからランダムにシンボルを選択してダウンロードします。関連するデータ量は約60Gです。DolphinDBに割り当てられたメモリは60Gのデータを保持するのに十分であり、すべてのデータはキャッシュにあるため、ダウンロードごとにディスクからデータをロードする必要はありません。
各APIのパフォーマンステストの結果は次のとおりです。
表13.C ++ APIデータのダウンロードデータのテスト結果
表14.JavaAPIデータのダウンロードデータのテスト結果
表15.C＃APIデータのダウンロードデータのテスト結果
表16.PythonAPIデータのダウンロードデータのテスト結果
表17.RAPIデータのダウンロードデータのテスト結果
表18.各APIの5年間のデータダウンロードスループットの比較（単位：メガ/秒）
図3.APIの5年間のデータダウンロードスループットの比較
テスト結果から、ユーザー数が64未満の場合、スループットは基本的にユーザー数の増加に比例して増加します。各APIのパフォーマンスに大きな違いはありません。最大スループットは約350Mです。データセット以降が12Tの場合、DolphinDBはすべてのデータをキャッシュできず、毎回ディスクからロードする必要があり、ディスクがシステムのボトルネックになります。
ユーザー数が128の場合、パフォーマンスが低下します。その理由は、DolphinDBがパーティションに従ってデータをロードするためです。ユーザーが特定の日に特定のストックのデータをダウンロードしたい場合、パーティション全体がメモリにロードされます。その後、ユーザーが必要とするデータが返されます。ユーザーに。同時ユーザー数が多すぎて同時にデータのダウンロード要求が開始され、データ量が多すぎるため、基本的にディスクからデータをロードする必要があります。128人のユーザーが同時にディスクを読み取るため、IOが強化されます。競争し、全体的なスループットを低下させます。
したがって、データの同時実行性が高いシナリオでは、各ノードが複数の独立したデータボリュームを構成して、IOの同時実行性を向上させることをお勧めします。
表19.さまざまなAPIの1週間のデータダウンロードスループットの比較（単位：メガ/秒）
図4.さまざまなAPIの1週間の同時データダウンロードスループットの比較
テスト結果から、各APIのスループットは、基本的に同時ユーザー数の増加に比例して増加します。DolphinDBに割り当てられたメモリは、1週間すべてのデータを保持でき、毎回ディスクからロードする必要はありません。したがって、最大スループットは1.4です。G付近でネットワーク制限に達しました（ネットワーク制限は1Gで、データ圧縮のため、実際のビジネスデータ量は1.4Gです）。
6.並行パフォーマンステストを計算する
このセクションのテストでは、APIを介して並行コンピューティングタスクをDolphinDBに送信し、特定の日の特定の株式の分レベルのKラインを計算します。計算の総数は約1億です。
5年間のデータ量と1週間のデータ量の2つのシナリオで、さまざまな数の同時ユーザー（1〜128）のコンピューティングパフォーマンスをテストします。
- 5年間の総データ量は12Tであり、メモリを完全にキャッシュできないため、ほとんどすべての計算でディスクからデータをロードする必要があります。これはIOを多用するアプリケーションのシナリオであり、ディスクはパフォーマンスのボトルネックになると予想されます。
- 1週間あたりのデータ量は約60Gで、DolphinDBデータノードは完全にキャッシュできるため、計算量の多いアプリケーションシナリオになります。複数のユーザーが同時に存在する場合、CPUがパフォーマンスのボトルネックになると予想されます。
各APIのテスト結果は次のとおりです。
表20.分バーのパフォーマンス結果のC ++ API計算
表21.分バーのパフォーマンス結果のJavaAPI計算
表22.C＃APIは、分バーのパフォーマンス結果を計算します
表23.Python APIは、分バーのパフォーマンス結果を計算します
表24.分バーのRAPI計算パフォーマンス結果
表25.さまざまなAPIの5年間のデータ計算スループットの比較（単位：メガ/秒）
図5.さまざまなAPIの5年間のデータ並行コンピューティングスループットの比較
上の図から、ユーザー数が16未満の場合、各APIのスループットは基本的に直線的に増加することがわかります。ユーザー数が64に達すると、スループットが最大になり、ユーザー数が128に増加すると、スループットが最大になります。 、代わりにスループットが低下します。2つの側面があります。1つは、日付と記号がランダムに選択されるたびに、5年間で合計12Tのデータです。同時ユーザーの数が特定の数に増加した後、DolphinDBメモリ完全に対応できないため、メモリとディスク間で大量のデータ交換が発生し、パフォーマンスが低下します。一方、同時ユーザーが多すぎると、システム内のコンピューティングタスクが多すぎて、タスクのスケジューリングに時間がかかります。分散が増加し、スループットが低下します。
表22.さまざまなAPIの1週間のデータ計算スループットの比較（単位：メガ/秒）
図5.さまざまなAPIの1週間のデータ同時コンピューティングスループットの比較
テスト結果から、ユーザー数が64人未満の場合、スループットは着実に向上し、各APIのパフォーマンスに大きな違いはないことがわかります。64人の同時ユーザーがいる場合、パフォーマンスは最大に達し、コンピューティングデータのスループットは7G /秒に近くなります。システムタスクが多すぎるために128Gに達し、物理マシンスレッドの数（クラスター内の物理マシンの数は48スレッド）を大幅に超え、スレッドの切り替えが頻繁に発生します。クラスター内の多数のタスクにより、スケジューリングと配布の時間が増加し、スループットが低下します。
7.まとめ
今回は、さまざまな同時ユーザー数でのデータアップロード、データダウンロード、計算におけるDolphinDB C ++、Java、C＃、Python、RAPIのパフォーマンスを詳細にテストしました。結論は次のとおりです。
メモリテーブルへのシングルユーザーデータのアップロード、 C ++のパフォーマンスが最高、最大スループットが265Mbit / sに達する、Java、Python、Rも160〜200Mbit / sに達する、C＃のパフォーマンスがわずかに悪い、最大スループットが約60M。また、バッチサイズが大きくなると、特にPythonとRの場合、スループットが大幅に向上します。したがって、書き込み時には、遅延とメモリが許す限り、バッチサイズを増やすようにしてください。
マルチユーザーは分散DFSテーブルに同時に書き込みます。ユーザー数が増えると、スループットはネットワーク制限に達する前に着実に増加します。全体的なパフォーマンスC ++およびJavaパフォーマンスの利点は明らかです。同時ユーザー数が約32の場合、ネットワークこれがボトルネックになっており、各APIのパフォーマンスは基本的に同じです。データ圧縮により、システムの最大スループットは1.8G /秒に達します。
マルチユーザーは同時にデータをダウンロードします。データセットが5年間12Tであるシナリオでは、ユーザー数が64、つまり約380 Mbit / sのときに最大スループットに達します。このシナリオでは、すべてのデータをディスクからロードする必要があり、ディスクの読み取りがパフォーマンスのボトルネックになります。ユーザー数が128の場合、各ノードはダウンロードするために多数のユーザーを受け入れる必要があるため、ディスクIOの競合は激しくなります。 、結果として全体的なスループットが低下します。データセットが1週間あたり約60Gのシナリオでは、6つのデータノードがすべてのデータをキャッシュできるため、すべてのデータがメモリ内にあり、ディスクからロードする必要がなく、スループットがネットワーク制限に達する可能性があります。データ圧縮により、クラスタースループットは1.8G /秒であり、同時ユーザーの増加に伴い、スループットは着実に増加しています。
マルチユーザー並行コンピューティング。各APIは、特定の日の特定の在庫を計算するための1分間のK-lineタスクをDolphinDBに送信し、計算結果を返します。ネットワークを介して送信されるデータの量は非常に少なく、ほとんどの場合、サーバー側で実行されるため、各APIのパフォーマンスは基本的に同じです。5年と1週間のデータ量のシナリオでは、スループットの傾向は基本的に同じです。ユーザー数が64のときに両方が最大スループットに達します。データ量が5年の場合、最大スループットは1.3Gです。 1週間あたりのデータ量は、すべてのデータがメモリ内にあるためであり、最大スループットは7GBに達します。ユーザー数が128の場合、主にシステムタスクが多すぎて物理マシンスレッドの数を大幅に超えてスループットが低下し（クラスターは合計48スレッドの物理マシンに配置されます）、スレッドの切り替えが頻繁に発生します。クラスター内の多数のタスクのスケジューリングと分散が増加します。
一般に、DolphinDBはAPIを使用して、データの取得、データのアップロード、データの計算などのタスクを実行します。同時実行性の増加に伴い、パフォーマンスは着実に向上し、基本的にほとんどのビジネスのパフォーマンス要件を満たしています。