Re: how to get the count of returned results

thanks Hoss, once again. -umar On Sat, Jun 14, 2008 at 4:06 AM, Chris Hostetter <[EMAIL PROTECTED]> wrote: > > : I am using a servlet filter to alter the query parms sent to the solr , > : now I have a problem where I want to take some extra action (like drop > some > : query terms or filters

Re: scaling / sharding questions

Hi. We as well use md5 as the uid. I guess by saying each 1/16th is because the md5 is hex, right? (0-f). Thinking about md5 sharding. 1 shard: 0-f 2 shards: 0-7:8-f 3 shards: problem! 4 shards: 0-3 This technique would require that you double the amount of shards each time you split right ?

Re: Num docs

Hmmm distributed BDB brrr :) On Fri, Jun 13, 2008 at 3:21 AM, Otis Gospodnetic < [EMAIL PROTECTED]> wrote: > Or, if you want to go with something older/more stable, go with BDB. :) > > > Otis -- > Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch > > > - Original Message > > From

doubt with an index of 300gb

Hi users, I´m going to create a big index of 300gb in a SAN where i have 4TB. I read many entries in the mail list talking about using multiple index with multicore. I would like to know what kind of benefit can i have using multiple index instead of one big index if i dont have problems with the

Re: doubt with an index of 300gb

Roberto, Here is some food for thought... Multiple smaller indices you can split them across several servers, but you can't do that with a monolithic index. With multiple smaller indices you can choose to search only a subset of them, should that make sense for your app. How much does it cost

Re: doubt with an index of 300gb

Hi Otis, Thanks for your fast answer. I understand perfectly your points. I will explain my limitations ... --Multiple smaller indices you can split them across several servers, but you can't do that with a monolithic index. The index will be allocated in a SAN that is not under my election. I c

Re: doubt with an index of 300gb

Hi Roberto, SAN is a fine choice, if that's what you were worried about. There is no way to tell exactly how fast your searches will be, as that depends on a lot of factors -- benchmarking with your own data and hardware and queries is the best way to go. As for the cost of multiple smaller m