質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.04%

システムの統合について

受付中

回答 5

投稿

  • 評価
  • クリップ 4
  • VIEW 1,933

rgaruaru

score 24

現在、同じシステムが複数の別々のサイトとして稼働しています。

仕組みはapache+tomcat+postgresのwebサービスです。

この複数のサイトを1つのサイトに統合することになった場合に
複数のデータを同じDBにひとまとめにするとして、
問題の一つとしてログテーブルのプライマリーキー(連番)が重複してしまうことが考えられます

プライマリーキーが他のテーブルのカラムにも紐づいたりして、作業量としてかなり重く、
データベース構成も複雑なためリスクの高い対応になってしまいます。

そこで、既存のテーブル構成をあまり変えずに、データを統合するいい方法はないでしょうか。
  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 5

+1

既存の同一システム複数サービスをマルチテナント対応化の場合には会社コードはPKへ付加します。
マルチテナントではなく単純統合でしたら工数の範囲内で行うしかないと思います。

単純例)
ログテーブルのPKへサーバIDを追加。
統合前に各DBサーバのログテーブルのPKへサーバIDをセット。
統合DBへ取り込み。
統合後のサーバIDを新規に採番。
など。

いずれにせよ改修範囲の調査も必要になりますし、ログテーブルのデータから業務データの参照有無もあると思います。
運用向けのログと業務データのログでは扱いも変わってくると思います。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+1

PostgreSQLなら、複数のデータベースを1つのPostgreSQLサーバで持つことが出来ますので、ひとまずは、それで纏めてみては如何でしょうか?
もしくは、データベース分けをするとアプリケーションから、複数のデータベースに跨ってアクセスするのが大変という事でありましたら、スキーマという単位で分離することが出来ます。
ただ、スキーマ化すると、DBへのアクセスするテーブル名にスキーマを付けなければならないなど、アプリケーション側の改修が必要になります。

スキーマを使用する理由はいくつかあります。
1 つのデータベースを多数のユーザが互いに干渉することなく使用できるようにするため。
管理しやすくなるよう、データベースオブジェクトを論理グループに編成するため。
サードパーティーのアプリケーションを別々のスキーマに入れることにより、他のオブジェクトの名前と競合しないようにするため。
@日本 PostgreSQL ユーザ会 ドキュメントより抜粋

1つの箱にいれるが、データベースを分離したまま(アプリは各々のDBにつなぐ際は別のコネクションを張る)とし、アプリの回収を接続先の変更に留めるか、スキーマを導入してアプリからDBへは1接続でスキーマ間のテーブルも操作できるようにする代わりに、アプリにスキーマを追加する回収を行うかといったトレードオフがあります。

Oracleでいう、データベース分け、インスタンス分け、スキーマ分けに相当するトレードオフがあります。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+1

リプレイスではなく統合ということですか?
自分なら結構泥臭いことをやるかもしれません・・・。

安定稼働しているシステムならば、既存のテーブル構成は一切変えるべきでないと思います。
またサービスが停止する時間も考慮するとマイグレーションツールを作るとよいかもしれません。
吸収される側(統合元?)のサーバを運用しながらの段階的な統合も対応できますしね。

思いつく感じだとざっくりこんな感じです。
1.統合元のDBダンプを取得(pg_dump)
DISK領域が不足してるなど容量的な問題があれば必要なデータだけ吸い出しします。

2.統合先に一時DBを作りリストア(pg_restore)
マイグレーションツールで使用する領域になります。

3.一時DBからデータ変換して統合先のDBに統合(マイグレーションツールを動作)
ここでシーケンスなどの整合性や統合で必要になった業務的な変換を動作させます。
顧客のわがままが意外に出ると思いますので要件はテーブルごとにきっちりさせておきます。
自分なら自由度を求めてプロシージャではなくJava等で作ります。

4.移行元のデータと統合先のデータ差分を提示
データが統合出来ている担保です。

5.向き先を統合先に切替

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

0

Ken.sakanakanaさんの回答と同様にスキーマ分けして一つのデータベースに共存させるのが軽いのかなと思いました。

 スキーマの使用が好まれる理由はいくつかあります。
    1つのデータベースを多数のユーザが互いに干渉することなく使用できるようにするため。
    管理しやすくなるよう、データベースオブジェクトを論理グループに編成するため。
    サードパーティのアプリケーションを別々のスキーマに入れることにより、他のオブジェクトの名前と競合しないようにするため。 

スキーマは、ネストできないという点を除き、オペレーティングシステムのディレクトリと似ています。 

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

0

もう統合は終わってますでしょうか。
一応、以下、回答しますが、以前行った異なる3つのシステムの統合データ移行は大変でしたよ。
(全く触ったことがない移行元のシステムでしたし、
それなりのデータ量もあったため、かなりのリスクでしたが
性能面もデータ移行も問題なく成功しています。)

ちなみに、複数システムの統合でどんなシステムでも気を付けなければならないのは、
ご指摘の通り、主キーの重複です。
テーブル数が多いとの事なので影響も大きいかと思いますが、
参照側で頑張るより、データ移行で頑張ってしまった方が、後々楽かなとは思います。
(統合要件にもよりますが、記載している内容を見る限り)

1.まず、ベースとなる移行元のシステムを決めます。
2.そのシステムはそのまま新しいサーバーへ移行します。
※リスク管理(後から自由に更新できるようにするため)として、
各テーブルに2つの項目(元の主キーとどのシステムからの移行データか分かる項目)を
追加するのもアリです。
※統合要件があれば、この時に、細かい部分も対応します。
3.各テーブルの主キーに対して、MAX値を取得します。
4.他のシステムのデータに対して、3のMAXを「紐づく項目」も含めて、プラスした値を移行します。
※統合要件があれば、この時に、細かい部分も対応します。
5.統合するシステム数分、3と4を繰り返します。
6.必要に応じて、2.4.でできなかったデータ補正を行います。

システムにもよりますが、
重複データ問題(同じ顧客情報が存在)や
マスタデータ問題(同じテーブル構造でも、マスタデータの中身が異なる)等もありますね。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 90.04%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

同じタグがついた質問を見る