Having been thinking about your questions again and I think that if you are expecting that the price value will be changing a lot, especially when talking about auctions then you should consider not storing the actual price into the full text index but into some fast datastore. Some kind of scalable in-memory hash map with journal based backup would do this job better I think.
Just my 2 cents. Regards, Lukas On Wed, Mar 17, 2010 at 10:36 AM, Lukáš Vlček <lukas.vl...@gmail.com> wrote: > Hi, > > Solr is running on top of Lucene and as far as I know Lucene knows only one > approach how to update the document field content: that is delete first and > then (re)index with new values. > However, saying this it does not mean you can not implement what you need. > Take a look at ParallelReader API > http://lucene.apache.org/java/3_0_1/api/all/org/apache/lucene/index/ParallelReader.html > > I am not sure if this functionality is directly exposed via Solr API. Try > digging mail lists (search-lucene.com or lucidimagination.com can be of > good help while you can narrow search to Solr only: > http://search-lucene.com/?q=ParallelReader&fc_project=Solr or > http://www.lucidimagination.com/search/?q=ParallelReader#/p:solr). For > example the following mail thread seems to be relevant: > http://search-lucene.com/m/iT2hMvtDt5 (though it is bit dated) > > Do you really use only one physical index for all auctions? If yes then you > might consider using ParallelReader but if the index is large then I am not > sure about the performance. If you are planning to partition your index then > it can get more complex but faster. > > Regards, > Lukas > > > On Wed, Mar 17, 2010 at 9:49 AM, Moritz Mädler <m...@moritz-maedler.de>wrote: > >> Hi List, >> >> we are running a marketplace which has about a comparable functionality >> like ebay (auctions, fixed-price items etc). >> The items are placed on the market by users who want to sell their goods. >> >> Currently we are using Sphinx as an indexing engine, but, as Sphinx >> returns only document ids we have to make a >> database-query to fetch the data to display. This massively decreases >> performance as we have to do two requests to >> display data. >> >> I heard that Solr is able to return a complete dataset and we hope a >> switch to Solr can boost perfomance. >> A critical question is left and i was not able to find a solution for it >> in the docs: Is it possible to update attributes directly in the >> index? >> An example for better illustration: >> We have an index which holds all the auctions (containing auctionid, >> auction title) with its current prices(field: current_price). When a user >> places a new bid, >> is it possible to update the attribute 'current_price' directly in the >> index so that we can fetch the current_price from Solr and not from the >> database? >> >> I hope you understood my problem. It would be kind if someone can point me >> to the right direction. >> >> Thanks alot! >> >> Moritz > > >
