In my experience, about as fast as you can push the new data :) Depending on the size of your records, this should be a matter of seconds.
/Martin Koch On Wed, Oct 24, 2012 at 9:01 PM, Marcelo Elias Del Valle <mvall...@gmail.com > wrote: > Erick, > > Thanks for the help, it sure helps a lot to read that, as it gives me > more confidence I am not crazy about what I am thinking. > The only problem I see by de-normalizing data as you said is that if > any relation between customer and vendor changes, I will have to update the > index for all the vendors. I could have about 10 000 customers per vendor. > Anyway, by what you're saying, it's more common than I was imagining, > right? I wonder how long solr will take to reindex 10000 records when this > happens. > > Thanks, > Marcelo Valle. > > 2012/10/24 Erick Erickson <erickerick...@gmail.com> > > > One, take off your RDBMS cap <G>... > > > > DB folks regularly reject the idea of de-normalizing data > > to make best use of Solr, but that's what I would explore > > first. Yes, this repeats the, in your case, vendor information > > perhaps many times, but try that first, even though that > > causes you to update multiple customers whenever a vendor > > changes. You haven't specified how many customers and vendors > > you're talking abou there, but unless the total number of documents > > (where each document is a customer+vendor combination) > > is multiple tens of millions, you probably will be fine. > > > > You can get a list of just customers by using grouping where you > > group on customer, although that may not be the most efficient. You > > could index a field, call it "cust_filter" that was set to true for the > > first > > customer/vendor you indexed and false (or just left out) for all the > > rest and q=blahblah&fq=cust_filter:true. > > > > Hope that helps > > Erick > > > > On Wed, Oct 24, 2012 at 12:01 PM, Marcelo Elias Del Valle > > <mvall...@gmail.com> wrote: > > > Hello, > > > > > > I am new to Solr and I have a scenario where I want to use it, but > I > > > might be misunderstanding some concepts. I will explain what I want > here, > > > if someone has a solution for this, I would gladly accept the help. > > > I have a core indexing customers. I have another core indexing > > vendors. > > > Both are related to each other. > > > Here is what I want to do in my application: I want to find all the > > > customers that follow some criteria and them find the vendors related > to > > > them. > > > > > > My first option was to to have just vendor core and in for each > > > document in vendor core I would have all the customers related to it. > > > However, I would write the same customer several times to the index, as > > > more than one vendor could be related to the same customer. Besides, I > > > wonder how would I write a query to list just the different customers. > > > Another problem is that I update customers in a different frequency I > > > update vendors, but have vendor + customers in a single document would > > obly > > > me to do the full update. > > > > > > Does anyone have a good solution for this I am not being able to > > see? I > > > might be missing some basic concept here... > > > > > > Thanks, > > > -- > > > Marcelo Elias Del Valle > > > http://mvalle.com - @mvallebr > > > > > > -- > Marcelo Elias Del Valle > http://mvalle.com - @mvallebr >
