この記事の途中に、以下の記事の引用を含んでいます。
Why Ave.ai Chose VeloDB over ClickHouse & Snowflake for Web3 Analytics
驚異的なデータ爆発時代に直面 ― Web3時代の分析基盤構築
本記事は、オーストラリア発の急成長Web3・DeFi取引プラットフォームAve.aiが、1,000万人以上のユーザ、50万以上のデイリーアクティブユーザを相手に、オンチェーンデータ分析基盤を刷新した技術的決断とその裏側に迫ります。
彼らは従来のPostgreSQLベースの分析システムから脱却し、複数候補を徹底評価した上で、Apache Dorisを基盤としたVeloDBへと舵を切りました。
その理由、背景、具体的な技術実装、その知見は、多くの現代的な大規模トランザクション・データ分析システムやWeb3領域に携わる技術者にとって貴重な指針となり得ます。
「なぜPostgreSQLではダメだったのか？」— 巨大Web3取引・分析の三重苦
この記事で最も重要な主張は、「従来型のPostgreSQL分析基盤では、1,000万人規模のWeb3オンチェーン取引データをリアルタイムに分析・可視化するユースケースには到底耐えられなかった」という点。
特に次のような三重苦を強調しています：
“Ave.ai’s PostgreSQL-based system struggled with high-concurrency queries, real-time analytics, and elastic scalability.”
Why Ave.ai Chose VeloDB over ClickHouse & Snowflake for Web3 Analytics
つまり、高並列クエリ処理、リアルタイム分析、弾力的なスケーラビリティ――この3つの条件を満たさなければ、現代の有力Web3アプリは成り立たないという現実があります。
加えて、扱うデータ規模も桁違い。
190以上ものブロックチェーン、500以上のDEXから流入する毎日数十億のトランザクションやウォレット行動の蓄積は、既存のRDBMSの設計思想を凌駕します。
「VeloDBは何が違う？」— Web3特有要件への徹底対応
1. リアルタイム性能への圧倒的こだわり
Ave.aiが新基盤に求めた要件は「ほぼリアルタイム（5秒未満）」で、「QPS 1,000超え」の詳細分析を「99パーセンタイル1秒未満」で返せることでした。
この要求水準は、一般的なBI用途はもちろん、金融分野やWeb3の複雑・高速なオンチェーン取引監視には不可欠。
ここで、VeloDBでは記録的な書き込み性能と、徹底したチューニングを施すことで、次のような成果を得たと主張します：
“With VeloDB’s write optimizations, the system now handles high-throughput ingestion from major blockchains, sustaining roughly 5,000 records per second. End-to-end data latency consistently stays under 5 seconds.”
“Ave.ai can now process close to 1,000 QPS with P99 latency within 1 second, even during prolonged peak periods.”
Why Ave.ai Chose VeloDB over ClickHouse & Snowflake for Web3 Analytics
この「エンド・ツー・エンドで5秒未満」「ピーク時にQPSが1,000でもP99が1秒以内」は、卓越したリアルタイム性の証明です。
2. オープン・SQL互換・脱ベンダーロックイン
2000年代以降、多くのデータウェアハウス製品はプロプライエタリやISC/クラウドロックインに苦しみがちでした。
Ave.aiはその反省を踏まえ、SQL互換性（既存ワークフローとツール資産をゼロから捨てない）と、オープン/クラウドニュートラル設計（どこでも自由にスケーラブルに運用可能）を重視。
ベンダーロックインを最大限回避できる点も選択理由の大きなファクターです。
3. コスト効率劇的向上—ストレージ・コンピュート分離
データウェアハウス運用あるあるですが、“ピーク需要想定の過剰プロビジョニング”は、運用コストを爆発的に押し上げます。
しかしVeloDBは、“ストレージとコンピュート分離（storage-compute separation）”モデルにより、トラフィック急増時も無駄なく自動スケール、全体OPEXを50%削減したと述べています。
4. クエリ・インデックス最適化事例
Web3・金融分野独自の重たい「TopNクエリ」や高精度な小数演算（最大60桁！）、頻繁な複合条件のフィルタクエリへの高速応答には、テーブル設計・パーティション設計・セカンダリインデックス最適化が欠かせません。
製品固有の例ですが、Ave.aiのメインイベントテーブル（10TB超）は、アカウントアドレスによるパーティション/バケッティング、動的パーティション（日単位）の組み合わせ、Inverted Index（範囲/複合条件向き）の選択などを実践。
その結果、「スキャン対象データを劇的圧縮し、ミリ秒級レスポンスを可能にした」とのこと。
なぜClickHouseやSnowflakeでなくVeloDBだったのか？— 意外な点も
記事の比較表によると、ClickHouseは高並列性能が弱く、TiDBは分析計算性能で及ばなかったとされています。
SnowflakeやHBase等他候補も考慮されたものの、結局Web3特有の「リアルタイム・スケール・オープン・SQL互換」という全要件にバランス良く応えたのがVeloDBだった、と結論づけられています。
筆者としても、商用クラウドDWH（Snowflake/BigQuery/Redshiftなど）は運用安定度やマネージドサービスとしての魅力は高い一方で、
・高頻度/細粒度/低レイテンシの複雑分析を連続的に捌く
・オンプレ/複数クラウドやローカル配備で将来の構成柔軟性を持つ
・ハイブリッドな可用性や異常検知、カスタムインデックスチューニングなどの自由度
こういった分野では、「フルクラウド前提アーキテクチャ」や「課金構造の稼働予測難」に悩まされる現実があります。
ClickHouseに関しては、列指向データベースとしてグローバル金融や広告分析での実績も豊富ですが、高並列性（特に大量ユーザから同時に分析詳細を要求されるWeb3のようなケース）では、特定設定や運用ノウハウなしではパフォーマンス限界が露見しやすい印象もあります。
実サービスでの活用例—ウォレット監視・マネロン検知・KOLトラッキング
Ave.aiはVeloDBを使って、まさにWeb3特有の高度な分析ワークロードを日常的に実施しています。
たとえば記事は、以下のような多彩な分析シナリオを紹介：
– 「スナイパー」分析：トークン発行から3ブロック以内に買ったウォレット特定
– フロントランニング/インサイダー疑惑ウォレットの即時発見
– フィッシング・詐欺アカウントの兆候検知
– インフルエンサー（Twitter等5,000人超フォロワー持ち）による取引パターン特定
– 「スマートマネー」や「ホエール」パターン（億単位取引や連続利益）の追跡
従来の分析DWHやRDBでこれらをリアルタイム処理すると、たった1つの複雑クエリで何百ギガのデータスキャンやI/Oボトルネックが即発生してしまうことも多い現実があります。
Web3ウォレットやDEX環境は非常にダイナミックで、しかも疑わしい挙動や新種の攻撃も常に更新され続けているため、データ基盤は「バッチ処理」的発想ではなく、「イベント駆動・常時監視可・低レイテンシ応答」が求められます。
コード・テーブル設計から学ぶ最適化Tips
記事にはDDL例や具体的クエリ例も豊富です。
主キー設計やパーティション/バケッティング、セカンダリインデックス設計の細やかなノウハウまで紹介。
範囲クエリ・複合条件フィルタ・TopN実装など、ミッションクリティカルな分析案件での参考ポイントが多々盛り込まれています。
例えば、10TB級トレードテーブルの設計では—
sql
CREATE TABLE `blockchain_l1_events` (
-- 省略
) ENGINE = OLAP
UNIQUE KEY(`account_address`, `block_number`, `event_id`, `date`)
PARTITION BY RANGE(`date`) (
PARTITION p20241004 VALUES [('2024-10-04'), ('2024-10-05'))
)
DISTRIBUTED BY HASH(`account_address`) BUCKETS 64
PROPERTIES (
"dynamic_partition.enable" = "true",
"dynamic_partition.time_unit" = "DAY"
);
問い合わせに頻繁に指定されるカラムを主キーに配列し、パーティション・バケッティングでデータ分割。
さらに下記のような複数のINVERTEDインデックスで高頻度なWHERE句に対応など、”運用される現場”発の生きた知恵が多く、汎用DB設計の参考にも有用です。
Web3・DeFi分野こそ「現場主導のアーキテクチャ選定」が重要
この記事を通して感じる最大の示唆は、「単なる知名度やベンチマーク値だけでなく、自社の本質的なビジネス要件と運用現場のニーズに合わせて、地道なPoCやクエリパターン解析、運用コスト分析、チューニングの地道なサイクルを惜しまない」ことの重要性です。
これまで日本企業では、「まずDBMSやDWHは大手か世界標準から」「クラウドならとりあえずマネージドサービス」のような選択が主流でした。
しかし、特にWeb3/金融/ゲーム/アドテクのような複雑・多様なデータ基盤では、「自社の現実に合うか」を何度でも疑う姿勢が成果を大きく左右します。
加えて、SQL互換性やインデックス設計の柔軟性、コスト構造の見直し（ストレージ/コンピュート分離等）、インフラ担当・開発者両者からの現場の声を十分吸い上げた上で、競合製品との徹底比較を実施すること。
このプロセスこそが、「成長し続ける基盤」「ベンダーロックイン回避」「将来のデータ爆発にも備えた運用KPI達成」への最短ルートとも言えるでしょう。
まとめ：「最強DWH」ではない、”いまの自社”に最適化された進化する分析基盤を追求せよ
Ave.aiの移行事例は、「特定製品が万能」という話ではありません。
むしろ世界観は、「現在進行形で成長し変化する自社ニーズ・運用体制と照らし、どのフェーズでどのプロダクト・アーキテクチャが『バランス良く最大価値を生むか』を考え続ける」こと――に尽きるでしょう。
Web3だけでなく、リアルタイム性・並列性・コスト・柔軟性・運用スキルの多様な要件がシビアに交錯する高度な分析基盤選びでは、
単に「業界標準だから」や「とりあえずクラウドで」ではなく、
具体的な数値基準・運用実績・地道な最適化のトレードオフと、”現場でのフィードバックループ”を大切にするマインドが不可欠です。
Ave.aiのように、目先の導入労力やPoCコストを惜しまず「長期視点の最適解」を根気よく追い求める姿勢は、あらゆる規模・分野の分析基盤刷新プロジェクトに勇気と知見を与えてくれるでしょう。
categories:[technology]
コメント