０．はじめに

DynamoDB（KVS）のベスプラは、RDBとは異なり正規化をせず、
同一TBLに色んな情報を正規化を極力しない形で、縦に情報をもつこと。

というのを出来なかったので、真剣に考えてみたシリーズのVol.1です。

なお、この記事は、以下の特性でした。

案件特性

① アジャイル案件
② 公共案件＆ミッションクリティカルであり、要望はお客様がもっている
　= 事業会社やベンチャーのような自分たちの好き放題できない。
　　また、データミスが許容されるようなシステムではない。
　　ゆえに、トランザクションも必須。
③ 拡張性が要求される。
　・突発的なアクセス急増に耐えるアーキテクチャ。
　・要件拡張として、DB設計の着手前に
　　アクセスパターンをすべて抽出することは不可能。
④ 性能要求を最重視する。
　・ターンアラウンドタイム：0.5秒
⑤ 超大量データになる。
　・年間で最大約7億レコード
⑥ RDBの思想が強いメンバが圧倒的に占めており、KVSのノウハウがない。

１．特性に対するベスプラ（サマリ）

　さっそく、結論から。

　１）特性③、④のため、オンラインサイドはDynamoDB必須。
　２）特性①、②、⑤、⑥のため、好き勝手なSQL検索を実現するための
　　　DynamoDBのベスプラは、しない方がベター。

２．ベスプラしない方がベターな詳細

　それでは、上記特性下では "DynamoDBのベスプラは、しない方がベター" の詳細な説明をします。
　
　まず、公式のベスプラはGSIのオーバーローディングという手法です。
　簡単にいうと、SKやGSI-PKでは、「縦に情報をもつ」方法です。
　　出典：https://qiita.com/_kensh/items/2351096e6c3bf431ff6f

　ただし、これは特性①、②、④、⑤、⑥の条件ではなかなか難しいです。
　特に"② 公共案件＆ミッションクリティカルであり、要望はお客様" 、④ 性能要求、⑤ 超大量データの条件がすべて求められる場合、障壁は一気に膨れ上がります。

　
　① アジャイル案件
　⇒ 後から色々と要件が追加されるため、アクセスパターンが定まらない。
　　 ②と密に影響してますが、要望は我らではない。
　　　　出典：https://qiita.com/_kensh/items/2351096e6c3bf431ff6f
　　

　② 公共案件＆ミッションクリティカルであり、要望はお客様
　⇒ データ移行や、データパッチも適宜必要となるが、
　　人が理解しにくい構造のため、移行ツールが非常に複雑になる、
　　ミスの温床でしかない。

　⑤ 超大量データ
　⇒ ②のトランザクションと関連。
　　超大量データのため、トランザクションを保持するために、
　　正規化のDBでは1レコード登録すれば良いが、情報を縦にもつため、
　　ベスプラに則ると、10レコード程度に一気に増加する。
　　また、GSI-PKが固定になるため、大量データでは処理が集中する。
　　つまり、データの偏りが生じるため、性能劣化に繋がる。
　　⇔ ④の性能要求に反する。

　⑥ KVSのノウハウがない
　⇒ 事前検証での把握、ないし有スキル者をアサインするのどちらかで
　　安定した設計が実現できる。
　　また、②と関連して、データパッチでミスりやすい。

３．次回予告：どうすりゃいいんだ！

　特定の条件下ではベスプラに則らない方がベターな理由を列挙しました。
　「難しい理由はわかった。うっさい、じゃ？どうすればいいんだ！」
　という内容を次回は記載します。

Others

Noteもやってます。
よければイイねしてください！