現在、同じシステムが複数の別々のサイトとして稼働しています。
仕組みはapache+tomcat+postgresのwebサービスです。
この複数のサイトを1つのサイトに統合することになった場合に
複数のデータを同じDBにひとまとめにするとして、
問題の一つとしてログテーブルのプライマリーキー(連番)が重複してしまうことが考えられます
プライマリーキーが他のテーブルのカラムにも紐づいたりして、作業量としてかなり重く、
データベース構成も複雑なためリスクの高い対応になってしまいます。
そこで、既存のテーブル構成をあまり変えずに、データを統合するいい方法はないでしょうか。
気になる質問をクリップする
クリップした質問は、後からいつでもMYページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
回答5件
0
リプレイスではなく統合ということですか?
自分なら結構泥臭いことをやるかもしれません・・・。
安定稼働しているシステムならば、既存のテーブル構成は一切変えるべきでないと思います。
またサービスが停止する時間も考慮するとマイグレーションツールを作るとよいかもしれません。
吸収される側(統合元?)のサーバを運用しながらの段階的な統合も対応できますしね。
思いつく感じだとざっくりこんな感じです。
1.統合元のDBダンプを取得(pg_dump)
DISK領域が不足してるなど容量的な問題があれば必要なデータだけ吸い出しします。
2.統合先に一時DBを作りリストア(pg_restore)
マイグレーションツールで使用する領域になります。
3.一時DBからデータ変換して統合先のDBに統合(マイグレーションツールを動作)
ここでシーケンスなどの整合性や統合で必要になった業務的な変換を動作させます。
顧客のわがままが意外に出ると思いますので要件はテーブルごとにきっちりさせておきます。
自分なら自由度を求めてプロシージャではなくJava等で作ります。
4.移行元のデータと統合先のデータ差分を提示
データが統合出来ている担保です。
5.向き先を統合先に切替
投稿2015/09/11 16:18
総合スコア206
0
PostgreSQLなら、複数のデータベースを1つのPostgreSQLサーバで持つことが出来ますので、ひとまずは、それで纏めてみては如何でしょうか?
もしくは、データベース分けをするとアプリケーションから、複数のデータベースに跨ってアクセスするのが大変という事でありましたら、スキーマという単位で分離することが出来ます。
ただ、スキーマ化すると、DBへのアクセスするテーブル名にスキーマを付けなければならないなど、アプリケーション側の改修が必要になります。
スキーマを使用する理由はいくつかあります。
1 つのデータベースを多数のユーザが互いに干渉することなく使用できるようにするため。
管理しやすくなるよう、データベースオブジェクトを論理グループに編成するため。
サードパーティーのアプリケーションを別々のスキーマに入れることにより、他のオブジェクトの名前と競合しないようにするため。
@日本 PostgreSQL ユーザ会 ドキュメントより抜粋
1つの箱にいれるが、データベースを分離したまま(アプリは各々のDBにつなぐ際は別のコネクションを張る)とし、アプリの回収を接続先の変更に留めるか、スキーマを導入してアプリからDBへは1接続でスキーマ間のテーブルも操作できるようにする代わりに、アプリにスキーマを追加する回収を行うかといったトレードオフがあります。
Oracleでいう、データベース分け、インスタンス分け、スキーマ分けに相当するトレードオフがあります。
投稿2015/09/11 13:46
総合スコア1768
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
0
既存の同一システム複数サービスをマルチテナント対応化の場合には会社コードはPKへ付加します。
マルチテナントではなく単純統合でしたら工数の範囲内で行うしかないと思います。
単純例)
ログテーブルのPKへサーバIDを追加。
統合前に各DBサーバのログテーブルのPKへサーバIDをセット。
統合DBへ取り込み。
統合後のサーバIDを新規に採番。
など。
いずれにせよ改修範囲の調査も必要になりますし、ログテーブルのデータから業務データの参照有無もあると思います。
運用向けのログと業務データのログでは扱いも変わってくると思います。
投稿2015/09/11 11:24
総合スコア241
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
0
もう統合は終わってますでしょうか。
一応、以下、回答しますが、以前行った異なる3つのシステムの統合データ移行は大変でしたよ。
(全く触ったことがない移行元のシステムでしたし、
それなりのデータ量もあったため、かなりのリスクでしたが
性能面もデータ移行も問題なく成功しています。)
ちなみに、複数システムの統合でどんなシステムでも気を付けなければならないのは、
ご指摘の通り、主キーの重複です。
テーブル数が多いとの事なので影響も大きいかと思いますが、
参照側で頑張るより、データ移行で頑張ってしまった方が、後々楽かなとは思います。
(統合要件にもよりますが、記載している内容を見る限り)
1.まず、ベースとなる移行元のシステムを決めます。
2.そのシステムはそのまま新しいサーバーへ移行します。
※リスク管理(後から自由に更新できるようにするため)として、
各テーブルに2つの項目(元の主キーとどのシステムからの移行データか分かる項目)を
追加するのもアリです。
※統合要件があれば、この時に、細かい部分も対応します。
3.各テーブルの主キーに対して、MAX値を取得します。
4.他のシステムのデータに対して、3のMAXを「紐づく項目」も含めて、プラスした値を移行します。
※統合要件があれば、この時に、細かい部分も対応します。
5.統合するシステム数分、3と4を繰り返します。
6.必要に応じて、2.4.でできなかったデータ補正を行います。
システムにもよりますが、
重複データ問題(同じ顧客情報が存在)や
マスタデータ問題(同じテーブル構造でも、マスタデータの中身が異なる)等もありますね。
投稿2016/08/26 01:07
総合スコア760
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
0
Ken.sakanakanaさんの回答と同様にスキーマ分けして一つのデータベースに共存させるのが軽いのかなと思いました。
スキーマの使用が好まれる理由はいくつかあります。
1つのデータベースを多数のユーザが互いに干渉することなく使用できるようにするため。
管理しやすくなるよう、データベースオブジェクトを論理グループに編成するため。
サードパーティのアプリケーションを別々のスキーマに入れることにより、他のオブジェクトの名前と競合しないようにするため。スキーマは、ネストできないという点を除き、オペレーティングシステムのディレクトリと似ています。
投稿2015/09/12 04:04
退会済みユーザー
総合スコア0
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
あなたの回答
tips
太字
斜体
打ち消し線
見出し
引用テキストの挿入
コードの挿入
リンクの挿入
リストの挿入
番号リストの挿入
表の挿入
水平線の挿入
プレビュー
質問の解決につながる回答をしましょう。 サンプルコードなど、より具体的な説明があると質問者の理解の助けになります。 また、読む側のことを考えた、分かりやすい文章を心がけましょう。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。