BlackBeltでDynamoDBを勉強してみた

こんばんわ、hisayukiです。
新年あけてそうそう夫婦ともにインフルエンザにかかりました・・・💦
とりあえず、すこし落ち着き明日からお仕事に戻ります(；´∀｀)

さて、Serverlessの仕組みを取り入れていこうと思うと避けて通れないのがNoSQL系DB。
AWSではDynamoDBですね。

今回のre:Inventでも更に使いやすくなったとのことで、再度勉強することにしました。

RDBとの違いで思うこと

いつも思うのですが、長年RDBでやっていると

『RDBのこの方法をNoSQLだとどうやるの？』

ってところで僕は結構躓くわけですが、もう全くの別物だと思って勉強したほうがよいですね。
DBの機能レベルでどう置き換える？という考え方だと、RDBのやり方をNoSQLでやろうとしちゃうので難しくなりがちな気がします。

『アプリケーションの機能をNoSQLでどう実装するか』

こっちで考えたほうがとっつきやすいです。
RDBでの実装経験は一旦ポイして、一からやり直すくらいの感覚のが楽です。

今回初めてBlack Belt Online Seminarを見てみました❗
DynamoDBの使い方とかネットで調べれば大量に出てきますが、本家のセミナー見たことなかったので(；´∀｀)

いやー、非常にわかりやすかったｗ

はじめてAWSのWebnarを見たんですが、DynamoDBまだ使ったこと無い人、またはまだ経験浅い人にはすごいオススメです。

個人的には過去のDynamoDB教材の中で一番よかったです。
とくにRDSと比較しちゃいがちな人には丁度いいと思います。

というわけで、今日は基礎知識だけおさらいしてみます。

TableはRDBのでのTableと同じで、ItemがRDBでのレコード、AttributeはRDBでのカラムとなります。
RDBとの違いはItem内には１つ以上のAttributeが必要だが、Item間でのAttribute数は同一でなくても良い。

PartitionKeyは順序指定をしないハッシュキーでItem内に必須。
単体でプライマリーキーにも出来る。

SortKeyは複数のデータ順序を保証するためのキー。
PartitionKeyとSortKeyを合わせてプライマリーキーにも出来るため、PartitionKeyに同一値が入っていても、SortKeyを変えて別のItemにすることも可能

検索対象TableのSortKey以外のAttributeで検索する際に、PartitionKeyと検索AttributeをSortKeyにした検索用Tableを作成することができる。

検索用TableのAttributeには検索対象TableのSortKeyを入れておく。
または、SortKey以外の値も一緒に引けるように入れてしまうことも出来る。

Local Secondary IndexではPartitionKeyは固定でSortKeyを変えることで検索する方式でしたが、PartitionKeyを別のAttributeにしちゃうのがこれです。
検索用Tableを作成することについてはLSIと一緒です。

見てる動画だとLSI使ってる場面あんまりなくて、ほぼGSI使ってたと思いますｗ

それくらいよく使われるし、制限といえば1Tableにつき20Indexまで。

DynamoDBはPartitionKey・SortKeyの2つをIndexを使ってシンプルに検索させることで力を発揮します。
RDBのWhere区を長々書くような複雑なリクエストをしてしまうと、全件スキャンやフィルター検索など高コストにつながりる。

それを回避するためのテクニックがこの２つ

PartitionKey・SortKey以外のAttributeを条件にしたい場合、GSIを作るときのSortKeyにAttribute同士を結合した値をSortKeyにする。

ハイフンやアンダーバーとかで結合して、新しいAttributeを作るイメージ

特定のItemだけ抜き出したいときに、そのItemに目印となるAttributeを追加する。
その目印のAttributeをPartitionKeyにしたGSIを作れば、低コストで欲しい情報だけを取得する事ができる。

この基礎部分だけでも、今までRDBで実装していたところはほとんど賄えると思いました。
ただ、なんでもDynamoDBに寄せようとするのもご法度みたいですね。

設計段階で必ず使う要素は出来る限り洗い出しておく必要がありそうです。
どのような検索を行うかでテーブル設計が変わりそうなので・・・ｗ
コストがデータ量になるので、いかに一回一回のリクエストで余分なデータを引っ張らないようにするのか工夫が必要そうです❗