RDSではなくてやっぱりDynamoDBで管理したくなる

RDSはいわゆるRDBMSをAWS上のシステムで動かせるクラウドサービスの一つで，スケールアップやスケールアウトするための仕組みを完全ブラックボックス化できることが特徴．普通であれば，Linuxとかで大変な設定とかサーバごとに設定しなければならないことを，シンプルに一つの画面で設定することができるようになる．

RDSを利用することで，バックエンドのエンジニア（しかも分散環境に強い）が不要になる．人的資源の乏しい小規模なチームほどその恩恵を受けられる．

DynamoDBはAWS上で動くNoSQLで，リレーショナルじゃないけど速い（小並感）．RDSと同じく，バックエンドの仕組みがブラックボックスになっている．その上，RDS以上に設定する項目が少なく，トラフィックに応じてテーブルやインデックスごとにスペックを上げることもできる．

RDSとDynamoDBはSQLかNoSQLかぐらいしか違わない．DynamoDBはNoSQL故にある程度速度が担保されているものの，RDBMSほど賢いクエリを投げられない．とりあえず，速いので小難しいクエリを投げる必要のない場合はDynamoDBでデータを運用したほうが速度を保つことができる．

弱点となる賢いクエリを投げられないことに対して目をつむれば，あながちDynamoDBも悪くはないんじゃないかと思う．

という訳で，MySQLのために構築していたテーブルを解体して，全部DynamoDBで運用することにしてみた．やっぱり，RDSを運用する場合の費用対効果も気になる．たぶん，RDSのほうが容量あたりの単価は安いんだろうけれど，速度の面ではDynamoDBには叶わない気がする．特に，データベースが肥大化するほどMySQLは劇的に検索が遅くなる．あいにくMySQLをチューニングするほどの知識はないので，DynamoDBのようにある程度は勝手に速くしてくれるシステムのほうが安全だと思う．

ただ，問題としてはテーブル設計のやり方がRDBMSとNoSQLでぜんぜん違うということ．特に，NoSQLはシステムごとに仕組みが違うので，その仕組みに見合ったテーブル設計は汎用的な技術になり得ない．

特にDynamoDBはMongoDBと比べると癖が強い気がする．インデックスも1ユニットあたりで月あたり50セントもかかるので，無駄なインデックスを張るのももったいない．インデックスは後から追加することができないので慎重に設計しないと金の無駄になる可能性が高い．

そんなわけで，テーブルをひと通り設計して，たぶんサービスの開発を始めても大丈夫かなぁというところまできた．3日ぐらいでそれっぽいものを作れるといいなって感じ．