静的ストレージの料金比較

public alphaの間はまだ無料

費用

使用状況

クエリ発行してないならゼロ

プランの制限を越えた分のストレージ

table:d1

Workers Free Workers Paid

Rows read 5 million / day First 25 billion / month included + $0.001 / million rows

Rows written 100,000 / day First 50 million / month included + $1.00 / million rows

Storage (per GB stored) 1GB (total) First 5GB included + $0.75 / GB-mo

storageは一番高い、それはそうだろう

​DOの上に実装してたはず

readが安い

writeは同程度

websocket的な通信が無いからだろうか

table:kv

Free plan Paid plan

Read requests 100,000 / day 10 million/month, + $0.50/million

Write requests 1,000 / day 1 million/month, + $5.00/million

Delete requests 1,000 / day 1 million/month, + $5.00/million

List requests 1,000 / day 1 million/month, + $5.00/million

Stored data 1 GB 1 GB, + $0.50/ GB-month

小さめの値でreadが多いものに使うと良い

KVの名前の通り

静的ストレージじゃなくてDBだと

まだわからんがegressは無料

durable object上で実装されてるっぽいこと

read replicaをエッジに分散しそうなこと

らへんを考えると、最低限DOよりかは高いだろう

操作ごとに分ける

store

容量 * 時間

R2 < S3 <<10x<< DO <<2x<< KV < D1

0.015 0.5　($/GB-month)

table:store

R2 S3 DO KV D1

0.015 0.023 1 GB, + 0.2 0.5 First 5GB included + $0.75 / GB-mo ($/GB-month)

s3系かそうでないかで、大雑把に10倍違う

D1はそもそもDBなので単なるストレージサービスとは違うし、高いのは当然

read

リクエスト単位

D1 << DO < R2 < S3 < KV

0.001 0.2 0.5 ($/million)

table:read

D1 DO R2 S3 KV

First 25 billion / month included + 1 million, +

$0.001 / million rows 0.2 0.36 0.4 0.5 ($/million)

D1は安い

実はDOが安い

write

リクエスト単位

D1=DO <<4.5x<< R2<KV=S3

1 5 ($/million)

table:write

D1 DO R2 KV S3

First 50 million / month included + 1 million, +

$1.00 / million rows 1.00 4.5 5.00 5.00 ($/million)

意外とDOとの差が大きい？

考察

Cloudflareは無料枠が結構あるので、初手はそんなに気にする必要はない

データが線形以上に増えて（実装したいサービスのロジックに従って増えてくとか）無料枠を超えるものを想定するときに必要

読み込み

D1が安い

DOも他と比べたら安いが、R2とは近い

そんなに変わらん0.2:0.36

書き込み

D1,DOが安い

短期~中期で書きこみメインのものはこれらに任せると良い?

そもそも書きこむのって要件によっては強整合が必要だし

なので、そのままid、インスタンス単位で実装を進めて

利用頻度が減って、見るタイミングは少ないけど長期保存はする必要があるデータは、R2やS3に移行、が良さそう？

S3以外の、S3互換なストレージ探すのも良い

KV向き

利用者が多い

速度を出したい

グローバルにkey valueの対応が同一

改めて特徴を把握する

グローバルなkey-valueストアなキャッシュ

データセンターに置きながら、エッジ上にキャッシュする

なので、storeやreadが高いのは納得

インスタンスは単一のデータセンターに存在するので、read, writeが安いのは納得できる

R2やS3

read,writeは上記らの真ん中あたりに位置する。

storeに関して、ここに優位性がある

あと、そもそも重いファイルはR2とかじゃないととか

KVやDOの１レコードに入り切る容量とか

S3にあるのか知らないけど、R2に ranged readがあるのはちょっと気になる

なんか面白い使い方できないかな？

前から読んで全体のindexというか構造がわかるようなタイプのデータなら、なんか良い感じに何かができそう？

あ、そうか、DBのインデックスと似たような仕組みをファイル前方に置いておけば、早いアクセスができるか？

read writeはリクエスト単位だからあんま関係ないか

そのコンセプト自体は、インデックスを別のストレージに持っておけば良い

ただ、指定のデータだけが欲しい、という用途にはまあ便利か

特に面白くなく、素直なranged readの使い方ではある