小規模なスタートアップで(炎上気味な)受託案件をやっています。
5年前に導入したmongodbを使って構築されたバックエンドで案の定mongodbが負債になっていて、長いこと我慢して開発してきました。
「私が移行作業全てやるのでPostgreSQLに移行したいです。1週間それだけに時間を使っていいですか？dbの正規化とかも全て私がやります。作業の見通しも大体ついてます。」とリードに聞いたら何の反発も無くあっさり受け入れられました。
死ぬほど大変そうですがやっていき！
(編集済み)
11
コメント一覧
PostgreSQL
投稿者
- posgresql
+ PostgreSQL
移行は目立たないけど非常に重要ですよね。頑張ってください！
投稿者
ありがとうございます！
ユーザー目線では無影響ですね確かに
スキーマレスからリレーショナルの移行は結構大変そうですが、とりあえず JSONB に入れて部分的にだけリレーショナルなデータモデルにする感じですか？
たとえばネストされた配列要素の更新や集計は Mongo の方が自然に書けると思いますが、複雑な書き換えがあると大変そうだなと思いました。
投稿者
おっしゃる通りです
幸いmongoの利点をフル活用してる箇所が少なかったので、書き換えが大変そうな箇所はありますが何とかやれそうです
結果のアップデートお待ちしてます。
昔働いてたスタートアップの製品が MongoDB をメイン DB に使っていて、成長とともに順当に負債化していって（そこまで生き残れた時点で成功なんだけど）、後から入ってきたメンバーがモンゴはクソだと dis りながら中途半端にポスグレを混ぜてシステムを複雑化させる（しかし完全移行を提案するガッツを持ってるやつはいない）様を忸怩たる思いで見ていた身として、いろいろ懐かしくなるトピックでした。
やりきる覚悟を買った、一週間なら捨てても痛くない、こいつならやれると腕を買われてる、などいろんな要素がありそうですが、うまくいくことを願ってます！モンゴを使ってるプロジェクトがまたひとつ減るのはちょっと寂しいけどw
投稿者
ありがとうございますw
完全移行を死ぬ気でやります！
コードよりもデータ移行の作業が大変そうですが幸いテストはしっかりあるのでデグレの心配が少ない
具体的にどのような面で負債になっていたんでしょうか
言える範囲で教えていただければ嬉しいです
投稿者
MomgoDBなので当然なのですがforeign key制約ができないことでアプリケーション側での参照先のnullかどうかのチェックが膨大な量になっています。
またこれは我々が悪いのですが初期にschemaの設計をサボったため事実上どんなshapeのjsonでも全てのcollectionに入れることができてしまい、逆に言えばあるコレクションに関して全てのドキュメントを走査して何かの値の統計を取るとき、その項目のif nullをいちいち書いてしまっています。
統計だけでなく一つのドキュメントを取得してあるレスポンスを生成したり、業務ロジックを書く際にもデータベース的にnot nullが保証されていれば書かなくてよかったif文が増えてしまいました。
最後に、連携予定のオンプレで動作している別アプリがPostgreSQLを使っていることが判明し、将来的に同じDBサーバーを使うことでそのアプリのユーザーのテーブルを(外部キー制約で)参照することを見据えての移行の提案でした。
