Having documents without fields doesn't matter much. Solr (well, Lucene actually) is pretty efficient about this. It handles thousands of different field types, although I have to say that when you have thousands of fields it's usually time to revisit the design. It looks like your total field count is quite reasonable.
The biggest bit for single .vs. multiple is if you want to select documents of one type based on some criteria of another type (think join in DB terms). It's much easier with a single collection. That said, if you start to use Solr "just like a database" then you might also want to revisit your architecture ;) Best, Erick On Fri, Apr 13, 2018 at 12:44 AM, neotorand <neotor...@gmail.com> wrote: > Hi Shawn, > Thanks for the long explanation. > Now 2 Billion limit can be overcome by using shard. > > Now coming back to collection.Unless we have a logical or Business reason > we should not go for more than one collection. > > Lets say i have 5 different entities and they have each 10,20,30,40 and 50 > attributes(Columns) to be indexed/stored. > Now if i store them in single collection.is there any ways empty spaces > being created. > On other way if i store heterogeneous data items in a single collection, > Does by any means there is a poor utilization of memory by creation of empty > holes. > > What are the pros and cons of single vs Multiple. > > Thanks team for spending your valuable time to clarify. > > Regards > Neo > > > > > > -- > Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html