Hi, You have many basic questions about search. Can I recommend one of the books? http://lucene.apache.org/solr/books.html Also, you'll find a lot of answers on the Solr WIKI: http://wiki.apache.org/solr/ if you're not aware of it.
I think Solr may solve your performance problems well. Whether it's the right tool for the job depends on several factors. Also, sometimes it is useful to step back and think fresh. Perhaps the reason why you implemented things like you did was technical reasons driven by your DB capabilities. When re-implementing on top of Solr, perhaps there are better ways to do what you REALLY wanted instead of limiting yourself to the ORDER BY syntax etc. One of Solr's strengths is relevancy and FunctionQueries and it can do amazing things :) Further answers below.. -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com Solr Training - www.solrtraining.com On 17. apr. 2012, at 07:20, Alexandr Bocharov wrote: > Thanks for your reply :) > I have some new questions now: > 1. How stable is trunk version? Has anyone used it on any kind of highload > project in production? It's stable. Used in production many places. Soon expected in alpha or beta release > 2. Does version 3.6 support near real time index update? No > 3. What is scheme of Solr index storing? Is it all in memory for each shard > or in disk with caching for frequently asked queries in memory? On disk but with many caching optimizations > 4. The best practice for index updating is - to do delta imports each 5 > minutes for example, and once a day - full rebuild index, does it take long > time for ~100 mln users? Am I right? You can do deltas only, as often as you choose. Solr will handle the backend details > 5. Does sharding and replications have native support in Solr, so everyting > I need to care about is config file for nodes? Are there any limitations of > usage such sorting if we use sharding? Yes, sharding and replication is natively supported. See the Wiki > The reason why we want to move from our DB search scheme (data is sharded > into small tables at several servers and managed in code) is that: > 1. response time of our search isn't what we need (3-5 s now in production, > we want <1 s) > 2. growing amount of data > 3. we want automatically clustering any amount of data and search by it, > without need to care about how data stores and does it has durability or not > > That's why we also looking other solutions with autosharding of huge amount > of data with ability to make such types of query and sorting (thinking > about Mysql Cluster, but it's not stable yet, or Oracle Cluster). If anyone > can give advice for such technology, I'll be glad to hear it. What do you expect from "Autosharding"? > > 2012/4/17 Jan Høydahl <jan....@cominvent.com> > >>> Hi everyone :) >> >> Hi :) >> >>> So, these are my 3 questions: >>> 1. Does Solr provide searching among different count fields with >> different >>> types like in WHERE condition? >> >> Yes. As long as these are not full-text you should use filter queries for >> these, e.g. >> &q=*:* >> &fq=country:USA >> &fq=language:SPA >> &fq=age:[30 TO 40] >> &fq=(bool_field1:1 OR bool_field2:1) >> >> The reason why I put multiple "fq" instead of one long is to optimize for >> caching of filters >> >>> 2. Does Solr provide such sorting, that depends on other fields (like >> sums >>> in ORDER BY), other words - does it provide any kind of function, which >> is >>> used to sort results from q1? >> >> Yes. In trunk version you can sort by function which can do sums and all >> crezy things >> &sort=sum(product(has_photo,10),if(exists(query($agequery)),50,0)) >> asc&agequery=age:[53 TO *] >> See http://wiki.apache.org/solr/FunctionQuery for more functions >> >> But you could also to much of this through boost queries >> &sort=score desc >> &bq=language:FRA^50 >> %bq=age:[53 TO *]^20 >> >>> 3. Does Solr provide realtime index updating or updating every N minutes? >> >> Sure, there is Near Real-time indexing in TRUNK (coming 4.0) >> >> Jan
