Norgorn [lsunnyd...@mail.ru] wrote: > Collection contains about billion of documents.
So 3-400M documents per core. That is a challenge with frequent updates and facets, but with your simple queries it should be doable. > At the end, I want to reach several seconds per search query (for not cached > query =) ), so, please, give me some reference points. The frustratingly true answer is http://lucidworks.com/blog/sizing-hardware-in-the-abstract-why-we-dont-have-a-definitive-answer/ > How much (roughly) will I need RAM with and without SSDs? > I know, it depends, but at least sommething, please. Okay, something it is: We have a 256GB machine, running a SolrCloud with 17 shards, each shard being about 900GB / 300M documents and put on a dedicated SSD. The machine currently has 160GB free for disk cache or about 1% of the total index size. For very simple unwarmed searches (just query on 1-3 terms, edismax over 6 fields with 2 phrase fields), median response time is < 200ms and nearly all response times are < 1 second. An extremely rough downscale with a factor 15 to approximate your 1TB index would leave 11GB for disk cache; divide it by 3 for your machines and it's 4GB disk cache/machine + whatever it takes to run your Solrs and the system itself. BUT! All the shards are fully optimized and never updated, range filters can be tricky, multiple filters takes time, you have more documents/bytes than we have etc. > And HS means HelioSearch, Ah. Of course. Although it helps with processing performance, it cannot do anything for your IO-problem, How much memory is used for disk caching with your current setup? - Toke
