データベース構造のバージョン管理された移行：これを行わないほうがよい理由

背景

データベースには、データベース構造の移行に関するさまざまな記事が多数掲載されており、この問題を解決するための多くのオプションが提供されています（この種の移行の必要性自体が深刻な問題であることを考慮する価値があります）。 好奇心is盛ですが、そのようなソリューションの必要性を排除するために提供される頻度ははるかに少なくなります。 著者は、複雑な問題の解決策を見つけるのではなく、それを防ぐことを試みることをお勧めします。 できるだけ早くこれを行う必要があります。 以下に、データベース構造の移行のマイナス面を示すプロジェクトについてのストーリーがあります。



注目に値する記事：

• データベース構造のバージョン化された移行：理論から実践へ
• データベース構造のバージョン化された移行：主要なアプローチ

著者が信頼できる理由

誰も信用することは不可能ですが、著者は、常識と論理に導かれ続け、適切な懐疑心を持って彼の言葉に反応することを心から望んでいます。 とはいえ、著者は、しばしば大げさな問題を解決する代わりに、もっと楽しいものに時間を費やすことができればうれしいでしょう。 この記事で説明するアイデア、評価、前提は、長年にわたるソフトウェア開発経験の結果です。 とりわけ、著者は、5年以上にわたっていくつかの新製品の既存および開発のサポートを率いてきました。そのため、説明されている問題は関連性があります。 数年後、ついに情報を共有する機会になりました。 以下に、深刻な問題の実際の例、それらを解決し、防止する方法を見つけることができます。 議論されるプロジェクトはかなり小さいですが、それにもかかわらず、非常に示唆的です：

まとめ

以下の議論を促進するために、すべてのコメント、仮定、結論を要約してみます。

1. 最新の開発プロセスは、短い反復、頻繁なビルド、および継続的な統合に焦点を当てています
2. 増分データベース構造の変更は、DBMSの明らかな制限のために非常に高価です
3. 開発の初期段階では、DBMSの制限は必ずしも明白/興味深いとは限りません（以下を参照）
4. 成功した製品はほとんどの問題に直面し、大きなサイズに達します。これは、多くの問題を修正するコストが莫大なときです
5. データストレージと処理の選択により、アプリケーションアーキテクチャが決まります
6. 後の段階でアーキテクチャを大幅に変更することは、非常に高価な喜びです。
7. ビジネスと収益性の面で明らかな利点があるため、プロセスのスピードアップを試みるのは開発の後期段階です
8. データベース構造の変更には、多くの場合、保存されたデータの追加の処理/変換が必要です。
9. 後の段階では、DBMSの多くの制限によるデータベース構造の変更には問題があります。
10. 多くのプロジェクトでは、初期段階でのデータベース構造のバージョン化された移行は明らかな解決策のように見え、その後深刻な制限になります。 多かれ少なかれ普遍的なレシピ-データベース構造の頻繁な変更を避ける必要があります。

別の例

現代開発の特徴

開発の現代的なスタイルには、考慮すべき多くの制限と要件があります。 たとえば、1週間から数時間の期間で、テスト用のアセンブリをビルドするように求められる場合があります。 テストを担当するチームまたは機能を独立して実装する別の開発チームには、以前の製品ビルドが既にインストールされている可能性があることを理解しておく必要があります（データベースは既に作成されており、誰も失いたくないテストデータが含まれています）人々の時間を尊重し、ビルド間で透過的なアップグレードを維持します。 集中的な開発では、新しいアセンブリごとにデータベース構造の変更が発生する可能性があります。



最終リリースには、データベース構造に対する多くの変更（多くの場合、相互に排他的）が含まれる場合があります。これにより、クライアント側のアップグレードが驚くほど遅くなり、システムの実際の目的に関係なく、重要な要因。 言い換えると、開発プロセスは理想的ではない場合があり、移行に伴うさまざまな問題を解決するために追加の時間が必要になる場合がありますが、クライアントにとっては、問題や外部からの干渉なしにすべてをできるだけ早く実行する必要があります。



簡単に：

• 集中的な開発-頻繁なアセンブリとデータベース構造の頻繁な変更
• 開発者は単独で動作しません-テスターと依存開発者を覚えておいてください
• 問題は移行のどの段階でも発生する可能性があります
• 多くの場合、移行の問題をすぐに特定することは困難です
• 「壊れた基盤」は常に時間のコストにつながります
• データベースが「更新」、動揺、さらには怒っている間に数時間待機するクライアント
• 顧客の失敗とは、数桁も多くの問題とその解決に必要な時間を意味します

例1、14年前のシステム

簡単な説明

解決すべき主な問題は、いくつかのタイプのネットワークデバイスの平均数を管理することです。 実際のインストールのサイズは、1〜60台のデバイスでした。 システムから、デバイスは構成および制御コマンドを受信し、それに応じて確認、さまざまな統計、および「テレメトリー」を送信します。 このシステムは、さまざまなデバイス構成を編集するためのユーザーインターフェイスも実装しています。 設定（およびユーザーインターフェイス）の複雑さ、履歴の保存、膨大な数のオプションのサポート、特定のユーザーデータタイプなどに注意する価値があります。 構成には、10から数百の異なるパラメーターを含めることができます。 すべてのデータを保存するために、データベースが使用されました（主にMySQL）。

簡易モデル

基本的に、システムのタスクは、各タイプのデバイスの数百のパラメーターを保存し、ユーザーにそれらを編集するための便利なインターフェースを提供し、デバイスに送信される結果の構成を形成することです。

タイムライン：始まり

他の製品の場合と同様に、このシステムの開発は1つのデバイス、いくつかのパラメーター、非常に単純なデータベース構造から始まりました。 最初のアイデアによると、構成を保存するテーブルの各パラメーターに個別の列が使用されました。 このようなソリューションは、簡単で最適とはほど遠いものでしたが、長続きしませんでした。クライアントベースの拡大には、各デバイスのパラメーター数の増加、新しいタイプのデバイスの追加に関連して、より多くの機能を追加する必要があり、前の1つにロールバックできるストーリーバージョンなど







顧客ベースの拡大により、会社はますますアクティブな開発スタイルを持ち、新しい顧客の要求を実装し、より厳しいリリーススケジュールに移行する必要がありました。 開発を加速する必要があるため、いくつかのほぼ独立したチームが作成されました。誰かがデバイスの開発に専念し、誰かが制御システムを開発し続け、さらにいくつかのチームがソリューションの「動物園」全体をテストする責任を負い、突然大きな利益をもたらし始めました。

この段階での問題

ユーザーは制御システムを介してデバイスと対話するため、後者を開発および改善するタスクは非常に重要になりました。 新しい機能の実装は、データベース内の1つ以上のパラメーター（列）の追加、削除、または置き換え、ユーザーインターフェースと生成された構成の対応する編集に限定されました。 しかし、後で判明したように、ほとんどの場合、開発者はデータベース構造の変更に関連するさまざまな問題の解決に費やしました。 誰もテストデータを手放したくなかったし、次の変更後にシステムを稼働状態にするための追加の手順を実行したくなかった。



同社のクライアントにも問題はありませんでした。長期にわたってデバイスを管理する能力を失いたいと思った人はほとんどいませんでした。明らかに、制御システムなしでは誰も望みませんでした。 しかし、データベースのサイズは数十メガバイトからギガバイトの範囲であったため、移行が完了するのを待つために数時間を費やす不満のお客様（多くの場合、リリースには数十または数百の変更が含まれていました）や、インストールプロセス中に何らかのエラーを受け取った悪意のあるお客様でさえありましたシステムの新しいバージョンとサポートサービスがそれらに注意を払うのを待っています。

技術的な詳細

ALTER TABLEを使用して既存のテーブルを変更することは、おそらく安価な操作ではありません。 著者は、テーブルメタデータの変更に至る理想的なオプションを事前に省略し、存在する可能性のあるインデックス、データを変換する必要性、ディスク上のデータの物理的な配置、理想的なテーブルビューとデータの実際の配置と対応するパフォーマンスの問題の違いについて考えるように読者を促しています。



ちなみに、ALTER TABLEを使用しないという呼び出しに出くわすことがよくあり、プロシージャよりもコピー名の変更を優先します（例： テーブルを変更しない。コピーして名前を変更する ）



どんな場合でも、最も単純な複雑さではないデータを変換するには、何らかのプログラミング言語で実装された追加のロジックを使用する必要があります。

解決策

この段階で、会社の明るい頭脳は、データベース構造を変更し、非常にファッショナブルな（人気を博し始めた）XML形式でデバイス構成を保存する必要性を完全に取り除くことにしました。 同意します。非常に便利です。XMLをオブジェクトツリーにデシリアライズし、それらを操作してから、XMLにシリアライズしてデータベースに保存します。 当然、データベースにはBLOBが表示されますが、しばらくの間、この問題をデータベースに任せることにしました。 データを変換するために、小さな独立したプログラム（最初はperlスクリプト、次にJavaのロジック）が使用されました。これにより、データベースのバージョンXからバージョンYへの順次変換が保証されました。

効果

新しい機能（新しいオプション）の追加がXML表現の変更に減ったため、データベース構造への変更はゼロに減り、プロセスを大幅に簡素化しました（少なくともデータベースの操作の観点から）。 何も心配することなく、より複雑なデータ構造を操作できるようになったため、開発プロセスが加速しました。 これで、履歴を保存することができます（いくつかのXMLを保存するだけです）。

タイムライン：なること

構成保管方法を大幅に処理した後、システムの開発が加速し、一見したところ問題の数が減少しました。 会社は新しいバージョンをリリースしました。これはインストール中に古いデータベースを新しい形式に変換し、明確な理由なしに再び顧客に時間を費やしますが、将来のトラブルからそれらを救うことを約束します。 顧客は信じて苦しんだ。 その後、システムの機能を拡張し、以前のバージョンの問題を解決した新しいバージョンが続きました。 システムの新しいバージョンへの切り替えには15〜30分かかりました。これは非常に深刻な成果のように見えました。 しかし、それは長くはありませんでした。 機能の増加により、保存データが爆発的に増加しました。 これにおける最後の役割からはほど遠いのは、構成変更の相対的な安さです。 開発者は、将来を気にせずに完全に実装する最も簡単な方法を選択しました。



このアプローチの結果、大量のXMLコードと、後続の各バージョンへの移行中に必要な多数の変換が行われました。 この段階で、データベースをX.1状態からX.2状態（新しい機能が追加された）に転送するには、XMLデータベースに格納された構成表現で1つまたは複数の変換を実行する必要がありました。 このような変換を正常に実行した後にのみ、システムは動作を開始できます（更新されたコードは保存されたビューを逆シリアル化できます）。

この段階での問題

構成変換は、保存されたXMLファイルの一連の順次変換でした（XMLファイルは実際にはデータベースに保存されていました。初期段階ではデバイスと完全に互換性がありました）。 これらの変換の一部では、XML表現を文字列として扱い、通常の置換を使用しました。 他のプログラマーは、DOMツリーを使用するか、SAXパーサーを使用して「最適化された」オプションを作成することを好みました。 このような変換は独立しており、たとえば、リリースに多数の変換が存在する場合、1種類の構成に対して複数の変換を実行する必要があることを意味する可能性があります。完全にオプションの手順を数回繰り返します。



開発者にとっては、開発中に使用されるテストデータのサイズが非常に小さいため、この操作は短時間で完了しました。 実際のシステムによって保存される実際の構成のサイズは、数桁大きくなりました（100キロバイトから1〜2メガバイト、データベースの合計サイズは最大1〜2 GB）。 システムの新しいバージョンへの移行は、再びお客様にとって大きな問題になりました。







パラメーターの数、可能なオプションの数、クライアントの数などが増加するにつれて、格納されたXMLの変換に関与するコードの複雑さは絶えず増加していました。 アプリケーションロジックの観点からは、「コウモリ」の出現や単純な不正な構成につながるエラーが発生しました。 これらの問題のほとんどは隠されており、最も複雑で洗練された場合にのみ、最大かつ最も価値のある顧客の間で現れました。 開発中にデータベースの変換が手動で開始されたため、状況は複雑でした。 次に、次のパブリックバージョンのリリース前に、開発者の1人がデータベースを1つのアプリケーションに変換するためのすべてのコードを収集し、最終ビルドを作成しました。 膨大な数のオプションと非常に厳しい（いつものように）時間枠があるため、システムのすべてのニュアンスをテストすることはできませんでした。 クライアントは、バグ、データベースの損失（バックアップの処理を忘れた場合）、問題のあるブランチに到達した後のデータベースの損失などを見つけました。



グローバルハルマゲドンを長い間説明することは可能です。次のリリース後、開発者は数週間かけて顧客データベースの構成を手動で編集したとしか言えません。 全体的な状況が脅かされていました。

解決策

今回、明るい頭はしばらくの間彼らの支配を疑ったが、後戻りはなかった。 繰り返しになりますが、システムのグローバルな再設計は膨大な量の作業のため不可能でした。 長期にわたる会議が決定した後：

• ビルド間および開発中（テスト中）にアップグレードの概念を導入し、将来的に顧客が使用するメカニズムを使用する
• 構成を変換するコードを慎重に記述する
• 顧客データベースを使用してシステムをより集中的にテストする（テストコストが大幅に増加した）

効果

その効果は重要ではありませんでした。さらに、最終的に（最終的に）システムをアップグレードし、ライブタスクでシステムをテストしたのは顧客のメリットでした。

タイムライン：成熟したシステム

システムは引き続き販売され、ますます複雑になりました。 クライアントは問題に我慢し、サポートサービスはできる限りのことを行い、多くの場合、開発者に問題を渡します。なぜなら、彼らだけが手でベースを修正しようとするからです。 友好的な雰囲気の中で、さまざまなパッチが登場し、人々は特定の問題を防ぐ作業用の「呪文」を交換しました。 一言で言えば-人生は本格的だった。

この段階での問題

この段階で、タスクは、新しいバージョンに切り替える際の長い更新の問題を解決し、データベースの更新ロジックを合理化し、他のチームの作業を簡素化するように設定されました。



さらに、一部の（特にアクティブな）クライアントは、構成サイズを10メガバイトに、総データベースサイズを5ギガバイトに引き上げた後、非常に興味深い問題の新しいクラスに遭遇しました。 図を完成させるために、リーダーシップが以前のバージョンのデバイスと互換性のあるシステムを手に入れることを望むことができます。 常に、デバイスと制御システムは同期して開発されました。 例：System.1は構成をDevice.1に送信し、System.2はDevice.2に送信します。 タスクは、System。4が正しい構成をデバイスに送信する機会を提供するように設定されました。 ちなみに、違いはしばしば非常に重要でした。

解決策

構成変換ロジックを作成するために、特に各段階で行われた変更の正確性を検証できる特別なメカニズムを実装し、破損したベースの出現を防止しました。 製品全体をテストおよび検証するための自動化されたシステムが機能し、理論上のみ隠された、場合によっては起こりうる問題を明らかにしました。



構成をアーカイブ形式で保存し始め、サイズの問題と読み取りおよび変換速度の問題の両方を解決しました（プロセッサのパフォーマンスは向上していますが、ディスクサブシステムはひどいブレーキであったため、データベース（MySQL）のパフォーマンスは本当に向上しました）。 安定したデバッグされた更新メカニズムを使用して、逆変換メカニズムが実装され、異なるバージョンのデバイスをサポートできるようになりました。 この場合、自動テストも使用されました。 開発者の生活は、とりわけ、制御システムが送信したものを表示するだけでなく、受信した構成をチェックして潜在的なエラーを示すユニバーサルデバイスエミュレーターによって大幅に簡素化されました。







ガベージはすべてのクライアントのデータベースから削除された後、サイズが一桁小さくなり、新しいバージョンのインストール時間が大幅に短縮されました。 それにもかかわらず、明らかな理由で、非常に初期の段階で巧妙かつ非常に慎重に設計されたすべての問題を解決することはできませんでした。

おわりに

作者はこのプロジェクトをかなり貧しい状態で受け取りました。 プロジェクトと一緒に、数百のバグ、実際のクライアント、および下位互換性を備えたシステムに対するひどい要求や新しい障害のあるアジャイルへのファーム全体の適応など、追加機能に対する多くの要求が寄せられました。 ところで、長い間存在していた大規模プロジェクトの継続的統合の実装と、各コミット後にチェックできるすべてのチェックは、別個の非常に興味深いトピックです。 彼らは優れたチームと無限の楽観主義のおかげで、タスクに対処することができました。 多くのバグが修正されました：







開発プロセスは非常に熱心でした。







2つのシステムからの実際のクライアントは、費用のかかるメンテナンスを必要とせず、強制的に非アクティブな時間を最小限に抑える最も安定した便利なオプションを選択することに注意してください。 サービス停止を必要とする21世紀のシステムを開発することはやや奇妙です。 数時間から1日まで「嘘をつく」システムを開発することは、少なくとも愚かです。



次の記事（機会があれば）で、著者はゼロから作成され、この記事で言及されたほとんどすべての問題がない別のシステムで作業することについて話します。 新しい設計により、開発とテストの時間が大幅に短縮され、数時間以内に更新されたアセンブリを提供できます。 当然、データベースはまだ使用されていますが、新しいバージョンにアップグレードする場合、追加の手順は必要ありません;すべてが透過的に、安定して、迅速に行われます。

ボーナス

XMLデータベースに格納されているドキュメントを更新する問題を解決するなど、XSLT変換を使用するオプションが検討されました。 このソリューションは魅力的で成功しているようで、いくつかの最適化手法を使用できました。 たとえば、いくつかの変換をコンベアの形で表すことができ、十分な数がある場合は、顕著なパフォーマンスの向上が得られます。 以下は、小規模の評価テストの結果です。 テスト1〜5は、処理されるデータのサイズが異なります。 結果を行動の指針や究極の真実として受け取らないでください。