Solr検索インデックスをデータベースとして使用する-これは「間違っている」ですか？
私のチームはSolrを検索インデックスとして使用するサードパーティのCMSを使用しています。返された各ドキュメントに2つのフィールドが含まれているという点で、作者がSolrをソートのデータベースとして使用しているようです。
- SolrドキュメントID（基本的にクラス名とデータベースID）
- オブジェクト全体のXML表現
つまり、基本的にはSolrに対して検索を実行し、オブジェクトのXML表現をダウンロードしてから、IDを使用してデータベースで検索するのではなく、XMLからオブジェクトをインスタンス化します。
私の直感は、これは悪い習慣だと私に告げています。 Solrはデータベースではなく検索インデックスです...したがって、Solrに対して複雑な検索を実行し、ドキュメントIDを取得して、対応する行をデータベースからプルする方が理にかなっています。
現在の実装は完全に健全ですか、またはこれがリファクタリングに適しているという考えを裏付けるデータはありますか？
編集：「XML表現」と言う場合-複数の保存フィールドではなく、オブジェクトのすべてのプロパティのXML文字列を含む1つの保存フィールドを意味します。
はい、SOLRをデータベースとして使用できますが、いくつかの本当に重大な警告があります。
SOLRの最も一般的なアクセスパターン（httpを介したもの）は、バッチクエリに特によく応答しません。さらに、SOLRはデータをストリーミングしません---一度に数百万のレコードを遅延して反復処理することはできません。 これは、SOLRを使用して大規模なデータアクセスパターンを設計するときは、非常に慎重になる必要があることを意味します。
SOLRのパフォーマンスは水平方向（より多くのマシン、より多くのコアなど）および垂直方向（より多くのRAM、より優れたマシンなど）に拡大しますが、そのクエリ機能は、成熟したRDBMS。とはいえ、フィールド統計クエリなど、非常に便利な優れた関数がいくつかあります。
リレーショナルデータベースの使用に慣れている開発者は、SOLRがクエリでフィルターを使用する方法が原因で、SOLAパラダイムで同じDAO設計パターンを使用すると問題が発生することがよくあります。 大きなクエリの一部またはステートフルな変更の一部にSOLRを使用するアプリケーションを構築するための適切なアプローチを開発するための学習曲線があります。
多くの高度なWebフレームワーク（Ruby、Hibernateなど）が提供する高度なセッション管理とステートフルエンティティを可能にする「エンタープライズ」ツールは、ウィンドウの外に完全に投入する必要があります。
リレーショナルデータベースは、複雑なデータと関係を処理するためのものです。したがって、これらのデータベースには、最先端のメトリックと自動分析ツールが付属しています。 SOLRで、私はそのようなツールを記述し、手動でストレステストを多数行っています。これは、時間のシンクになる可能性があります。
参加：これは大きなキラーです。リレーショナルデータベースは、単純な述語に基づいてタプルを結合するビューとクエリを作成および最適化する方法をサポートしています。 SOLRでは、インデックス間でデータを結合するための堅牢な方法はありません。
耐障害性：高可用性のために、SolrCloudはその下にある分散ファイルシステム（HCFSなど）を使用します。このモデルはリレーショナルデータベースのモデルとはかなり異なります。リレーショナルデータベースは通常、スレーブとマスター、またはRAIDなどを使用して回復力を発揮します。したがって、クラウドスケーラブルで耐性を持たせるには、SOLRが必要とする回復力インフラストラクチャを提供する準備ができている必要があります。
とはいえ、特定のタスクについてSOLRには多くの明らかな利点があります：（ http://wiki.Apache.org/solr/WhyUseSolr を参照）-緩いクエリの実行と意味のある返却ははるかに簡単です結果。インデックス作成はデフォルトの問題として行われるため、ほとんどの任意のクエリはかなり効果的に実行されます（RDBMSとは異なり、RDBMSでは、事後に最適化や非正規化が必要になることがよくあります）。
結論：SOLRをRDBMSとして使用できますが、（私が持っているように）最終的には「無料の昼食なし」であることがわかります。超クールなluceneテキスト検索と高性能のインメモリインデックス作成のコスト削減は、柔軟性の低下と新しいデータアクセスワークフローの採用により、多くの場合支払われます。
yourアプリケーションに応じて、Solrをデータベースとして使用することは完全に合理的です。実際、それは guardian.co.ukがやっていることです 。
それ自体は間違いなく悪い習慣ではありません。 GOTOでさえ、あらゆるレベルの他のツールと同じように、間違った方法で使用することは悪いことです。
「XML表現...」と言ったとき、私はあなたが複数の格納されたSolrフィールドを持ち、SolrのXMLフォーマットを使用してこれを取得することについて話していると想定します。 。 Solrがデフォルトの応答フォーマットとしてXMLを使用するという事実はほとんど関係ありません。 バイナリプロトコル を使用することもできるため、その点で従来のリレーショナルデータベースにかなり匹敵します。
最終的には、アプリケーションのニーズ次第です。 Solris主にテキスト検索エンジンですが、多くのアプリケーションのNoSQLデータベースとしても機能します。
これはおそらくパフォーマンス上の理由で行われました。問題が発生しない場合は、そのままにしておきます。従来のデータベースとsolrインデックスの間にあるはずの大きな灰色の領域があります。 Iveは、UIプレゼンテーションに対してこれと同様のこと（通常はxmlではなくキーと値のペアまたはjson）を行い、更新/削除に必要な場合にのみ、データベースから実際のオブジェクトを取得します。ただし、すべての読み取りはSolrに送信されます。
非常に高速な検索が可能なため、同様のことが行われているのを見てきました。 Luceneインデックスから高速のKey-Valueストアにデータを移動して、DRYの原則に従い、インデックスのサイズを小さくしています。これには厳密なルールはありません。一種のこと。