はじめに

株式会社OMJテクノソリューションズ Advent Calendar 2023　18日目の記事です。

皆さんはNoSQLに触れたことがありますか？
私は学生時代も含めると10年近くRDBを何となく使っている程度だったのですが、
この1～2年でRDBではないデータストアに触れるようになりました。
（よちよち歩き状態を支えてくださった社内のメンバーには本当に感謝です・・・。）

「NoSQLという単語自体はなんとなく知っているけど結局何なんだ」
とずっと疑問だったのですが、

DynamoDBに触れているうちにわかってきたこと
DynamoDBとRDBの差異

を主観ベースで列挙しようと思います！

これからNoSQL（主にDynamoDB）やサーバーレスに触れる、あるいは興味がある人の一助となれば幸いです。

前提

まずNoSQLってなに？

そもそもNoSQLってなんだい？というところなんですが、
「RDB以外のDB」と説明されていることが多い（ような印象）です。

書いて字の如く「SQLではない」
つまり、問い合わせなどの命令をする際にSQLは使わないのです。
ここで思い浮かぶ疑問としては「SQLじゃないなら何でDBに問い合わせするのよ」ということです。
これに関しては各サービス、プロダクト（NoSQL）ごとに異なりますが、
ざっくりとした理解として
「APIに専用メソッドでjsonを送る」
と捉えておくのが良いかなと思います。

NoSQLの特徴としては上記のような問い合わせ方法のため、直感的にコードの中にデータストアとの連携を埋め込むことができます。
話を簡単にまとめると、SQLを使ってRDBとやり取りするよりもかなりシンプルな構成にできるのです。

そして、NoSQLと言えばサーバーレス構成の要のようなイメージです。

サーバーレスってなに？

サーバーレスという言葉がさほど珍しくもない時代ですが、
やはり私と同じように昔ながらの一般的？なシステム構成に触れる機会が多い方は
あまり馴染みがないかと思います。
これまた用語解説となりますが、
サーバーレスは
「サーバリソースを考慮して物理的にサーバを用意して構築しなくてもよいシステム構成」
という解釈を私はしております。
※明らかに間違ってるだろという場合はご指摘ください。

「つまりどういうことだってばよ」という方向けの説明しますと、
仮にWebサービスを作ろうとしたときにまずはWebサーバ、APIサーバ、DBサーバを構築するかと思います。
端的に申し上げますと、そもそもこの構築の手間がなくなります。
デプロイするサービスの設定は必要になりますが、「サーバを用意してサーバの設定をする」という手間が格段に省けるわけです。
これはマイクロサービスをさくっと作ってさくっとリリースしたいなどの場合に大きく効果を発揮します。
サーバの設定等の人的リソースはかなり削減できますし、サーバ自体の費用は（変な組み方さえしなければ）サーバーレスの方が格安です。
このあたりは公式が出しているハンズオンを実際にやってみると実感できるかと思いますのでぜひ！

感覚を掴むまでは検索すら大変

前置きがかなり長くなりましたが、ここから具体的にDynamoDBに関することを列挙していこうと思います。

まず前項までに述べたとおり、SQLで問い合わせを行うわけではないのでレコード検索する時点で苦しみました。
更にRDBのようなプライマリーキーや外部キーの概念がないため「DynamoDBの概念ってなんだ」がもうひとつの苦しみポイントでした。

詳しくはDynamoDBのチュートリアルや解説を読んでいただければと思うのですが、
DynamoDBは各レコードにパーテーションキーとソートキーというものを設定できます。
このパーテーションキーとソートキーの組み合わせが、RDBでいうプライマリーキーという読み替えができます。
そしてレコードに対して操作するには、このパーテーションキーとソートキーを指定する必要があります。
※全件検索などごく一部例外あり

まずは概念を理解してこの感覚を掴むまでにそこそこの時間がかかってしまいました・・・。

設計が大変

先ほど「レコードに対して操作するには、このパーテーションキーとソートキーを指定する必要があります」と記載しました。
SQLでは当たり前にWHERE句で「この条件に当てはまるレコードを操作～♡」と簡単に条件指定できていたのですが、
DynamoDBはパーテーションキー、ソートキーとして設定したカラムが一致するレコードのみ操作できます。

パーテーションキーとソートキーは一意性を表すだけじゃないんかい！！！！！

そしてどの値（カラム）をパーテーションキーとソートキーにするかはテーブル作成時に設定しなければいけません。

つまりどういうことかと言いますと
あまりに適当に（無考慮に）テーブルを作成すると、開発しているうちに
「あれ・・・この機能を実装するためのレコード条件が指定できない・・・」
なんてことが起こったりします。

救済措置？としてGSI（グローバルセカンダリーインデックス）という、
テーブルにパーテーションキーとソートキーの組み合わせを更に追加できる機能もあるのですが、
DynamoDBは従量課金制で、GSIは課金を加速させます。
DynamoDBを動かす回数やレコード数が多くないうちはさほど問題にならないかもしれませんが、ゴリゴリ回したりサービスのアクティブユーザが増えた時に請求金額を見るときっと青ざめることでしょう・・・。
なんとなくRDB的に中間テーブルを作成したり、ロジックで無理やり進めることもできなくはありませんが、コストや保守性の面でいろいろと問題が出てきます。

こうならないためにもテーブル設計はとても大事なのです。
「サーバーレスって構築簡単なんでしょ！」というのはインフラ構築時のコスト的なお話なだけで、
設計がいらないというわけではまったくございません・・・。

最後に

驚かすようなことばかり書いてしまいましたが、慣れてくるとDynamoDBはかなり使いやすいです！
ネガキャンの意図があるわけではないのであしからず・・・。

冒頭でも述べたように「コストをかけたくないけどマイクロサービス組みたい」という時は特に効果を発揮するかと思います！
また、公式のチュートリアル（ハンズオン）がしっかりしているので、とりあえずはそちらをなぞることで何とかなるかと思います。

当カレンダー21日目には私のサーバーレスの師匠である方がAWS Lambdaに主軸を置いたしっかりした技術記事を公開してくださるみたいです！
公式チュートリアルでもあるように、DynamoDBはLambdaと組み合わせる使われ方が非常に多いと思いますので、是非合わせてご確認いただければと思います！！！
（後日リンク貼ります）