MongoDBのノードからの遅延テスト
3012 ワード
ノードからの遅延テストについて:
遅延時間を手動で設定する方法で、プライマリ・スレーブの書き込み/読み取りの遅延時間を2つのデータベースでテストしました.
プライマリスレーブノードの遅延時間は約0.3秒である.
このテストは私が想像していたよりずっと大きくて、遅延も10-30ミリ秒ぐらいだと思っていました.
このテストでは、「0.3秒遅延した後、ノードから挿入されたデータの割合が大きいほど検索できる」としか言えないかもしれません.
挿入後すぐにデータを返す場合は、一時的にプライマリノードからのデータの読み出ししか指定できません.
****************************************************************************************************
テスト1:サイクルN回、
1. メインノード挿入_id=i,
2.遅延時間の長さを設定し、
3.ノードからのクエリー_id=iで、挿入された時間が表示されます.
試験庫(1主、1従、1仲裁、バージョン2.6):
1.遅延が設定されていない場合、ノードからデータの78/1999に問い合わせることができる
2.クエリー時間が0.1秒遅れて、ノードからデータの360/499をクエリーできます.
3.クエリー時間を0.2秒遅らせ、ノードからデータをクエリーできる449/499
4.クエリー時間は0.3秒後に遅延し、ノードからデータの473/499にクエリーできます.
別のデータベース環境(1マスター4スレーブ、バージョン2.6):
1.遅延を設定しない場合、ノードからデータの45/999を問い合わせることができる
2.クエリ時間を0.1秒遅らせ、ノードからデータの433/499をクエリできる
3.クエリー時間を0.2秒遅らせ、ノードからデータの492/499にクエリーできます.
4.クエリー時間を0.3秒遅らせ、ノードからデータの498/499にクエリーできます.
3.2.3バージョンクラスタ環境テスト(1 p+2 s)
1.遅延を設定場合、ノードからデータの281/500 2に問い合わせることができる.クエリ時間は0.1秒後に遅延し,ノードからデータの495/500にクエリできる.
3.0以上のバージョンでは、パフォーマンスが大幅に向上しました.
(473/499、499はループの合計数、473はサブノードで挿入されたばかりのデータをクエリーする数)
(以上、単一の挿入のみをテストしたが、プライマリノードが複数のレコードを更新すると、複数のレコードの変更により、スレーブノードが複数のレコードとしてそれぞれ処理されるため、ノードからの遅延が大きくなる可能性がある)
テスト2:テスト1でロック競合が発生する可能性があることを考慮すると、プライマリ・ライブラリにデータをループ挿入した後、ログがスレーブ・ノードに同期し、ノードからデータを再再生する場合、ロックの問題が発生する可能性があります.
テスト1の時間を0に遅らせる.X秒、ライブラリの他のテーブルとデータを挿入するように変更した後、テストテーブルのデータがスレーブノードに同期されているかどうかを確認します.
テストでは、他のテーブルのデータが多く挿入される場合(各テーブルのデータ挿入時間は数ミリ秒しかかかりません).ノードデータからのデータの再生が遅い.
(テストライブラリでテスト)
--------------------------------------------------------------------------------------------
テスト1 pythonスクリプト:
テスト2スクリプト:
#time.sleep(0.1)は、ループが他のテーブルにデータを挿入するように変更され、ループが大きいほどライブラリからのデータの再生が遅くなります.
for j in range(2,20):
tst_db.get_collection('test%s'%str(j).zfill(2)).insert({"_id":i,"date":datetime.datetime.now()})
遅延時間を手動で設定する方法で、プライマリ・スレーブの書き込み/読み取りの遅延時間を2つのデータベースでテストしました.
プライマリスレーブノードの遅延時間は約0.3秒である.
このテストは私が想像していたよりずっと大きくて、遅延も10-30ミリ秒ぐらいだと思っていました.
このテストでは、「0.3秒遅延した後、ノードから挿入されたデータの割合が大きいほど検索できる」としか言えないかもしれません.
挿入後すぐにデータを返す場合は、一時的にプライマリノードからのデータの読み出ししか指定できません.
****************************************************************************************************
テスト1:サイクルN回、
1. メインノード挿入_id=i,
2.遅延時間の長さを設定し、
3.ノードからのクエリー_id=iで、挿入された時間が表示されます.
試験庫(1主、1従、1仲裁、バージョン2.6):
1.遅延が設定されていない場合、ノードからデータの78/1999に問い合わせることができる
2.クエリー時間が0.1秒遅れて、ノードからデータの360/499をクエリーできます.
3.クエリー時間を0.2秒遅らせ、ノードからデータをクエリーできる449/499
4.クエリー時間は0.3秒後に遅延し、ノードからデータの473/499にクエリーできます.
別のデータベース環境(1マスター4スレーブ、バージョン2.6):
1.遅延を設定しない場合、ノードからデータの45/999を問い合わせることができる
2.クエリ時間を0.1秒遅らせ、ノードからデータの433/499をクエリできる
3.クエリー時間を0.2秒遅らせ、ノードからデータの492/499にクエリーできます.
4.クエリー時間を0.3秒遅らせ、ノードからデータの498/499にクエリーできます.
3.2.3バージョンクラスタ環境テスト(1 p+2 s)
1.遅延を設定場合、ノードからデータの281/500 2に問い合わせることができる.クエリ時間は0.1秒後に遅延し,ノードからデータの495/500にクエリできる.
3.0以上のバージョンでは、パフォーマンスが大幅に向上しました.
。
(1p+2s+1a,2g ,mongoDB ver:3.2.7 ). 0.002 sec.
(473/499、499はループの合計数、473はサブノードで挿入されたばかりのデータをクエリーする数)
(以上、単一の挿入のみをテストしたが、プライマリノードが複数のレコードを更新すると、複数のレコードの変更により、スレーブノードが複数のレコードとしてそれぞれ処理されるため、ノードからの遅延が大きくなる可能性がある)
テスト2:テスト1でロック競合が発生する可能性があることを考慮すると、プライマリ・ライブラリにデータをループ挿入した後、ログがスレーブ・ノードに同期し、ノードからデータを再再生する場合、ロックの問題が発生する可能性があります.
テスト1の時間を0に遅らせる.X秒、ライブラリの他のテーブルとデータを挿入するように変更した後、テストテーブルのデータがスレーブノードに同期されているかどうかを確認します.
テストでは、他のテーブルのデータが多く挿入される場合(各テーブルのデータ挿入時間は数ミリ秒しかかかりません).ノードデータからのデータの再生が遅い.
(テストライブラリでテスト)
--------------------------------------------------------------------------------------------
テスト1 pythonスクリプト:
#primary
tst_conn = pymongo.MongoClient(['mongodb://10.0.0.48:27017'])
tst_db=tst_conn.test
#slave
tst_conn2 = pymongo.MongoClient(['mongodb://10.0.0.67:27017'])
tst_db2 = tst_conn2.test
for i in range(1,500):
#primary insert data
tst_db.test01.insert({"_id":i,"date":datetime.datetime.now()})
print 'i=%d'%i,datetime.datetime.now()
#sleep
time.sleep(0.1)
#slave select data
cur = tst_db2.test01.find({"_id":i})
for row in cur:
print 'select secoundary data: ',row["_id"],row["date"]
テスト2スクリプト:
#time.sleep(0.1)は、ループが他のテーブルにデータを挿入するように変更され、ループが大きいほどライブラリからのデータの再生が遅くなります.
for j in range(2,20):
tst_db.get_collection('test%s'%str(j).zfill(2)).insert({"_id":i,"date":datetime.datetime.now()})