DynamoDBは早い安いうまい

僕の推しDBは断然DynamoDBなのだが、これほど癖のあるDBもそうないと思う。

DynamoDBを初めて触ると、あまりにも簡単に構築してCRUDできてしまうし、設計らしい設計もなさように見えるので、すげぇなと思うわけだが、実際にアプリケーションに組み込み始めると色々とその制約が見えてきて、なんだこれはと狼狽することになる。

目次

一覧できねぇ

最初の見えるトラップが何かは人によりけりだろうけれど、やはりまずは「一覧できねぇ」じゃなかろうか。いやできねぇことはないんだが、平然とスキャンを要求される。セキュリティ面のことは置いといて、データ数が少ない間はスキャンでも実用に耐えるだろうが、増えてくればそうもいかない。FilterExpressionなんて項目があることに一縷の希望を見出したりするが、これは走査した後のレスポンスをフィルタするものでしかなく、つまりスキャンすれば結局テーブル全部見るのである。まぁそれでも全部見てくれればまだマシというもので、1度のスキャンは1MBの制限があるので一度のスキャンでは全部見てくれず、複数回スキャンする必要があったりもして、自分はただ直近10件のアイテムがほしいだけなのにと打ちひしがれたりする。

ここらへんで最初のキー設計がめちゃくちゃ重要らしいと嫌でも気づく。またグローバルセカンダリインデックスを使うことで多少の無理には答えられそうだという確かな希望も得る。最初にきちんと設計すればローカルセカンダリインデックスも使えそうだとわかる。ドキュメントの「ビジネスのユースケースが決まるまで設計するな」とかいうかぐや姫でも言わないことは世界が平和になるまで封印する。

多対多の苦労

これである程度、具体的には一対多にはそれなりに対応できるのだが、多対多の要件が出てくるとまた頭をひねることになる。手癖で正規化してしまうとJOINできないため結合のためにN+1でクエリを投げる羽目になる。当然死ぬ。これについては公式からベストプラクティスが出ているのでそれに則ってやればやはりそれなりに対応できる。

あわせて読みたい
DynamoDBで多対多のテーブル設計 DynamoDBの設計を始めてからたいていの人が引っかかるであろう、DynamoDBにおける多対多(many-to-many relationship)の対応について、つらつらとメモする。 AWSのドキュ...

対応できるのだが、これはRDBでいうところの中間テーブルに情報を集約した構造に近く、情報が冗長になる。Aの情報が複数のアイテムに散らばるため、Aについて変更したら複数のアイテムを同時に変更しないと整合性が保てない。一応DynamoDBでもトランザクション処理できるのだが、これも制約があるため注意が必要だ。ライブラリも使いづらいし。それでも昔はトランザクション処理自体なかったのであるだけ良いのだろう。

DB設計というよりシステム設計でありビジネス設計

しかしこれの抜本的な対策は、恐らく要件として原子性や一貫性を多少諦めてもなんとかなるようにシステム全体を調整することだろう。つまりデータベース設計というよりはシステムのアーキテクチャ設計であり、もっといえばビジネスのユースケースとの調整だ。かぐや姫に口を出すパワーがいる。

しかしながらデータベースやアプリケーションを触るエンジニアに必ずしもそういった権限があるわけではない。というか多分だいたいない。上から降ってくる我が儘に調整の余地なく抗えない場合、DynamoDBで頑張るのはけっこうムチャすることになろうとは思う。

まぁ上から突然降ってくる謎仕様については、KVS的な柔軟性のために必ずしも対応できないわけではない。キー設計で対応できれば、言い換えるとクエリを変えなくてよければ、かなり楽に対応できる。ここらへんはRDBよりもやりやすいと感じられるだろう。逆に言うと、今のキー設計で対応できなそうだとつらいことになる。具体的には複数の属性を結合した地獄のようなグローバルセカンダリインデックスになるだろうか。

最高の非機能

他にも検証とか基本的にプログラムで頑張ってねという感じなので、とにかくアプリケーション側の仕事が増える。色々とDBの特性を把握して面倒見てやらないといけない。などなど、機能的にはかなりの制約があるように見える、見えるというか事実あるのだが、それにも関わらず僕がDynamoDB大好き芸人なのは、インフラ面における運用の楽さに尽きる。特に課金体系としてオンデマンドを選択した場合、マジでほとんど何も考えなくていい。阿呆でいられる。

アプリケーションにもインフラにもそれぞれ苦労があるが、のっぴきならない何かがあった時、どちらかというとアプリケーションのほうが対応しやすく、また被害も抑えやすいように思う。インフラはどうにもならん時はもう本当にどうにもならんし、対応にも時間がかかるし、また症状もサービスがまるごと落ちるなど深刻な障害という形で現れやすい。なのでインフラを「ちゃんとやる」のはかなりの労苦であり、新規事業やりがちの自分にはどうにもつらい。

そんなわけで、つらいインフラについて脳死でいられるという一点だけでも、僕はDynamoDBが好きなのである。

しかもそんな素敵インフラとマネージドサービスを提供してくれるDynamoDB、めっちゃ安い。DBはクラウドでも金喰い虫になりやすいところだと思うが、DynamoDBはコスパも良好。特に大きくないサービスであれば無料枠でほぼ戦えるものと思われる。僕はプライベートでもライフログやら自前のBTCチャートやらにDynamoDBを使っているのだが、1円もかかっていない。

早い安いそして……

ということで、色々言ってきたがとどのつまりDynamoDBはさくっと作れて破壊も簡単、パフォーマンスよくスケーラビリティ最高、それでいながらコスパも良好。ただし前述のとおり癖強でアプリ頑張るのはもちろん、システム全体ってかビジネスにも口出す設計が必要。そこは人間。頑張れ人間。

つまり、DynamoDBは早い安い(人間が)うまい。うまくあれ。

この記事が気に入ったら
フォローしてね!

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

コメント

コメントする

目次