3

MongoDB にいくつかのコレクションが格納された複数のアプリケーション サーバーを実行するオンライン サービスがあります。私は継続的な展開の方法で作業しています。これは基本的に、コードの更新によって自動テストがトリガーされ、すべてがうまくいけば本番環境のアップグレードが行われることを意味します (これは問題を少し複雑にしますが、質問は CD 以外の展開にも関連していると思います)。

これはほとんどの場合機能しますが、コア データ モデルの 1 つ (または複数) が変更されることがあります。

例を挙げます：

単純なデータオブジェクトがあるとしましょう:

public class User {
    private String id;
    private String name;
    private String[] friendsNames;
}

そして今、私はユーザーを次のように変更することにしました:

public class User {
    private String id;
    private String name;
}

次のような単純なオブジェクトを格納する別のコレクションとして友達を追加します。

public class Friend {
    private String name;
    private String friendUserId;
}

これは問題につながります。新しいデータ モデルに合わせてデータ構造を変更する前にサービスをアップグレードすることはできず、サービスを停止する前にデータを変更することもできません。そうしないと、古いバージョンが新しいデータ バージョンを読み取ってめちゃくちゃになってしまいます。

したがって、唯一の解決策は、すべてを停止し、データベースでアップグレード プロセスを実行してすべてを変更し、新しいコードを実行してサービスを元に戻すことです。

最後に質問です。古いバージョンのアプリケーションが古いデータを使用し続けることができ、新しいアプリケーションが新しいデータ。「UserV1.1」や「UserV1.2」のようなものを、mongo で適切なクラス バージョンを検索するクラス バージョンとして考えましたが、誰かがすでにこれを考えて思いついた場合、「車輪を再発明」したくありません。スマートなソリューションで。

明確にするために、オブジェクトの履歴は気にしません。アプリケーションのバージョンをスムーズにアップグレードできるようにしたいだけです。

4

1 に答える 1

2

「スキーマレス」の楽しさへようこそ。私のアプリケーションでは、「移行」期間を通過できるようにオブジェクトをコーディングすることになりました。つまり、モデルを変更するリリースは、古い「スキーマ」と新しい「スキーマ」の両方をサポートする必要があります。ビットを本番環境にプッシュしてから、すべてを変換する長いプロセスを開始します。次のリリースでは、移行ロジックを取り消します。お尻が痛いですが、効きます。スキーマを変更するには、2 つのリリースが必要です。

于 2013-04-28T04:28:27.753 に答える