実体を1つ直すと、平均では40.0件の文書を書き直すことになります。
ところがいちばん使われる実体では8,688件でした。平均を見ていると気づけません。
関係を別に置けます。文書の中に持つ形と比べると、置く量と書き直す件数が入れ替わります。
Supabaseは、NoSQLの置き場を使いません。公式はとりわけ目立つのは、NoSQLの置き場ではなくPostgresを使っていることであると述べています。
関係を別に置けるかどうかで何が変わるのか。実際に数えて比べました。
文書 200,000件・共有される実体 5,000件 文書は 340バイト、実体は 220バイト。1実体あたり平均 40.0件の文書から指される 持ち方 置く量 1件を読む往復 実体を1つ直したときに書き直す文書 文書の中に持つ 106.8MB 1回 40.0件 別に置いて指す 65.9MB 2回 1件
文書の中に持てば、1件を読む往復は1回です。そのかわり実体を直すと40.0件を書き直します。
別に置けば書き直しは1件ですが、読む往復が2回になります。置く量も1.62倍の差がつきました。
よく出てくる実体を直した場合、書き直す文書の数 順位 書き直す文書 全体に対する割合 最も多い 8,688件 4.34% 10番目 1,387件 0.69% 100番目 218件 0.11% 真ん中 17件 0.01%
平均は40.0件ですが、いちばん使われる実体は8,688件です。217倍の開きがあります。
真ん中の実体なら17件です。平均は、この2つのどちらにも当てはまりません。
関係を別に置けば、この偏りは効きません。1件を直すだけで済みます。同じ判断はMongoDBの記事でも扱いました。
平均を見ていると、上位の書き直しを見落とす。
Most notably, we use Postgres rather than a NoSQL store.原文Supabase 公式ドキュメント「Architecture」 この内容の有効期限2027-02-18
中心にあるのは1つの置き場です。読みを速くする索引は、そのまま書き込みを重くします。
Supabaseの中心には、1つの置き場があります。公式はPostgresはSupabaseの中心であると述べています。
中心が1つなので、読みのための工夫が書き込みに響きます。実際に足して測りました。
行を 200,000件 足す。索引の数を変えて、かかる時間を見る 索引は「値ごとに行番号を並べたもの」として作っている 索引の数 足すのにかかった時間 1件あたり 索引なしとの比 0個 3ms 0.01µs 1.0倍 1個 13ms 0.06µs 4.4倍 2個 21ms 0.10µs 7.0倍 4個 43ms 0.21µs 14.4倍 8個 85ms 0.42µs 28.7倍
索引を1個足しただけで4.4倍です。8個では28.7倍になりました。
行を足すたびに、索引の数だけ書き足すことになるからです。読みの都合で足した索引が、書き込みに乗ります。
索引をたどれば読みは大きく速くなります。だから索引を消すのが正解というわけではありません。
見るべきは、その索引を使う問い合わせが実際に走っているかどうかです。使われていない索引は、書き込みを重くするだけになります。
自動で作られる仕組みでは、この確認が抜けやすくなります。索引設計の記事で扱った手順が要ります。
表がそのまま入口になります。同じ行に集まる処理があると、人数を増やしても伸びません。
Supabaseでは、表がそのまま外向きの入口になります。公式はあなたのPostgresのデータベースを、そのままRESTの形の入口に変える、独立した給仕役であると述べています。
入口が増えると、同じ行に集まる処理が出てきます。どれだけ効くのか実際に動かして数えました。
処理 4000件。1件 2ms。同じ行を取り合う分は順番待ちになる 取り合う割合を変えて、担当を増やしたときの短縮を見る 取り合う割合 1人 2人 4人 8人 16人 16人での短縮 0% 8.00秒 4.00秒 2.00秒 1.00秒 0.50秒 16.0倍 5% 8.00秒 4.20秒 2.30秒 1.35秒 0.88秒 9.1倍 20% 8.00秒 4.80秒 3.20秒 2.40秒 2.00秒 4.0倍 50% 8.00秒 6.00秒 5.00秒 4.50秒 4.25秒 1.9倍
取り合いがなければ16人で16.0倍です。理想どおりに縮みます。
5%取り合うだけで9.1倍まで落ちます。50%なら1.9倍で、人数を増やしてもほとんど効きません。
取り合いが起きるのは、在庫の数や集計の値など、みんなが同じ行を直す場面です。
入口を増やしても、この部分は伸びません。行を分ける設計にするか、集計を後で足す形にすることになります。
3つの計測はいずれも手元で書いた模型で、実際のSupabaseやPostgresを動かしたものではありません。指される数の偏りは式で作ったもので、実際の分布とは違います。索引の書き込みは「値ごとに行番号を並べる」という簡単な形で作っており、実際の実装より軽くなっています。取り合う分は同時に1人しか進めないものとして計算しました。ここで見せているのは、平均だけを見ると上位の書き直しを見落とすという点と、わずかな取り合いで人数を増やす効果が半分近くまで落ちるという点の2つです。
A standalone web server that turns your Postgres database directly into a RESTful API.原文Supabase 公式ドキュメント「Architecture」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る