マイクロサービスごとの複数のデータベース
私たちのビジネスエンティティのすべての重要なトランザクションフィールドが高度に構造化され、リレーショナルであるシナリオがあります。これらの重要なフィールドのデータサイズも非常に小さいです。ただし、非常にまれにしか更新されない（例外的な場合のみ）各エンティティに関連付けられた未加工のJSONがあります。ただし、ほとんどの読み取りAPIでは、未加工のJSONを含むすべてのデータが必要です。
これを考慮して、MySqlをデータストアとして選択しました。データバッグ（生のJSON）は、各エンティティのblobとして保存されています。これは機能上の問題を引き起こしません。ただし、データサイズは急速に増加しており、JSONブロブの寄与は約70％です。
そのため、生データをNoSqlストアに移動し、MySqlの主キーをNoSqlの参照キーとして使用することを検討しています（コードによって適用されます）。
ただし、これは分散トランザクションを導入するため（両方のDB間で一貫性を確保する必要があるため）、どういうわけか私にはアンチパターンとして表示されます。これは、NoSqlへの書き込みがメッセージキューを通過するSagaパターンを使用して回避できます。しかし、読み取りには強い一貫性が必要なので、これに依存することはできません。さらに、メンテナンス/監視の問題を引き起こす可能性のある複雑さがさらに導入されます。
完全にNoSqlストアに移動することを選択できますが、メインドメインエンティティは実際にはそれを必要とせず、リレーショナルデータ構造の良さを失います。サイズに基づいてMySqlをシャーディングできますが、これによりいくつかのクロスシャードクエリが必要になります。
これに対処するための一般的なパターンはありますか？「サービスごとの複数のデータベース」はパターンですか、それともアンチパターンですか？
2番目のデータベースを追加しても問題は解決しません。それはあなたが特定した、そしておそらくもっと多くの新しい問題の束をあなたに与えます。あなたがする必要があるのはあなたのデータをよりよく構造化することです。真に構造化されていないデータはまれであり、ほとんどのアプリケーションはデータを構造化された方法で提示する方法であり、その構造をデータベースに正しく反映することは難しい場合があります。データの構造は、許容できるよりも多くあり、データベースにできるだけ多く移動すると、パフォーマンスが向上します。少なくとも、大きなJSONブロブを複数のブロブに分割すると、いくつかの利点が得られます。データをより適切に分析して構造を見つけるための最初のステップとして適しています。考慮すべきもう1つのことは、MYSQLでJSONデータ型を使用することです。これにより、データベースがストレージとパフォーマンスをより最適化し、データベースレベルでより多くのフィルタリングを実行できるようになるため、最終的にはコード化されたアプローチよりもパフォーマンスの高いソリューションを実現できます。
複数のデータベースまたは分散データベースは、最後の手段のソリューションです。これらは、追加のハードウェア、およびすべての同期と維持を維持するために必要なボディの両方で莫大なコストになります。このルートを進むと、すべてがより困難になり、その困難を正当化するには多くの時間がかかります。
JSON部分だけでなく、データベース全体に水平スケーリングを実装する必要があります。 JSON部分を抽出すると、購入するスペースが70％増えるだけですonceなので、リレーショナルデータを使用すると、すぐに同じ問題が再び発生します。
JSONの部分は、アプリケーションにとって基本的に「ブラックボックス」のように見えるので、リレーショナルデータベースに格納してもそれほど大きなメリットはありません-butを使用しても何のメリットもありません別のデータベースシステム。また、2つのデータベースシステムを使用することにより、複雑さとメンテナンスコストが増大します。
データベースエンジンによっては、垂直パーティション分割と水平パーティション分割（シャーディング）を組み合わせることができるため、リレーショナルデータとは別にJSONブロブで列をシャーディングします。
「パターン」と「アンチパターン」については、それを考えるのは間違っています。確かに、同じサービスでリレーショナルデータベースとNoSqlシステムの両方を使用することが理にかなっているシナリオがあります。しかし、あなたの場合、それはあなたに何の利益ももたらさず、あなたが抱えている問題を解決しません。
私は、2つのDBを持つことはそれよりも問題が多いという考えに概ね同意する傾向がありますが、状況に応じて検討する価値があります。また、JSONをgzip圧縮することも検討できます。ドキュメントのサイズによっては、これによりスペースを大幅に節約できます。これの良い点は、レスポンスにMIMEタイプを設定して、サービスからgzipされた生データを返すことができることです。
しかし、MySQLの容量を拡張する簡単な方法がないと仮定すると、全体を水平スケーリングDBに移動するか、LOBを移動する必要があります。コアデータにリレーショナル機能を使用しているため、前者は複雑になります。たぶんそうする方法はあるでしょうが、それは多くの課題を生み出し、やらなければならない仕事をすることになります。
ドキュメントストアを使用する際の主な障害は、一貫性が心配されているようです。これは、両方のDB間の整合性が本当に必要な場合の課題ですが、その要件を少し弱めることができる場合は実行可能です。これを実行できる方法としては、リレーショナルデータをコミットする前にJSONドキュメントを作成して確認する必要があります。さらに、JSONレコードを絶対に変更しないことが重要です。 JSONデータを書き込むことはできたが、リレーショナル部分が失敗した場合、ドキュメントストアに孤立したレコードが存在することになります。 NoSQLストアからの検索はリレーションクエリから返されたデータに基づいていると思いますので、これが（大きな）問題である明確な理由はありません。必要に応じて、ある種のクリーンアッププロセスを実装できます。
JacquesBは、スペースの使用に関して良い点を示しています。あなたが説明したようにすべてが当てはまる場合は、問題を後で遅れるまで遅らせるだけです。これを説明するには、長期的なストレージのニーズを把握する必要があります。すべてを1つのDBに永久に保持する必要がある場合は、すべてを水平方向にスケーリングするソリューションが必要です。日付などの意味のある方法でデータを分割できる場合は、さらに多くのオプションがあるかもしれません。