1000件の一覧を1件ずつ引くと、往復が1001回になり、まとめて引く場合の223.0倍かかりました。
公式は汎用のリレーショナルデータベースではないと明言しています。用途を外すと、この差がそのまま出ます。
公式が汎用ではないと述べています。1件ずつ取り出す形に当てると、往復がそのまま効きます。
Trinoは、置き換えを狙った道具ではありません。公式はTrinoは汎用のリレーショナルデータベースではないと述べています。
では用途を外すと何が起きるのか。1件ずつ引く形で実際に数えて比べました。
1往復 0.8ms、1行を返す手間 0.002ms として計算する 一覧の件数を変えて、1件ずつ引く場合とまとめて引く場合を比べる 一覧の件数 1件ずつ（往復） 1件ずつ（時間） まとめて（往復） まとめて（時間） 比 10件 11回 8.8ms 2回 1.6ms 5.4倍 50件 51回 40.9ms 2回 1.7ms 24.1倍 200件 201回 161.2ms 2回 2.0ms 80.6倍 1000件 1001回 802.8ms 2回 3.6ms 223.0倍
1000件では往復が1001回になり、223.0倍の差がつきました。返す行の数は同じです。
差はすべて往復の回数から来ています。まとめて引けば、件数が増えても2回のままです。
一覧200件で固定し、1往復にかかる時間のほうを変える 1往復 1件ずつ（時間） まとめて（時間） 比 0.001ms 0.60ms 0.40ms 1.5倍 0.01ms 2.41ms 0.42ms 5.7倍 0.1ms 20.50ms 0.60ms 34.2倍 0.8ms 161.20ms 2.00ms 80.6倍 5ms 1005.40ms 10.40ms 96.7倍
往復が0.001msなら、差は1.5倍まで縮みます。同じ機械の中にある場合がこれにあたります。
Trinoは離れた置き場に問い合わせる形をとります。だから往復の重さがそのまま効きます。
件数が増えるほど、1件ずつの形は不利になる。
Trino is not a general-purpose relational database.原文Trino 公式ドキュメント「Trino use cases」 この内容の有効期限2027-02-18
集約のために作られています。効くのは使う項目を絞ることで、全項目を選ぶと利点が消えます。
Trinoは、集約のために作られています。公式はデータウェアハウジングと分析、すなわちデータの分析、大量のデータの集約、報告の作成を扱うために設計されたと述べています。
集約で効くのは、読む量を絞ることです。どれだけ変わるのか実際に読んで数えました。
表 200,000行・1行あたり 12項目（1項目 4バイト） 集計に使う項目の数を変えて、読む量を見る 使う項目 行ごとに持つ形 列ごとに持つ形 比 1個 9.2MB 0.8MB 12.0倍 2個 9.2MB 1.5MB 6.0倍 3個 9.2MB 2.3MB 4.0倍 6個 9.2MB 4.6MB 2.0倍 12個 9.2MB 9.2MB 1.0倍 1項目だけを合計する時間（同じ値になることを確認済み） 行ごとに持つ形 2.37ms 列ごとに持つ形 0.33ms（7.1倍速い）
1項目だけなら読む量は12分の1です。12項目すべてを使えば同じになります。
時間の差は7.1倍で、量の比の12.0倍より小さくなりました。この規模だと、間の項目もまとめて手元に載るためです。
つまり効き方は、置き場の形と問い合わせの書き方の組み合わせで決まります。全項目を選ぶ書き方は利点を打ち消します。
手元に載りきらない規模になると、量の比がそのまま時間に出ます。大きくなるほど、絞る効果が強くなります。
列ごとに持つ形そのものの効き方はParquetの記事で扱っていて、Trinoが読みに行く先もこの形が多くなります。
Trino was designed to handle data warehousing and analytics: data analysis, aggregating large amounts of data and producing reports.原文Trino 公式ドキュメント「Trino use cases」 この内容の有効期限2027-02-18
SQLが同じでも、後ろの仕組みが違います。索引をたどる形はもともと別の道具の役目です。
TrinoはSQLを理解しますが、それだけです。公式はTrinoがSQLを理解するという事実を、標準的なデータベースの機能を備えていることと取り違えてはならないと述べています。
違いが出るのは、1人ぶんを引くような問い合わせです。実際に両方を動かして比べました。
注文の表 200,000行・顧客 20,000人 ある顧客の注文をすべて取り出す問い合わせを 2000回 やり方 1回あたり見に行った行 合計の時間 1回あたりの時間 全部の行を見る 200000.0行 257ms 0.129ms 索引をたどる 10.0行 2ms 0.001ms
見に行った行は19,951倍、時間は137倍の差でした。SQLの見た目は同じです。
この索引をたどる形は、取引を扱う道具の得意分野です。公式も、そのための設計ではないと述べています。
報告を作る問い合わせと、画面から1件を引く問い合わせを同じ場所に投げると、後者だけが極端に遅くなります。
だから分けることになります。1件ずつの取り出しはPostgreSQLの記事で扱った形の道具に任せ、集約をTrinoに寄せます。
3つの計測はいずれも手元で書いた模型で、実際のTrinoを動かしたものではありません。往復0.8msや1行0.002msは置いた値です。索引の比較も、索引を作る手間と行を足すたびに直す手間を含めていません。列ごとに持つ形の時間はこの規模での実測で、規模が変われば比も変わります。ここで見せているのは、SQLが同じでも往復の回数と読む量で結果が桁違いに変わるという点と、用途を外すとその差がそのまま出るという点の2つです。
Do not mistake the fact that Trino understands SQL with it providing the features of a standard database.原文Trino 公式ドキュメント「Trino use cases」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る