はじめに
先日、PingCAPブログにてHTAPワークロードのベンチマーク、Web3 Benchについてのブログが掲載されました。
従来のデータベースのベンチマークは、TPC-CやTPC-H/YBCSのように、OLTPまたはOLAPいずれかのワークロードのベンチマークだったのですが、このベンチマークは両方のワークロードが同時に発生するHTAPワークロードを実施して計測している点が異なるとされています。
このようなワークロードが顕著に観測されるのがWeb3（と書いてありますが、ブロックチェーンデータのリアルタイム分析）です。ブロックの生成に応じたOLTPワークロードと、過去データも含めたOLAPワークロードの両方が発生します。本ベンチマークでは架空のEthereumデータをベースにしています。
発表内容と下記のリポジトリから、実際にどのようなベンチマークなのか中身を見ていきます。
データモデル
データモデルはすごくシンプルで、4つのテーブルしかありません。
BigQueryのEthereum ETLのスキーマをシンプルにしたもののようです。
検索ワークロード
検索については次の4種類のクエリカテゴリが定義されています。
- T(0.1秒以内)
- O(1秒以内)
- O(10秒以内)
- A(制限なし)
クエリ例を少し見ていきます。まず始めにTクエリ
SELECT to_address, from_address
FROM transactions
WHERE hash = ?
これはハッシュ値からトランザクション、誰と誰の取引だったかを探すものです。Etherscan(https://etherscan.io/) で Txn Hashで検索することに該当するものと思われます。
次に
-- R22
SELECT count(*)
FROM token_transfer
WHERE token_address = ?
あるアドレスのトークン取引件数をカウントするものです。こちらもEtherscanでも検索できます。
Aクエリを見てみます。
-- R34
SELECT sum(value) as totalamount,
count(value) as transactioncount,
from_address as fromaddress
FROM transactions
GROUP BY from_address
ORDER BY sum(value) DESC
LIMIT 10
取引額の大きい送信元アドレスTop10です。
更新ワークロード
更新ワークロードは単一のINSERTだけではなく、バッチINSERTやJOIN UPDATEも行っています。
-- W2
INSERT INTO transactions VALUES
(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?),
(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?),
(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?),
...
(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) /* 99回繰り返し */
-- W52
UPDATE token_transfers
SET value = value + 1
WHERE from_address IN (
SELECT to_address
FROM token_transfers
)
まとめ
ざっとみた感じでは、シンプルなデータモデル、かつ大量のレコードに対する、性能要求の異なるクエリの実施パフォーマンスを見るベンチマークとなっています。検索はどれも基本的なものですが、レコード数が多くなるとそれなりに時間がかかるものを選んでいるようです。
実際にTiDBやMySQLに対して動かしてみたら別途ブログに書いていこうかなと思います。