データベースストレージによるファイルシステムの依存関係の解決
私はソフトウェアプロジェクトAを使用しています。このプロジェクトは、ファイルシステムに格納されたデータに大きく基づいているサードパーティソフトウェアBに対してAPI呼び出しを行います。また、これらのソフトウェアとファイルシステムは、別の場所にあるサーバーに配布されます。たとえば、ファイルシステムを使用せず、BLOBを格納するためにデータベースを使用する方法を考えていました。次のシナリオを想定します。
- AがBを呼び出す.
- Bには、ファイルシステム上にあるテンプレートファイルが必要です。
- ファイルシステムでテンプレートファイルにアクセスできる場合、Bは正常に処理されます。そうでない場合は、エラーを返します。
このシナリオでは、2つのオプションについて考えました。
- データベースを使用して、これらのテンプレートファイルのBLOBを格納します。次に、Aにデータベースからファイルを抽出させ、Bへの呼び出しが行われるたびにファイルシステムに保存します。呼び出しが戻った後、Aはデータベースのテンプレートファイルを更新し、ファイルシステムから削除します。このシナリオでは、データベースストレージを複製/配布するだけで十分です。
- ファイルシステムを使用して、すべての場所AおよびBへのレプリケーションを実行しています。実装する方が簡単ですが、クエリ、統計など、データベースストレージにあるすべての機能を失います。
私はこの問題の解決策を見つけようとしており、Oracleデータベースで [〜＃〜] dbfs [〜＃〜] に遭遇しました。外部アクセス用のファイルシステムインターフェイスを作成しているように見えますが、実際には、これらのファイルはリレーショナルデータベースに格納され、管理されています。理論的にはファイルシステムの問題は解決しますが、Oracleデータベースがないため、この製品をテスト/使用できません。他のオープンソースデータベースで類似の機能を探しましたが、成功しませんでした。多分私は正しく検索していないのかもしれませんし、私が気付いていないこのための正しい用語があるかもしれません。多くの人がおそらくある時点で直面している単純な問題のように思えます。
- 私はそれについて正しいですか？
- ファイルシステムに依存するアプリケーションを処理する上でのベストプラクティスは何ですか？
- このサードパーティソフトウェアがアクセスできるファイルシステムを維持しながら、データベースの利点を活用できる方法はありますか？
データベース内のファイルを処理するには、多くのトレードオフがあります。いくつかの実際的な制約により、データベースの製造元は、データベースファイル構造の外部にファイルを保存して、クライアントへのファイル転送を高速化する手段を提供しています。 OracleにはDBFS、MicrosoftにはFileStreams、FileTable、およびリモートBlob Store（RBS）があります。大まかなトレードオフは次のとおりです。
- データベースで管理されているファイルは、バックアップでも維持されます
- バックアップが簡単
- バックアップのサイズが悪い-特に、バックアップを特定の期間内にネットワーク経由で転送する必要がある場合
- ファイルがディスク上にある間、ファイルに元のファイル名が含まれることはほとんどありません
- ファイルに直接アクセスするサードパーティに依存することはできません
- いくつかのデータベースはめちゃくちゃ高価です（あなたを見るとOracle）
テンプレートの問題を処理するには、テンプレートファイルがdataかconfigurationかを決定する必要があります。違いは、問題の解決方法にあります。
テンプレートファイルをデータとして扱う
この仮定は基本的に、テンプレートをデータベース内の特定のレコードに関連付けます。これらは、データが処理されているときに適切にステージングし、その後クリーンアップして、他の処理に干渉しないようにする必要があります。この場合、サードパーティソフトウェアへのアクセスをBLOBストレージからテンプレートを取得するサービスでラップし、処理が完了したらクリーンアップすることをお勧めします。これにより、呼び出し側がテンプレートについて直接知る必要がないように、単一責任原則（SRP）が維持されます。
この場合、外部のBLOBストレージをお勧めします。
- クラウドでホストしている場合は、クラウドプロバイダー（AWS S3、Azure Blob Storage、GCP Cloud Storage）でblobストレージ機能を使用します
- オンプレミスでホストしている場合は、 min.io のようなものを使用して、クラウドblobストレージと同じインターフェイスでblobストレージをホストする分散手段を提供します
通常、管理されたblobストレージは、データベース内であっても、独自のホストされたソリューションよりもはるかに堅牢であり、作業がはるかに高速です。そのシナリオでは、バックアップについてあまり心配する必要はありません。 Min.ioではクラウドのようにblobストレージを操作できますが、デプロイメントを自分で管理する必要があります。つまり、Kubernetes（k8s）のようなオーケストレーションサービスを使用すると、非常に堅牢なデプロイメントを自分で維持できます。
テンプレートファイルを構成として扱う
このシナリオでは、テンプレートファイルはファイルシステムに存在する必要があるだけで、有効な展開の一部と見なされます。これは、コンテナーとオーケストレーション（k8s）が実際にそれを管理するための優れたオプションとなる場所です。コンテナは、必要に応じてサードパーティツールとすべてのテンプレートファイルを持つように構築されます。オーケストレーションサービスによってデプロイされたコンテナーの各インスタンスは、まったく同じように構成されます。
このアプローチは、デスクトップアプリケーションでも機能します。この場合、テンプレートファイルはインストーラの一部になります。