同僚のこういう記事を読み、そういえば自分もWeb系の企業に入ってから初めてデータ移行の流れとかを知ったなーとなったのと、せっかく技術ブログあるのにあまり書いてないのは勿体無いなーという気持ちからこの記事書いてみます。
www.yasuhisay.info
技術系の記事はもっと気楽に書いていきたいマン。
何がしたいのか
何らかの理由でデータベースの構造を変えたいとなった際、いきなりガバッと変えたいのもやまやまですが、動き続けているWebサービスだとそれはちょっとできないですよね。いきなり画面がみれなくなった！いきなりログインできなくなった！とかなると大変です。また、いじっている間に何かしらのミスでデータが飛んじゃって前の状態に戻せなくなるとか。Webサービスは出してから後々のリリースで修正を入れることは確かにできますがそれがデータベース層での変更でユーザが24時間使ってるようなサービスだとそうそう簡単に変更はできません。
我々が変えたい先のテーブルやカラムを新たに作り、そこに該当するデータを移行し、最終的にそちらを使うようにするとサービスを止める必要はないし、もしものときは前のテーブルの状態に戻せるので安心です。
流れ
- 新しいテーブルを作る
- 古いテーブルと新しいテーブル両方から読む（新しい方にデータあればそちらを優先）
- データの作成や更新を古いテーブルだけでなく、新しいテーブルでもする
- 古いテーブルにしかないデータを新しいテーブルのほうにもコピーする
- 古いテーブルのほうから読み書きしないようにする
- 古いテーブルの使わなくなったカラムなどはいらなければ落とす
どういうことか
自分は元々DBとか触ったことなかったのでなぜこんなに手順が多くてめんどうなのかと最初思いました。ただ、先ほども書いたように、ユーザは我々が開発したりデプロイしたりしている間もサービスを触っているかもしれないし、途中の段階でおかしくなると困ります。そこで一時的に二つのテーブルから読み書きするようにして最終的に新しいほうを使う、とすると安心という感じですね。
