あなたのアプローチは実際に良いです。 Compassのようないくつかの人気のあるフレームワークは、ORMフレームワークを介して実行されたインデックスの変更に自動的にミラーリングするために、より低いレベルで説明したことを実行しています（http://www.compass-project.org/overview.htmlを参照）。
あなたの説明に加えて、SolrとMongoの両方が同期されるように、MongoDBに存在するすべてのデータのインデックスを定期的に再作成します（ドキュメントの数によっては、おそらく思ったほど長くはありませんが、フィールド数、フィールドあたりのトークン数、アナライザーのパフォーマンス：複雑なアナライザーを使用すると、15分以内に500万から800万のドキュメント（約20フィールドですが、テキストフィールドは短い）のインデックスを作成することがよくあります。 RAMバッファは小さすぎず、すべてのドキュメントが追加されるまでコミット/最適化しないでください。
パフォーマンスに関しては、コミットにはコストがかかり、最適化には非常にコストがかかります。最も重要なことに応じて、Solrconfig.xmlのmergefactorの値を変更できます（値が大きいと書き込みパフォーマンスが向上し、値が低いと読み取りパフォーマンスが向上します。最初は10が適切な値です）。
あなたはインデックスの構築時間を恐れているようです。ただし、Luceneインデックスストレージはセグメントベースであるため、書き込みスループットはインデックスのサイズにあまり依存しないようにする必要があります（http://lucene.apache.org/java/2_3_2/fileformats.html）。ただし、ウォームアップ時間は長くなるため、次のことを確認する必要があります
- 一般的ですが（特にフィールドキャッシュをロードするための並べ替えの場合）、solrconfig.xml構成ファイルのfirstSearcherおよびnewSearcherパラメーターにそれほど複雑ではないクエリがあります。
- useColdSearcherは
- に設定されています
- 検索パフォーマンスを向上させるためにfalse、または
- 検索が遅くなる代わりに、インデックスに対して実行された変更をより速く考慮したい場合はtrue。
さらに、データがMongoDBに書き込まれてからわずか数Xミリ秒後に検索可能になった場合に許容できる場合は、UpdateHandlerのcommitWithin機能を使用できます。このようにして、Solrはコミットする頻度が少なくなります。
Solrのパフォーマンス要因の詳細については、http：//wiki.apache.org/solr/SolrPerformanceFactors
を参照してください。ドキュメントを削除するには、ドキュメントID（schema.xmlで定義）またはクエリで削除できます：http：//lucene.apache.org/solr/api/org/apache/solr/client/solrj/SolrServer.html