🕰️

AWS DocumentDBのInsert性能ベンチマーク

2022/02/14に公開約2,800字

はじめに

本記事の正確性等は一切保証できませんが、理解の誤りや、誤植・手順漏れ等、コメント・ご指摘に関しては何でも頂ければ幸いです。マサカリは優しく投げてください。

やったこと

AWSのDocumentDBに関して、膨大なデータ数を格納する上で要する時間について確認しました。
かなり雑な確認方法ではありますが、データサイズ対処理性能に対して、おおよその指標として、メモ代わりに記載します。

かなりのDB初学者の記載なので、必要な情報の欠損や、考慮漏れ、アドバイス等あればコメントいただければと思います。

結論

Document Size平均より,Document数のほうがInsert処理の負荷に与える影響として支配的っぽい.十分速いは速いが,AWS DocumentDBは書き込み命令数やIO数に応じて課金されるので,お金がかかるほうが辛い.

確認方法

環境

AWSに以下のInstanceを立てて、測定を行っています。

# DB
    db.r5.4xlarge
        L3 Mem: 64G, vCPU: 16

# CLIENT
    r5.16xlarge
        L3 Mem: 512G, vCPU: 64

手順

予め以下のコードによって、5 \times 10^4個の疑似ドキュメントを作成し、並列処理でDocumentDBに投入しています。
測定する時間としては、生成後のINSERT処理開始から、終了までを測定しており、疑似Document生成の時間は含みません。

DocumentDBのAPIには、pythonのライブラリのpymongo, insert_many()メソッドを利用しています。

collection – Collection level operations
https://api.mongodb.com/python/current/api/pymongo/collection.html

def gen_dummy(num, length):
    fake = Faker()
    docs = [
        fake.pydict(length, value_types="str") for i in range(num)
    ]
    return docs

1つのドキュメントサイズとしては、以下3パターンを用意しています。

pattern size [kB] key-value pairs [-]
MIN 0.038 1
MID 0.32 10
BIG 3.4 100

結果

以下に、(ドキュメントサイズ, 並列プロセス数)ごとの, 単位時間あたりの処理性能を記載しました。

docs/ms (単位時間あたりの処理ドキュメント数)に関しては、(並列プロセス数)\times 50000の値を用いています。
size/s (単位時間あたりの処理サイズ)に関しては、投入時に用いるドキュメントリストオブジェクトのサイズにより計算しています。

時間がかかるので分散は取っていません…、おおよその値ということで承知ください。

Process Num Doc Size Doc Num [\times 10^6] Wall Time[sec] docs/msec size/sec
single MIN 0.500 13.9 36.0 1.44
single MID 0.500 20.7 24.2 7.83
single BIG 0.500 95.9 5.23 17.9
2 proc MIN 1.00 110 9.09 30.9
4 proc MID 2.00 143 14.0 47.6
8 proc BIG 4.00 171 23.4 79.5
16 proc BIG 8.00 277 28.9 98.2
64 proc BIG 32.0 861 37.2 126
16 proc BIG 8.00 60.0 133 43.2


Fig.1. ドキュメントサイズと処理性能; ドキュメントサイズが大きくなるほど、単位時間あたりの処理ドキュメント数は減っていく。ドキュメントサイズが100倍になっても処理性能は1/10程度なので、ある程度までであればドキュメントサイズは大きいほうがサイズ効率が良さそう。


Fig.2. プロセス数と処理性能; プロセス数を増やすに伴って、10procまではある程度線形に増加していくものの、16, 64procとなってくると頭打ちされている。
おそらく、DocumentDB側のドキュメント更新に伴うIndex等の処理?競合解決によるものか。調査中。

考察

処理の時間に寄与するパラメータとしては、ドキュメント数とドキュメントサイズの両方が効いているようです。当たり前といえば当たり前ですが。

ドキュメントサイズが大きくなるほど、単位時間あたりの処理ドキュメント数は減っていく。ドキュメントサイズが100倍になっても処理性能は1/10程度なので、ある程度までであればドキュメントサイズは大きいほうがサイズ効率が良さそう。

プロセス数を増やすに伴って、10procまではある程度線形に増加していくものの、16, 64procとなってくると頭打ちされています。
おそらく、DocumentDB側のドキュメント更新に伴うIndex等の処理?競合解決によるものか。調査中。

また、想定以上にCLIENT側のメモリ負荷が高いです。
64 procで3,200,000個のドキュメントを投げた場合, 861secの間, 400GByte以上のメモリを消費しており、かなりヒヤヒヤしました。

使用しているライブラリの問題や、実装の問題もありますが、投入時に必要な容量は多めに見積もったほうが安心安全かもしれません。

Discussion

ログインするとコメントできます