データベーススキーマの移行は運用環境で問題になりますか？

NoSQL対SQLデータベースに関する議論で、スキーマを新しいバージョンに移行するのは問題があるため、企業はスキーマレスのNoSQLデータベースを使用することを好むと聞きます。しかし、アップグレードを行うとき、それは本当に大きな問題ですか？リレーショナルデータベースは、このような操作に悪いですか？

MongoDBブログの次のブログ投稿を読んでください。なぜSchemalessなのですか？

NoSqlデータベースが従来の意味でスキーマを持っていないからといって、それが変化したときに対処する必要のある論理スキーマがないわけではありません。MongoDbを使用する典型的なアプリの場合、ほとんどの場合、コードはjsonオブジェクトの特定のフィールドが特定の方法で動作することを期待しています。動作を変更すると、データベース内の既存のデータを更新する可能性があります。さて、従来のRDBMSでは、これは主に解決された問題でした。基礎となるテーブルを変更するだけでした。しかし、これらの新しいNoSQLデータベースを使用して、決断を下します-すべてのオブジェクトを変更して更新するスクリプトを作成しますか？または、オンザフライでバージョン間で変換するコードを追加しますか？その場合、v1オブジェクトをどのくらいサポートしますか？永遠に？v3まで？

MongoDbブログ投稿で使用されている例は、RDBMSに関係なく適切な更新プロセスを持っている場合、少し単純化され、非常に簡単に処理できることを付け加えます。フィールドを追加してもほとんど問題ありません。それはあなたが自分のName分野を分割することを決めたときでFirstNameありLastName、物事はエキサイティングになります。

しかし、アップグレードを行うとき、それは本当に大きな問題ですか？

かもね。

一部の組織は-まあ-解体されており、スキーマ移行の非常に悪い仕事をしています。

1. 「移行週末」。サーバーを停止します。すべてのデータをバックアップおよびエクスポートします。新しいスキーマを作成します（多くの場合、既存のスキーマを変更します）。データをリロードするか、所定の場所に再構築を試みます。

2. 「継続的な調整」。SQLで許可されている範囲でテーブルを変更します。実行されたALTERのシーケンスを追跡しません。以前のスキーマバージョンに戻る方法はありません。必要に応じて、既存のテーブルから新しいテーブルを作成し、できればすべてのアプリケーションを調整して新しいテーブルを使用するようにします。しかし、良いQAが不足しているため、「万が一に備えて」古いテーブルをそのまま残しています。

3. 「フルパニック」。スキーマの変更を防ぐだけです。大きな悪臭を放つ。リスクが高すぎると主張する。この方向のすべての努力をブロックします。より賢明なアプローチを採用するまで、スキーマを人質にしてください。

リレーショナルデータベースは、このような操作に悪いですか？

スキーマは移行するのが面倒です。

最大の問題は技術的なものではありません。

セマンティックです。

スキーマ変更の主な理由の1つは、以前のスキーマが問題のドメインとあまり一致していないことです。セマンティクスが変更されたため、データベース（およびアプリケーション）を変更する必要があります。これらは、アプリケーションがデータを操作する方法を再考する必要がある大きな変更である場合があります。

データベースのセマンティクスの修正は非常に困難です。

スキーマ変更の代わりに人々が行うことは、物理スキーマの誤用です。できるため、既存のフィールドに間違ったデータのロードを開始します。「コメント」フィールドに突然、重要な顧客管理情報があり、その後に「//」とそれに続く実際のコメントが続きます。これは、「フィールド1-フィールド2 //コメント」というデータの断片にまで拡大します。「実際の」アプリケーションソフトウェアには変更が難しいスキーマがあり、ITが変更を拒否したため、ユーザーはコメントフィールドからこの追加データを抽出するスプレッドシートを持っています。

問題なく、テーブルと（nullable）列を追加して運用データベースをアップグレードします。アプリケーションの以前のバージョンは、アップグレードされたデータベースで正常に動作しますが、新しいものを参照しません。テーブルや列の削除、または既存のデータの保存方法の変更は避けますが、必要な場合は適切な変換スクリプトを作成します。データベースに宣言されたタイプセーフスキーマがあるかどうかにかかわらず、データ構造の変更には、新しい構造と対話するためのデータ変換とアプリケーションのアップグレードが必要です。

場合によります。

まず、複数のマシンにまたがる非常に大きなデータベースがある場合、すべて（データベースの更新だけでなく）が苦痛になります。（事前にいくら計画しても）。

第二に、データベースの更新は単なるデータベースの問題ではなく、DBが含まれるより大きなシステムにも依存します。これには、データベースの展開も含まれます（多くのデータベースサーバー、複数のデータセンター、マスタースレーブのセットアップなど）。

すべてのDBスキーマ変更イベントを何らかの「認識」できるようにシステムコンポーネントを設計することで、痛みを緩和できます。これは、システム全体がスキーマの変更に耐え、「適切な」方法でそれに対応できることを意味します。

MySQLスキーマの更新に取り組むためにFacebookによって開発されたユーティリティをチェックアウトできます。

また、マスターを読み取り専用にする、スレーブに変更を加える、開発コピーを変更するなどの標準的なベストプラクティスがあります。

いずれにせよ、完全なバックアップと広範なテストスイートを用意することは必須です。そのときだけ、変更を自信を持って安全に行うことができます。