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

はじめに

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

やったこと

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以上のメモリを消費しており、かなりヒヤヒヤしました。

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