Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
0
Help us understand the problem. What is going on with this article?
@kurimoto

S3のKey命名について

S3のバケットに色々なデータを置いていくと、ちょいちょい命名に悩むことがあります。
本記事は命名規則、というほど大袈裟なものではありませんが、「こうしたら楽だった」という経験則についてのお話です。

REST的な命名は意外と困る

RESTに慣れていると、S3もそれに合わせて以下のような命名にしたくなります。

dogs/{dogId}/age.json
dogs/{dogId}/name.json
dogs/{dogId}/weight.json

idと、その属性を保存したいようなケースですね。
この場合、特定のidに対する属性は簡単に取得することができます。
ListObjectsV2のprefixで、dogs/{dogId}/を指定すればすぐですね。

ただ、開発を続けていると「全てのdogsのageを知りたい」ってケースも当然のように出てきて、そうなると対象のdogIdを全て知っている必要があり、ちょっと面倒なことになります。

ではどうしようか

シンプルな話ですけども、属性をできる限り前に記載し、一意とする識別子は後ろにするを基本にすると便利です。

dogs/ages/{dogId}.json
dogs/names/{dogId}.json
dogs/weights/{dogId}.json

って感じですね。
この書き方であれば、「全てのdogsのageを知りたい」というケースはdogs/ages/のprefix指定で取得可能です。

とはいえ、当然の如く

「おいおい、それじゃ、特定のidに対する全ての属性を取得する」ってケースに対応できなくなるがな」

って話になりますが、属性は基本的にそんな大量にない&あらかじめ知っているはず、という前提にて、「全ての属性について知る」と「全てのidについて知る」のどちらが楽か、というと、やはり前者になるかと思うわけです。

例外的なケースは当然あろうとは思いますが、何か新しいファイルを置く必要が出てきた際、毎回「こうかなぁ、、、?」って悩まずとも、この基本ルールを適用すると話がサクサク進んで良いかなと思っております。

一意とする識別子が複数ある時はどうすんの?

例えばこんなケースもありますよね。

breeders/{breederId}/dogs/{dogId}/age.json

これも悩ましい話ではあるのですが、属性をできる限り前に記載し、一意とする識別子は後ろにするに従うとこうなります。

dogs/ages/breeder.{breederId}/dog.{dogId}.json

わからなくはないです。でも、なんか、ちょっと気持ち悪い、、
でも、いつか「特定のbreederIdに所属する全てのdogのageを知りたい」って要件が出てきた時、これは結構助かります。

じゃあさらに一意となる値が複数出てきたらどうするの?

仰ることはわかります。こういうことですよね。

organizations/{organizationId}/breeders/{breederId}/dogs/{dogId}/age.jsonn

OK、わかったわかった、こうだろう?

dogs/ages/organization.{organizationId}/breeder.{breederId}/dog.{dogId}.json

問題は解決しました。これなら「特定のorganizationに所属するdogの全てのage」も、「特定のorganizationに所属する特定のbreederが育てたdogの全てのage」も取得できます。

しかしここでまた新しい要件が。
「breederは複数のorganizationに所属していることがある。特定のbreederが育てたdogの属性を全部知りたいんだ」

え?organizationIdは全部わかるんですよね。え?取得するのにめちゃくちゃ負荷がかかるから使いたくない? 無茶言うな

無茶なのは、、、?

全く、どんどん要件変えやがって。困ったもんだ。無茶ばっかりだ、、

という気もしますが、まぁ、ぶっちゃけるとそんな複雑な検索要件が出てくるものをS3で扱おうって前提が間違っていた、という可能性も大いにあります。DynamoDBを使え

そうです、本記事は、安いからついS3をDynamoDBの代替にしたくなる貧乏性が産んだ経験則だったのです、、、!

という締まらない結論にて締めたいと思います。
ここまで読んでいただいて、ありがとうございました。

でも、要件が固まってるタイプのデータなら、S3をDBがわりにするのって結構楽ちんなんですよね(小声)

0
Help us understand the problem. What is going on with this article?
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
kurimoto
トレラン大好きエンジニア。
runners
スポーツで世界を良くしたいエンジニアチーム。応援navi、.finisher、run&といった製品開発をしています!

Comments

No comments
Sign up for free and join this conversation.
Sign Up
If you already have a Qiita account Login
0
Help us understand the problem. What is going on with this article?