アプリケーションのデータ モデルを異なるデータベース システムに分割することは理にかなっていますか? たとえば、アプリケーションはすべてのユーザー データと関係をグラフ データベース (関係の格納に最適) に格納し、その他のデータは CouchDB や MongoDB などのドキュメント データベースに格納します。これには、ユーザー グラフ データベースがドキュメント データベース内の一意の ID を参照する必要があり、その逆も同様です。
これにより、データ モデルとアプリケーションが複雑になりすぎていませんか? それとも、アプリケーションをスケーリングするために、両方のタイプのデータベース システムを最大限に活用していますか?
それは間違いなく理にかなっており、アプリケーションの要件に完全に依存しています。他のデータベース システムが得意とする分野に使用できる場合。
全文検索を例にとってみましょう。もちろん、MySql のようなリレーショナル データベースを使用すると、多かれ少なかれ複雑な全文検索を行うことができます。しかし、Lucene/Solr などのようなシステムがあり、そのようなものに最適化されており、何百万ものドキュメントを高速に検索できます。したがって、これらのシステムを特別なタスク (ここでは気の利いた全文検索を行う) に使用できます。次に、識別子を返し、RDBMS からリレーショナル構造化データをロードすることもできます。
またはCouchDB。私はいくつかのプロジェクトでcouchDBをキャッシングシステムとして使用しています。リレーショナル データベースとの組み合わせ。もちろん、一貫性を気にする必要がありますが、努力する価値は間違いなくあります。これにより、プロジェクトのパフォーマンスが大幅に向上し、たとえばサーバーの負荷が 2 から 0.2 に減少しました。:)
このようなものは、たとえばクロスストア永続性と呼ばれます。あなたが言及したように、特定のデータをリレーショナル データベースに保存し、ソーシャル リレーションシップをグラフデータベースに保存し、ユーザー生成データ (ドキュメント) をドキュメント データベースに保存し、ユーザーが提供するマルチメディア ファイル (写真、オーディオ、ビデオ) を S3 などのブロブ ストアに保存します。 .
これは主にユースケースを見て、必要な場所から各ストアの「プライマリ」キーまたはインデックス キーにアクセスできるようにすることです (前後に)。ドメインまたは dao レイヤーで実際のルックアップをカプセル化できます。
Spring Dataプロジェクトのような一部のフレームワークは、ほとんどの場合 JPA を別の NOSQL データストアと統合して、すぐに使用できる最初の種類のクロスストア永続性を提供します。たとえば、Spring Data Graphを使用すると、エンティティを JPA に保存し、ソーシャル グラフまたはその他の高度に相互接続されたデータを二次的な関心事として追加し、典型的なトラバーサルおよびその他のグラフ操作 (ランキング、提案など) に graphdb を活用できます。
これの別の用語は、多言語持続性です。
質問に対する2つの反対の立場は次のとおりです。
プロ: 「それとは反対に、私は多言語永続化の大ファンです。これは単に、ユースケースごとに適切なストレージ バックエンドを使用することを意味します。たとえば、ファイル ストレージ、SQL、グラフ データベース、データ ウェア ハウス、インメモリ データベース、ネットワーク キャッシュ、NoSQL。現在、ほとんどの場合、ファイルと SQL データベースの 2 つのストレージが使用されています。どちらもすべてのユースケースに最適というわけではありません。」
短所: 「私が多言語永続性の支持者であると言う必要はないと思います。また、Unix ツールの哲学を信じています。しかし、システムにコンポーネントを追加する際、そのようなシステムの複雑さは「また、運用コストも増加します (注意: Twitter が Cassandra を使用し始めた理由を覚えていますか?)。システムのコンポーネントが増えるほど、システム全体などの重要な側面を把握するために、より多くの注意と注意を払う必要があることは言うまでもありません。可用性、レイテンシ、スループット、および一貫性です。」