頭痛のないデータスキーマの移行：DDLスクリプトのべき等性と収束

SQL言語とリレーショナルデータベースは、40年以上にわたって使用されてきました。 この間、SQL標準は多くの改訂を経て、明らかに、開発プロセスはそこで止まりません。 リレーショナルデータベースは何十年もの間、データウェアハウスとして存続してきましたが、今日では支配的であり、ごく最近では代替アプローチが少しずつ普及しています。

SQLは、データ抽出に関してはほぼ全能です。 （誰もが知っているわけではありませんが、1つのSQLクエリで、 Mandelbrotのセットをグラフィカルに構築できます）。 しかし、1つの問題が引き続き概念的に解決されていません。それは、データスキーマの移行の問題です。



ITのキャリアのさまざまな段階で、作業中のデータベースの構造を制御し、ソフトウェアの新しいバージョンが展開されるたびに更新することは非常に困難に直面したと思います。 すでに修正された後に戻るバグ、「フィールドがテーブルにない」などのエラー、「ストレージを修正し、それを消去しました！」-これをすべて知っていますか？

この問題の深刻度は、ソースコードのバージョン管理の問題を根本的に解決する方法とは対照的に特に明確です。GitやSubversionのようなシステムでは、多くの開発者のコ​​ラボレーションを制御でき、単一の変更を失うことなく、「すべての動きを記録」し、チームワークの結果を収集できます一緒に。 しかし、この良い状況は、バージョン管理システムの適用可能性が終わるところで終わります。 データスキームの構造について説明する場合、その開発のためのバージョン管理システムの使用は依然として非常に限られています。

ベースで構造を変更するのはとても簡単で魅力的です！ そのような変更が文書化されていない場合、将来的にシステムを開発する必要があり、大惨事が近づいています。 しかし、データベースの構造を変更するためにすべてのステップを文書化する必要性を認識して、これを行うことは非常に不便であり、データスキームを定義するDDL言語はこれに役立たないという結論に達します。 たとえば、テーブルにフィールドを追加するには、ALTER TABLE ADDコマンドが必要です。 この式を1回だけ実行し、フィールドがまだテーブルに存在しない瞬間に実行することは理にかなっていますが、すでに必要です。 他のときにこのスクリプトを実行すると、スクリプト自体の実行でエラーが発生するか、さらに悪いことに、データベース構造の状態が不適切になります。

開発者によって行われたすべての変更を単一の結果に集約し、その実装を制御する方法は？

アプローチ＃1：変更スクリプトの蓄積

追加のツールを使用せずに手動でこの問題を解決する実用的なソリューションは、プロジェクトコードベースに番号付きスクリプトを使用してフォルダーを作成し、データベース構造を変更し、それらをこのフォルダーに蓄積し、開発プロジェクトの参加者に最も厳しい規律を導入することです。 次のスクリプトファイルでの変更を記録するプロセスと、データベースへの変更を「ローリング」するプロセスを形式化する必要があります。

より高度で便利なソリューションは、 Liquibaseなどのシステムを使用することです。 Liquibaseは、最後に実行されたデータ構造の変更回数を制御し、スクリプトが構造変更スクリプトを線形形式で1回だけ実行するようにします。 これはすでに多くのことであり、Liquibaseを使用することで、データスキームの開発と更新で発生する混乱を確実に排除できます。

それでも、変更スクリプトの蓄積に基づいたLiquibaseやその他のツールを使用しても、アプリケーションのソフトウェアソースコードを変更するのは簡単で技術的であるので、データスキーマを変更するタスクは簡単で技術的ではありません。

まず、変更スクリプトが蓄積されます。 十分に長時間実行されるプロジェクトは、これらのスクリプトから大きな「テール」を引き出します。ほとんどのスクリプトは、かなり前に行われた変更が含まれているため、関連性を失います。 「テール」全体を保存することは無意味です。なぜなら、ログのある場所での変更は、別の場所での変更の結果をキャンセルする可能性があるためです。ログe。 大きくなりすぎたログを見ると、ベースの構造に関する現在の理解を理解することができなくなります。 また、たとえば完全に新しいプロジェクトでデータベース構造をゼロから再現したい場合は、スクリプトを実行するプロセスで進化的開発の全パスを繰り返す必要があります！

第二に、このアプローチでは、変更セットを介してデータベース構造を変更する複雑さと、プログラムのソースコードを変更する単純さとの間に大きな違いがあります。

お気に入りのプログラミング言語でクラスを記述するコードがあり、システムを改善する過程で、1つのメソッドをクラスに追加し、他のメソッドを削除する必要があるとします。 何してるの？ クラスのソースコードを取得して変更し、バージョン管理システムにコミットしますか？ 次の形式のコマンドを使用して変更セットを作成する必要はありません。

alter class drop method foo;
alter class add method bar(…) {
…
}

データスキーマ構造に対してこれを行う必要があるのはなぜですか？

もちろん、その理由は、構造を変更するときに何かをする必要があるデータもデータベースに含まれているからです。 この問題について詳しく説明しますが、まず、問題を解決するための別の可能なアプローチを見てみましょう。

アプローチ2：i等DDLスクリプト

サーバーの構成時に、データベーススキーマの移行時に発生する問題と同様の問題が長い間発生していました。

サーバーへの必要なソフトウェアのインストールを自動化し、構成の更新を提供する方法は？ 空の仮想マシンで実行されると、その上にすべてをインストールして構成するシェルスクリプトを作成できます。 これは、データベース構造を作成するスクリプト（CREATE TABLE ...スクリプト）に類似していますが、問題は、空のマシン上でのみ1回しか実行できないことです。 マシンがすでに展開されて実行されており、システムの新しい仕様に従って動作する場合、たとえば、別のバージョンのJavaが必要になります。ここに投稿するにはどうすればよいですか。古いバージョンを破棄して新しいバージョンのJavaをインストールする変更スクリプトを追加しますか？ さて、空のマシンで構成を再現する必要がある場合-過去に行ったすべてのステップを実行するには何が必要ですか？

この場合に発生する主な重要な質問：インフラストラクチャ/データスキームを、ソースコードを編集するのと同じくらい簡単に編集できますか？その説明を直接変更してバージョン管理に書き込むことで可能ですか？

サーバー構成の問題に対するこれらの質問に対する答えは、 Infastructure as Code（IaC）の原則と、構成管理システムとして知られるシステムのクラス全体の出現でした。Ansible、Chef、Puppetなどです。 dem等性（べき等性）および収束（収束、収束）。 これらの用語は両方とも数学から借用しています。 問題に適用される不必要な形式を破棄する場合、これらの用語は次のことを示します。

1. べき等および収束スクリプトは、オブジェクトに対して実行する必要があるアクションではなく 、オブジェクトを取り込む必要がある状態を記述します。
2. べき等性とは、そのようなスクリプトが正常に実行され、オブジェクトがすでに目的の状態にある場合、スクリプトの繰り返し実行は何も変更せず、何ももたらさないことを意味します。 たとえば、必要なパッケージのインストールを宣言するシステムの構成管理スクリプトについて話している場合、これらのパッケージが既にインストールされていると、スクリプトは再起動時に操作を実行しません。
3. 収束とは、スクリプトが実行または失敗しなかった場合、再度実行したときに、システムが目的の状態になる傾向があることを意味します。 たとえば、パッケージのダウンロード時にネットワークが消失したためにパッケージの1つのインストールが失敗した場合、スクリプトを再実行すると、不足しているパッケージがインストールされます（前回インストールされたパッケージはそのまま残ります）。

これらの原則は一般的なものであり、マシンのソフトウェア構成だけに適用されるわけではありません。 たとえば、Terraformシステムを使用すると、必要な仮想サーバーのセットとそのハードウェア構成をコードの形式で指定し、クラウド内の仮想マシン群を制御できます。

これらの原則がデータスキーマの制御にどのように役立つかを理解するには、上記ですでに十分だと思います。 データベースがキーワード「CONVERGE」をサポートしており、次のスクリプトがあるとします。

CONVERGE TABLE OrderHeader(
id VARCHAR(30) NOT NULL,
date DATETIME DEFAULT GETDATE(),
customer_id VARCHAR(30),
customer_name VARCHAR(100),
CONSTRAINT Pk_OrderHeader PRIMARY KEY (id)
);

CONVERGEキーワードは、「テーブルを目的の構造にする」と解釈する必要があります。 つまり、テーブルがない場合は、テーブルを作成し、テーブルがある場合は、その中にあるフィールド、タイプ、インデックス、外部キー、デフォルト値などを確認し、この中の何かを変更する必要があるかどうかを確認します適切な種類にそれをもたらすためのテーブル。

データベースがそのようなキーワードをサポートできる場合、つまり、データベースに対してべき等および収束DDLスクリプトを記述できる場合、この記事を書く必要はありません。 全員がバージョン管理システムに「CONVERGE TABLE」スクリプトを保持して、現在のデータスキームを記述し、ソースコードを操作するのと同じようにそれらを操作します。テーブルに新しいフィールドが必要です。インデックスのフィールド-編集。 （あなたの質問を聞きます：データの移行についてはどうですか-しかし、忍耐、私はすぐにこれに進みます。）

残念ながら、リレーショナルデータベースの世界では、DDLの真のべき等性をサポートする動きはありません。 これまでデータベースでDDLコードのべき等性に向けて行われたことはすべて、CREATE IF NOT EXISTS構造のサポートですが、これは率直に言って、かなり弱い試みです。 もちろん、CREATE TABLE IF NOT EXISTSスクリプトは、外部的にはべき等として動作します（テーブルが既に作成されている場合はエラーになりません）が、収束としては動作しません（既に作成されたテーブルの構造を変更しません）。

外部ツールに依存する必要があります。 たとえば、 Celestaシステムでは、べき等および収束DDLを使用できます。 開発者と開発ツール（ERダイアグラムのビジュアルエディターなど）が通常のDDLスクリプトのように見えるように、CelestaキーワードはCREATEを使用しますが、Celestaでは仮想CONVERGEの意味を持ちます。 Celestaは、起動するたびに、接続されている現在のデータベース構造とCelestaSQL DDLスクリプトとして記述されている目的の構造を比較し、必要に応じて必要最小限のCREATE / ALTER / DROPコマンドを実行します。 現在サポートされているデータベースは、PostgreSQL、Oracle、MS SQL Server、およびH2の4種類です（後者は、主に単体テスト組織のニーズに対応しています）。

データベース構造を定義するi等スクリプトは、単純に取得して直線的に実行することはできません。 ご存じのように、データベース内の一部のオブジェクトは他のオブジェクトに依存しています-たとえば、テーブルは外部キーを介して相互に参照し、ビューとインデックスはテーブルに依存します。したがって、一連のオブジェクトを作成/再構築する前に、ランク付けする必要があります相互依存関係の順序：形式的に言えば、依存関係グラフのトポロジカルソートを実行し、何も依存していないオブジェクトから開始してオブジェクトを処理します。 接続するテーブルを変更した後で外部キーを後で復元するために、外部キーをリセットする必要があることがよくあります。 この問題はCelestaで解決されたため、ほとんどの場合、問題なくアップグレードできます。

データ移行

では、データ変換についてはどうでしょうか。単純なALTERだけでは十分ではないからです。 たとえば、空でないテーブルにNOT NULLフィールドを追加し、DEFAULT値を提供しない場合はどうなりますか？ 実際、そのようなフィールドにデータが事前に入力されていない場合、データベースはALTER TABLE ADDスクリプトの実行を許可しません。 そして、外部キーを追加したいが、テーブル内のすべてのデータが制限を満たしているわけではない場合 また、たとえば、アプリケーションロジックが変更され、ある列から別の列にデータを転送したい場合はどうでしょうか。

これらの質問はすべて正しいのですが、まず、アプリケーションの開発中にデータベースで行うほとんどの変更について、移行は必要なく、単純なALTERスクリプトで十分であることに注意してください。 新しいテーブルまたは新しい列をテーブルに追加するだけの場合（NULLABLEまたはDEFAULT値を使用）、データを移行する必要はありません。 インデックスを追加または再構築する場合、データを移行する必要はありません。 ビューのクエリが変更された場合、何も移行する必要はありません。 Celestaシステムを使用する慣行は、開発者による変更の大部分がこのタイプのものであることを示しています。

データの移行が本当に必要な場合は、はい。1回限りの移行スクリプトを作成して実行する必要があります。 このスクリプトを「長期にわたって」保存する必要がないというだけであり、デバッグとアプリケーションのストーリーは、変更ログに基づいて構築されたシステムよりもはるかに簡単です。

空でないテーブルに外部キーを追加する場合を考えてみましょう。そのようなキーを満たすレコードはすべてありません。 アップグレードプロセス中に、CelestaはALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEYコマンドを使用してこのようなキーを作成しようとします。 彼女が成功した場合-うまくいけば-システムは停止し、Celestaは何らかの理由でそのようなオブジェクトをデータベースからのメッセージで更新できなかったことを報告します。

changelog-systemsの場合、中間状態で半分完了して修正されたチェンジセットほど悪いものはありません。この状況では、システムは2つのリビジョンの「中間」にあり、手動でしか解決できません。 多くのデータベースでロールバックDDLトランザクションがサポートされていないため、さらに困難が生じます。

「変更ログ」システムとは異なり、「収束」システムの場合、最後まで完了していない更新は問題になりません。ALTERコマンドを生成するために、システムはデータベースの現在の実際の状態を目的の状態と比較し、ある試みで、彼女は別の試みで終わろうとします。

更新を自動的に実行できない状況に直面すると（繰り返しますが、この状況は非常にまれです）、1回限りのスクリプトを作成できます。 参照テーブルに必要なデータを入力し、それによりCelestaが更新を自動的に実行するための条件を作成するとします。 このスクリプトは、実稼働ベースの新しいコピーでデバッグし、実稼働ベースで実行してからCelesta更新を生成できます。

結局、スクリプトは二度と必要ないので、 単に捨てることができます ！ 結局のところ、作業ベースはすでに構造上必要な状態にあり、新しいベースを最初から作成する予定がある場合は、ベースをすべての方法で進行させて、開発プロセスでその構造を完成させる必要はありません。

おそらく、このアプローチは、構造を変更するたびにデータの移行に必要な手順を検討し、そのような手順を変更セットに埋め込む変更ログシステムを使用するよりも信頼性が低いと思われます。 しかし、考えてみると、この点に関するchangelogシステムの信頼性は想像上のものであることが明らかになります。 ご存知のように、潜在的なエラーのないプログラムはありません;このルールはデータ変更スクリプトにも適用されます。 変更セットスクリプトが既存のデータセットでデバッグされ、正しい動作を示したという事実は、データに対してエラーなしで実行されることを100％確実に保証するものではありません。 dem等DDLを使用する場合、少なくともデータ変更スクリプトを変更不可として宣言しない場合、監査属性はチェックサムによって保護されます。 エラーが発生した場合、システムを目的の構造に縮小するまで、更新をいつでも繰り返すことができます。 Celestaはデータを含む列とテーブルのドロップを自動的に実行せず、この操作は手動で実行されるため、データは失われません。

* * *

残念ながら、CelestaSQLの範囲はCelesta システムと組み合わせて使用​​してビジネスロジックコードを作成することに限定されており、 （もう更新はありません！）したがって、今日のプロジェクトでは、おそらくLiquibaseをお勧めします。 ただし、Celestaはオープンプロジェクトであり、その開発の可能な方向の1つは、汎用のデータベース構造移行ツールの作成です。

個人的には、データベース開発者がべき等性とDDLコンバージェンスの実際のサポートを実装することを希望します。

UPD：2018年初頭から、CelestaSQLを使用して、 2bassシステムを使用して任意のデータベースをべき等に更新できます。