Firebaseのマイグレーション

# Firebaseのマイグレーション

前回[Firebase.yebisu](https://connpass.com/event/69238/)で質問を頂いた。Firebaseのマイグレーションについて言及します。

## TL;DR
**マイグレーションはスキーマ定義が汚れてもいいから新しいプロパティをはやすことで頑張る！**

## ビジネスとDBマイグレーション
マイグレーションについて話を進める前にマイグレーションはどのようなシーンに置いて必要なのか私の考えを述べようと思います。
一言でマイグレーションと言ってもその規模は様々で今から話をする内容がどの規模の物かを想像するのは、その人の置かれた状況や立場によって考え方が変わると思います。

- 既存DBからのFirebaseへの移管
- FirebaseからFirebaseへの移管
- スキーマの変更

そんな中まず最初に述べたいのは、マイグレーションは実施しないに越したことはないと言うことです。
なぜなら**リスク**が必ずついてくること、リスクに対しての**リターン**が見合うかはやってみないとわからないことの方が多いことが理由です。
マイグレーションを行う際には、技術的な検証よりもビジネス的な検証をまず優先することをオススメします。リスクとったけどビジネスにならないのでは、とんだ骨折り損です。

既存DBでサービスがまわっているのであれば移管しなくともFirebaseには[カスタム認証システム](https://firebase.google.com/docs/auth/users?hl=ja)と呼ばれるものがあるのでこれを使って両方のDBを共存させるのが有効だと思います。
時代によって新しいDBはどんどん出てくるのでDBを統一化してしまうより、インターフェースを揃えてカプセル化してしまう方がよっぽどエンジニアフレンドリーに開発を進めることが出来ます。
MySQLであろうと、DynamoDBであろうと、Firebaseであろうと、サービスを利用するユーザーには全く関係ないのでDBのマイグレーションについては特に慎重に判断して下さい。

と言うことでここではビジネス影響が少ない範囲について説明していきます。

## マイグレーションについて

FirebaseはスキーマレスDBですが、スキーマを設計して開発を進める方が圧倒的に効率的ですので複数のモデルを先に定義してしまいましょう。
今回は下記の３つで話を進めて行こうと思います。

- User
- Group
- Item


また加えてiOS向けのModel Frameworkである[Pring](https://github.com/1amageek/Pring)の内部についても言及します。iOS向けではあるものの構文も非常に似ているので**TypeScript**や**Kotlin**で同じものを構築していくことが可能だと思います。

### スキーマ定義

#### User

```swift
class User: Object {

    var status: Int = 0

    var name: String = "unknown"

    var friends: ReferenceCollection<User> = []

    var groups: ReferenceCollection<Group> = []

    var items: NestedCollection<Item> = []
}
```

#### Group

```swift
class Group: Object {
    var name: String = "unknown"
    var onwner: Reference<User> = Reference()
    var users: ReferenceCollection<User> = []
}
```

#### Item

```swift
class Item: Object {
    var name: String?
}
```


__Pringの機能について__
Pringでは開発を効率的行うために以下の機能を持っています。
*マイグレーションについてのみ理解を深めたい方は飛ばしてもらって構いません。*

| 関係性 | 機能 | 説明 |
| --- | --- | --- |
| 1:1 | Reference | 1:1の関係を表します。`Salada`では関係性をIDで管理していましたが、関連したインスタンスを保持できるようになりました。 |
| 1:N | NestedCollection | 1:Nの関係を表します。名前の通りネストされた状態で保存されます。上記の定義ではItemは上位ノードでは保存されず、 Userの下に配置されることとなります。Itemにアクセスするためのパスを示すならば次のようになります。 </br>/user/:user_id/items/:item_id|
| 1:N | ReferenceCollection | 1:Nの関係性を示します。NestedCollectionと違うのは上位ノードでモデルが保存されることです。 Userがもつfriendsにアクセスするためのパスを示すならば次のようになります。 <br>/user/:user_id/friends/:user_id/<br>ただしここには値が存在しないため、<br>/user/:user_id/ <br>アクセスする必要があります。|


### Userのマイグレーションについて考える。

Firebaseのマイグレーションで考えられるのは以下の3つのパターンです。

| パターン | 説明 |
| --- | --- |
| ADD | 新しいプロパティを追加する |
| MOD | 既存のプロパティの型を変更する |
| DEL | 既存のプロパティを削除する |

それぞれについて考えて行きましょう。

#### ADD

**どんな作業が必要か？**
Firebaseはスキーマレスなので大きな作業は必要になりませんね。

**サービスへの影響は？**
ADDは基本的に新しい機能を追加する場合に起るマイグレーションパターンです。新機能を使い始めたときにプロパティーが追加されさえすればこちらもなんの問題もないと思います。


#### MOD

**どんな作業が必要か？**
MODのイメージを具体化させるために例をあげてみます。
Userのstatusは今`Int`で定義されていましたがわかりにくかったので`String`に変更することにしました。

作業ストラテジーは2つ考えられます。

1. MODもADDにしてしまう。
2. MODする。

##### MODもADDにしてしまう

MODもADDにしてしまうとはつまり、新しいプロパティとしてstatusを定義してしまう方法です。そうなると次のような感じになります。

```swift
class User: Object {

    var status: Int = 0

    var statusStr: String = "none"

    var name: String = "unknown"

    var friends: ReferenceCollection<User> = []

    var groups: ReferenceCollection<Group> = []

    var items: NestedCollection<Item> = []
}
```
運用でカバーってやつですね。遺産としてstatusは残りますが、まぁ固いこと言うなよ。正直これでいいと思ってます。

##### MODする

問題は本気でMODする場合ですね。
ここでも作業ストラテジーは2に考えられます。

1. 既存データを全て置き換える
2. 必要なデータを置き換える

既存データを全て置き換えるのは古典的な方法ですね。他のDBでマイグレーションと言うと基本的にこれを想像するはずです。しかし現代では不可能に近い方法です。FacebookやTwitterを想像すればその理由はわかると思います。
データの増加量にマイグレーション量が追いつかないと思います。

必要なデータを置き換えるのが現実的です。必要なデータとは、つまりアクセスされたデータのことを指します。データにアクセスされたらそのときにデータをマイグレーションしてしまいましょう。このとき注意しなければならないのが**バージョン管理することです。古いバージョンのアプリからもアクセスがあることを考えると古いデータも残して置く必要があります。**
そしてデータは**Double Write**が必要になります。
Modelをバージョン管理してマイグレーションを行う**マイグレーションチェーン**については後ほど詳しく説明します。

**サービスへの影響は？**
選ぶストラテジーによって影響は異なりますが、本気でMODする場合はマイグレーションの時間分少しレイテンシが発生します。いずれにしてもサービスを止めることなく作業が行えるのでサービスには大きな問題はないと思います。

#### DEL

**DELに関してはやらない**と割り切ってしまう方がいいでしょう。基本的に論理削除のみを行い物理削除はやらない方がいいです。FirebaseにはDBの妥当性を担保する方法がありません。
**どうしてもやった方がいいと意見をお持ちの方はぜひその理由を教えて欲しいです。**


### マイグレーションチェーン

マイグレーションチェーンの概要に説明します。
マイグレーションチェーンは必要なデータのみマイグレーションを行うというストラテジーを基にデザインされています。
マイグレーション後の理想な姿は、Appがそれぞれのバージョンでバージョンを参照している状態です。
しかし、必要なデータのみマイグレーションを行うと言うことは、まだマイグレーションが終わってないデータが存在することもありえます。

**理想**

<img width="646" alt="スクリーンショット 2017-12-04 17.00.17.png" src="https://qiita-image-store.s3.amazonaws.com/0/80287/616e8afb-82a6-8f18-cda7-25a80babb123.png">

**現実**

<img width="613" alt="スクリーンショット 2017-12-04 17.02.11.png" src="https://qiita-image-store.s3.amazonaws.com/0/80287/135ffaba-6d01-ce79-79bd-3dde8ffc5898.png">

このとき、マイグレーションを再帰的に行います。これがマイグレーションチェーンです。

<img width="816" alt="スクリーンショット 2017-12-04 17.24.43.png" src="https://qiita-image-store.s3.amazonaws.com/0/80287/0cdf22b2-a23f-65c3-07c9-96074095924e.png">

マイグレーションチェーンを利用するためにはいくつか制約があります。

1. データは必ずいずれかのバージョンに存在する
1. データはどのバージョンでも同じIDを利用している 
1. 下位バージョンが変更されると上位バージョンに伝達される

#### データは必ずいずれかのバージョンに存在する
データがどのバージョンにもない場合は、データが削除されたことを意味します。上の図のApp3.0からリクエストがコールされた場合毎回マイグレーションチェーンが走ることになるので必ずデータを保持するようにしてください。

#### データはどのバージョンでも同じIDを利用している
データはIDによって管理されるため、IDは必ず同じものを使う必要があります。そうするとデータへアクセスするときはversionの番号だけ変更してあげればよくなります。

```
/version/1/model/:model_id/
```
```
/version/2/model/:model_id/
```

**Pringではバージョンを定義できるようになっています。**

modelVersionをオーバーライドすることでバージョンを管理する。
詳細はこちらから
https://github.com/1amageek/Pring/blob/master/Pring/Object.swift#L15

```swift
class User: Object {

    class var modelVersion: Int {
        return 1
    }
}
```

#### 下位バージョンが変更されると上位バージョンに伝達される

上位バージョンが存在するデータではすでに新しいバージョンでのデータを利用した運用が始まっていると言うことです。この時古いバージョンのデータが更新されれば必ず上位バージョンまでその変更を伝えてあげなければなりません。

<img width="766" alt="スクリーンショット 2017-12-04 18.40.45.png" src="https://qiita-image-store.s3.amazonaws.com/0/80287/341443cf-65b6-6c04-832a-bc376eeaea79.png">

また上位バージョンが変更された場合も下位バージョンに伝達する必要がありますが、これを実装するくらいならば、アップデートを促す仕組みを取り入れた方がいいと思います。

## まとめ
マイグレーションチェーンの運用しますか？やらないですよね？
新しいプロパティを運用しましょう。
Pringにはマイグレーションチェーンの機能を実装しようと考えてますが。

ではでは素晴らしいFirebase Lifeをお楽しみください。