私は NoSQL データベース エンジンを作成しており、開発者が Web サイトの動作を停止することなくアプリケーションを新しいバージョンにアップグレードできるようにする機能を提供したいと考えています。つまり、アップグレード中のダウンタイムは 0% です。私の質問は、24 時間年中無休で実行され、データベース構造が頻繁に変更される場合の Web アプリケーションの方法または一般的な設計は何ですか? 例や成功談があれば大歓迎です。
6 に答える
2
企業がデータベースの地理的分散に投資できる場合。フェイルオーバー耐性と同様。従来のように聞こえますが、データ レプリケーション (またはデータストア レプリケーション) は、トラフィックのルーティングに関しては問題になりません。
オプション 2:- キャッシング (カスタム開発) とサイクリングの使用。例:- 午前 1 時から午前 2 時まで、データベースのスナップショット 1 を使用します (たとえば、サーバー 1 /データ センター 1 とします)。データセンター 2 経由。
スナップショットに基づく循環は、考慮すべき解決策になる場合があります。
于 2013-05-07T01:20:27.357 に答える
2
NoSQL (具体的にはドキュメント指向データベース) を使用すると、バージョン管理によってこれを実現できます。
すべてをドキュメントとして保存する MongoDB について考えてみましょう。
MongoDB では、すべてのドキュメントのスキーマが異なるコレクション (ドキュメントのグループ) を持つことができます。
ユーザー向けに次のドキュメントがあるとします。
{
"_id" : 100,
"firstName" : "John",
"lastName" : "Smith"
}
これを同じコレクション内のドキュメントとして持つこともできます。
{
"_id" : 123,
"firstName" : "John",
"lastName" : "Smith",
"hasFoo" : false
}
スキーマは異なりますが、両方とも同じコレクションにあります。明らかに、これは従来のリレーショナル データベースとは大きく異なります。
その場合の解決策は、スキーマ バージョンを持つすべてのドキュメントにフィールドを追加することです。次に、すべてのクエリでアプリケーションがそのバージョンを検索するようにします。
MongoDB クエリは次のようになります。
users.find({ "version" : 3 }).limit(10);
これは、スキーマ バージョン「3」を使用しているすべてのユーザーを返すだけです。既存のサイトに影響を与えずに新しいスキーマを挿入し、不要になった古いスキーマ バージョンを徐々に削除できます。
于 2013-05-06T15:01:42.420 に答える
1
実稼働環境の多くの Web サーバーがそのデータベースにアクセスし、互換性のないコード変更 (フィールドを削除して新しいフィールドを追加する) がある場合は、マルチステップ ソリューションをお勧めします。少し手間がかかりますが、細部に問題が発生した場合にダウンタイムのリスクはありません。
最初のステップでは、古いバージョンと新しいバージョンが書き込まれるようにアプリケーションを拡張し、そのバージョンをデプロイします
2 番目のステップでは、可能な限り古いデータ フィールドの値を新しいデータ フィールドに変換します (時間がかかる場合があります)。
3 番目のステップで、新しいフィールドのみを読み取るようにアプリケーションを変更し、デプロイします
4 番目のステップで古いフィールド値を削除します
5 番目のステップでは、コードから古いフィールド値の書き込みを削除し、デプロイします。
于 2013-05-12T18:55:00.563 に答える
0
これを実現できる唯一のケースは、完全にステートレスなアプリケーションを使用している場合です。ステートレスという用語には、アプリケーション データとアプリケーション構造の両方が含まれます。アップグレードには、データに加えてビジネス オブジェクトの定義の変更が含まれる場合があることに注意してください。このようなステートレス アプリケーションは明らかな理由で実用的ではないため、一般的なアップグレードでダウンタイムをゼロにする実用的な方法はありません。ステートレスでないアプリケーションでは、ライブ ユーザーが (中間層で) ビジネス オブジェクト定義とビジネス データをキャッシュします。アップグレードにより、新しいビジネス データだけでなく、新しいビジネス オブジェクト定義も保証される場合があります。ライブ ユーザーによってキャッシュされたデータは、常に新しいスキーマとの潜在的な不整合を引き起こす可能性があります。そのため、中間層にキャッシュされたデータとメタ データ (ビジネス定義) の両方を移行できなければ、ライブ ユーザーを移行することはできません。中間層のキャッシュを吹き飛ばすと、ライブ ユーザーが影響を受けます。ライブ ユーザーが古いデータベースで引き続き作業できるようにし、後でデータの変更を新しいデータベースに移行/マージすることを検討してください。しかし、それは解決するのが難しい問題でもあります。稼働中のユーザーに影響を与えることなく、停止時間ゼロのアップグレードで許可されるものを制限したり、データベースのアップグレード後に、ログアウトして新しいスキーマに対して再度ログインしない限り、稼働中のユーザーが読み取り専用ユーザーになるようにすることができるようになりました。ライブ ユーザーが古いデータベースで引き続き作業できるようにし、後でデータの変更を新しいデータベースに移行/マージすることを検討してください。しかし、それは解決するのが難しい問題でもあります。稼働中のユーザーに影響を与えることなく、停止時間ゼロのアップグレードで許可されるものを制限したり、データベースのアップグレード後に、ログアウトして新しいスキーマに対して再度ログインしない限り、稼働中のユーザーが読み取り専用ユーザーになるようにすることができるようになりました。ライブ ユーザーが古いデータベースで引き続き作業できるようにし、後でデータの変更を新しいデータベースに移行/マージすることを検討してください。しかし、それは解決するのが難しい問題でもあります。稼働中のユーザーに影響を与えることなく、停止時間ゼロのアップグレードで許可されるものを制限したり、データベースのアップグレード後に、ログアウトして新しいスキーマに対して再度ログインしない限り、稼働中のユーザーが読み取り専用ユーザーになるようにすることができるようになりました。
于 2013-05-13T23:41:18.260 に答える