こう
- 「キーバリュー、
RDB、 強い 一貫性が 要る 状態、 ファイルの 置き場を、 どう 使い 分けますか」 - 「設定の
値、 注文の 記録、 チャットの 部屋、 利用者が 上げた 画像は、 それぞれどこに 置きますか」 - 「全部 1 つの RDB に
入れては だめですか」 (裏から聞く形)
面接官が
- 置き場ごとの
得意と 苦手を、 データの 読み方と 書き方で 説明できるか - 「更新が
すぐ 全部に 見えるか」という 一貫性の 違いを 分かっているか - 料金の
体系や 運用の 手間まで 含めて、 捨てた物を言えるか
短い答え
- 読み方と、
どれだけ新しい 値が 要るかで 分けます。 キーで 引くだけで 少し 古くても よい物は キーバリュー、 条件で 探したり 結合 したりする 物は RDB、 同時に 書き換えて 食い 違ってはいけない 状態は 1 か所で 順に 処理する 仕組み、 ファイルや 画像は オブジェクトストレージです。 - 置き場ごとに
速さ、 一貫性、 問い 合わせの しやすさ、 料金の かかり方が 違い、 全部に 強い物は 無いからです。 - たとえば
設定の 値は キーバリュー、 注文は RDB、 在庫の 引き当ては 順に 処理する 仕組み、 画像は オブジェクトストレージに 置きます。 そのぶん 置き場が 増え、 運用の 手間も 増えます。
少し
4 つの
- キーバリュー鍵 (キー) を
渡すと 値が 返る、 いちばん単純な 置き場です。 読むのが 速く、 たくさん 読まれる 設定や キャッシュに 向きます。 条件で 探す、 表を 結合する、といった 問い 合わせは 苦手です。 AWS なら DynamoDB、 Google Cloud なら Firestore、 Cloudflare なら KV が 近い 位置にあります - RDB 表と SQL で、
条件での 検索、 集計、 結合、 トランザクション (まとめて 成功か 失敗に する 仕組み) が できます。 注文や 会員のように、 関係の ある データを 正しく 持つのに 向きます。 AWS の RDS、 Google Cloud の Cloud SQL、 Cloudflare の D1 などがあります - 強い
一貫性が要る状態チャットの 部屋、 在庫の 残り、 回数制限の 数のように、 同時に 何人も 書き換えて、 それでも 食い 違ってはいけない値です。 1 か所で 順に 処理する 仕組みに 集めるか、 RDB の トランザクションと ロック (同時の 書き換えを 待たせる 仕組み) で 守ります。 Cloudflare では Durable Objects が この 役で、 AWS や Google Cloud では RDB や DynamoDB の 条件付きの 書き込みで 同じ役を 作る ことが多いです - ファイルの置き場画像、
動画、 書き出した ファイルは、 オブジェクトストレージ (ファイルを キーで 出し入れする 置き場) に 置きます。 DB には 置き場の キーだけを 持ちます。 AWS の S3、 Google Cloud の Cloud Storage、 Cloudflare の R2 などです
一貫性の
置き場に
だから
料金の
料金の
置き場を
話すときは、
よく
- 在庫や
残高を 結果 整合の 置き場に入れる 反映が 遅れる 間に、 同じ物を 2 回売る、 残高より 多く 使う、が起きます - 画像を DB の
列に そのまま入れる DB が 重くなり、 バックアップも 膨らみます。 ファイルは オブジェクトストレージに 置き、 DB には キーだけを持ちます - 「転送料は無料」とだけ言う
外へ 出す転送の 料金が かからない 体系でも、 保存量と 操作の 回数には 料金が かかります。 体系として 説明します
深掘りの問い
- 「キーバリューの
値が 古いまま 残ったら、 どう 困りますか」 設定なら 少し 遅れて 効くだけですが、 権限の 取り消しが 遅れると 危ない、のように、 データごとに 困り方が 違う、と答えます - 「在庫の
引き当てを RDB だけで 作るなら」 トランザクションの 中で 残りを 確かめて 減らし、 同時の 書き換えは ロックや 条件付きの 更新で 防ぐ、と答えます - 「利用者が
上げた 画像を 安全に 配るには」置き場は 外から 直接読めないようにし、 期限付きの URL を 発行する、と答えます