94193


サーバー上にデプロイされたWEBアプリケーション（仮にSpringBootベース）が  
データソースとして Postgres DB と MySQL DB と言った  
異なるベンダーが提供する2種類のデータベースを参照するアーキテクチャは  
一般的に問題ない構成なのでしょうか。

同一ベンダーであれば、複数DBを参照するケースは  
検索する中で多々見かけましたが、  
異種ベンダーとなるとあまり見かけることがありません。

ORMにHibernateを使用する場合、  
それぞれのSessionFactoryを作成すれば実現可能であるため  
こういった構成も問題ないように思えます。

浅学のため大変恐縮ではございますが、  
参考までに、掲題の構成を採用しているシステムや、  
是非について書かれている記事,書籍等あれば教えていただけないでしょうか。


CC BY-SA 4.0
2023-03-12T13:16:37.540
94142
2023-03-16T09:26:49.163
2023-03-12T14:08:54.320
57495
57495
question
java mysql postgresql database hibernate
1つのWEBアプリが複数ベンダーのDBを参照することの是非


永続オブジェクトをリレーショナルデータベース(RDB)に、セッション情報やキャッシュなど消えても良いデータはオンメモリなキーバリューデータベース(キーバリューストア、KVS)にというのはよくある構成かと思います。扱うデータの特性に応じて、
**特性が異なるデータベース(DB)を組み合わせる** というのはそれほど不思議とは思いません。

たぶん、聞きたいのは、ほぼ同じような特性のDBを複数種類使う是非なのかと思います。例えば、MariaDBとMySQLはほぼほぼ同じRDBですが、データをそれぞれのDBに分けて扱う理由があるのかどうかです。

そもそも、DBを分けると言うことがあるのかです。最初に述べたとおり、必要な特性が異なるデータであれば、特性毎に扱うDBを分ける意味もありますが、ほぼ同じ特性のデータを別々のDBを分ける意味があるのでしょうか？ないですよね？全く関連が無いデータ同士は違うDBに入れるべきとか、聞いたことが無いです。そもそも、全く関連がないデータ同士を扱うなんて、一つのアプリケーションとして、何か間違っているような気もします。

それでも、いくつかのフレームワークでは複数のDBをサポートしています。これは一体、どういう用途に使うのでしょうか？たぶんですが「既存の別のシステムのDBに接続するため」だと私は思っています。例えば、すでに運用中のシステムAがあるとして、それと連携するシステムBを作るとしましょう。理想としては、システムAが連携用のAPIを提供して、それを利用すべきかもしれませんが、工数等の問題から、システムAのDBを直接参照することになったとします。ただ、システムA自体は変更したくないので、システムBが独自に持つデータは別のDBで扱うとなります。こうなると、システムBでは、システムAのDBとシステムB独自のデータがあるDBの二つを参照することになります。システムAのDBは既に運用中なので変更できません。ライセンスとか、費用とか、サーバーの制限とか、パフォーマンスとか、サポートの有無とか、上司の趣味とか、プログラマーのこだわりとかで、システムBのDBは、別ベンダーのDBになるというシチュエーションはあり得るかと思います。

何を言いたいかというと、そもそも、DBを分ける時点で、なにか退っ引きならない理由があり、それによっては、ベンダーが異なることも避けることはできないのでは無いのかと言うことです。問題があるかどうか言う前に「
**やるしかない**
」という状態です。もちろん、検証段階でうまくいかないことが発覚することもあるでしょう。そうであれば、計画の段階からやり直し(それこそ既存のシステムから作り直しなど)はあるかも知れません。逆に、同じベンダーが提供するDB同士、例えば、Orcale
Database、MySQL、Berkeley
DBはいずれもオラクル社が提供していますが、それらを組み合わせて作ったシステムでも問題がでてくるかも知れません。もし、そういうことが心配というのであれば、より具体的な構成を挙げた上で問題点があるか検証する必要があるかと思います。


CC BY-SA 4.0
2023-03-15T12:01:17.337
94193
2023-03-16T09:26:49.163
2023-03-16T09:26:49.163
7347
7347
94142
answer