Comments on: SOLR Performance Benchmarks – Single vs. Multi-core Index Shards

By: 绚丽也尘埃 » Solr multicore配置

绚丽也尘埃 » Solr multicore配置 — Fri, 22 Apr 2011 02:22:52 +0000

[...] SOLR Performance Benchmarks – Single vs. Multi-core Index Shards [...]

By: Na_D

Na_D — Mon, 26 Apr 2010 11:09:26 +0000

great work !!! but one question how did you get the index size of solr??I have been working with solr but i did not find any direct API’s to check the same .

By: Terry Jones

Terry Jones — Mon, 01 Mar 2010 15:12:05 +0000

These graphs are amazing – does anyone know what tool was used to generate them?

By: Leon

Leon — Tue, 02 Feb 2010 12:32:17 +0000

Good overview. Have you any experience with sharding by document content or type, e.g., by date ranges per shard? http://www.lucidimagination.com/Community/Hear-from-the-Experts/Articles/Scaling-Lucene-and-Solrhttp://www.lucidimagination.com/Community/Hear-from-the-Experts/Articles/Scaling-Lucene-and-Solr

By: Subroto

Subroto — Sat, 23 Jan 2010 19:34:59 +0000

The writeup by Mr. Justin was very informative. Please let me know if it is possible to partition indexes using SOLR. Apache has provided a whitepaper regarding the issue. I need some more detailed information on it.

By: Steve Pettigrew

Steve Pettigrew — Thu, 04 Jun 2009 16:22:43 +0000

Well done. As you said there is not a whole lot of information out there and comparisons are difficult to be made. We now have some (lot) more with the above study.

Just one question about the Dell r900 specs. Is it really 24GB RAM???

By: Shalin Shekhar Mangar

Shalin Shekhar Mangar — Sat, 16 May 2009 20:19:52 +0000

Thanks for the nice writeup Justin. I would like to highlight a few points related to multicore and distributed search support.

Multicore support was originally contributed for a use-case where users wanted to have multiple indexes on the same Solr instance where each core was dedicated to a different language. One of the assumptions was that one will use multi-core if the data did not need to be joined.

Distributed Search was built for the use-case where the index is just too big for one box and therefore needs to be split among different boxes but the data needs to be queried in its entirety. As you noted, one of the key assumptions was that if documents are assigned randomly to shards, IDF can be ignored in a distributed search.

It is the HTTP based design which enables one to use both these features together but that might not be the optimal design. If one can use a single index, it is better to go with that and avoid the overhead of distributed search. Also, in some cases, it is better to have multiple solr instances on the same box rather than have multiple cores to avoid GC overhead on JVM heaps.