Let's see...
1> Committing every second, even with commitWithin is probably going
to be a problem.
     I usually think that 1 second latency is usually overkill, but
that's up to your
     product manager. Look at the NRT (Near Real Time) stuff if you
really need this.
     I thought that NRT was only on trunk, but it *might* be in the
3.4 code base.
2> Don't understand what "a single index per entity" is. How many cores do you
     have total? For not very many records, I'd put everything in a
single index and
     use filterqueries to restrict views.
3> I guess this relates to <2>. And I'd use a single core. If, for
some reason, you decide
     that you need multiple indexes, use several cores with ONE Solr
rather than start
     a new Solr per core, it's more resource expensive to have
multiple JVMs around.

Best
Erick

On Thu, Nov 3, 2011 at 2:03 PM, Gustavo Falco
<comfortablynum...@gmail.com> wrote:
> Hi guys!
>
> I have a couple of questions that I hope someone could help me with:
>
> 1) Recently I've implemented Solr in my app. My use case is not
> complicated. Suppose that there will be 50 concurrent users tops. This is
> an app like, let's say, a CRM. I tell you this so you have an idea in terms
> of how many read and write operations will be needed. What I do need is
> that the data that is added / updated be available right after it's added /
> updated (maybe a second later it's ok). I know that the commit operation is
> expensive, so maybe doing a commit right after each write operation is not
> a good idea. I'm trying to use the autoCommit feature with a maxTime of
> 1000ms, but then the question arised: Is this the best way to handle this
> type of situation? and if not, what should I do?
>
> 2) I'm using a single index per entity type because I've read that if the
> app is not handling lots of data (let's say, 1 million of records) then
> it's "safe" to use a single index. Is this true? if not, why?
>
> 3) Is it a problem if I use a simple setup of Solr using a single core for
> this use case? if not, what do you recommend?
>
>
>
> Any help in any of these topics would be greatly appreciated.
>
> Thanks in advance!
>

Reply via email to