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 Black Belt Online Seminar】AWS Step Functions

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

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

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

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

基礎知識

Table・Itame・Attribute

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

PartitionKey・SortKey

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

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

Local Secondary Index(LSI)

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

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

Global Secondary Index(GSI)

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

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

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

コスト削減

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

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

Composite Key

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

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

Sparse Indexes

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

まとめ

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

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

コメント