bq: Try not to store fields as much as possible. Why? Storing fields certainly adds lots of size to the _disk_ files, but have much less effect on memory requirements than one might think. The *.fdt and *.fdx files in your index are used for the stored data, and they're only read for the top N docs returned (30 in this case). And since the stored data is decompressed in 16K blocks, you'll only really pay a performance penalty if you have very large documents. The memory requirements for stored fields is pretty much governed by the documentCache.
How are you committing? your solrconfig file has all commits commented out and it also has maxWarmingSearchers set to 4. Based on this scanty evidence, I'm guessing that your committing from a client, and committing far too often. If that's true, your performance is probably largely governed by loading low-level caches. Your autowarming numbers in filterCache and queryResultCache are, on the face of it, far too large. Best, Erick On Thu, Jun 25, 2015 at 8:12 AM, wwang525 <wwang...@gmail.com> wrote: > schema.xml <http://lucene.472066.n3.nabble.com/file/n4213864/schema.xml> > solrconfig.xml > <http://lucene.472066.n3.nabble.com/file/n4213864/solrconfig.xml> > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/How-to-do-a-Data-sharding-for-data-in-a-database-table-tp4212765p4213864.html > Sent from the Solr - User mailing list archive at Nabble.com.