Hi Otis, Currently, whole record has to be stored on disk in order to update single field. Are you trying to say that it won't be necessary with the use of DocValues ? Sounds great!
Regards. On 29 March 2013 20:51, Otis Gospodnetic <otis.gospodne...@gmail.com> wrote: > Hi, > > The current field update mechanism is not really a field update > mechanism. It just looks like that from the outside. DocValues > should make true field updates implementable. > > Otis > -- > Solr & ElasticSearch Support > http://sematext.com/ > > > > > > On Fri, Mar 29, 2013 at 3:30 PM, Marcin Rzewucki <mrzewu...@gmail.com> > wrote: > > Hi, > > Atomic updates (single field updates) do not depend on DocValues. They > were > > implemented in Solr4.0 and works fine (but all fields have to be > > retrievable). DocValues are supposed to be more efficient than > FieldCache. > > Why not enabled by default ? Maybe because they are not for all fields > and > > because of their limitations (a field has to be single-valued, required > or > > to have default value). > > Regards. > > > > > > > > On 29 March 2013 17:20, Timothy Potter <thelabd...@gmail.com> wrote: > > > >> Hi Jack, > >> > >> I've just started to dig into this as well, so sharing what I know but > >> still some holes in my knowledge too. > >> > >> DocValues == Column Stride Fields (best resource I know of so far is > >> Simon's preso from Lucene Rev 2011 - > >> > >> > http://www.slideshare.net/LucidImagination/column-stride-fields-aka-docvalues > >> ). > >> It's pretty dense but some nuggets I've gleaned from this are: > >> > >> 1) DocValues are more efficient in terms of memory usage and I/O > >> performance for building an alternative to FieldCache (slide 27 is very > >> impressive) > >> 2) DocValues has a more efficient way to store primitive types, such as > >> packed ints > >> 3) Faster random access to stored values > >> > >> In terms of switch-over, you have to re-index to change your fields to > use > >> DocValues on disk, which is why they are not enabled by default. > >> > >> Lastly, another goal of DocValues is to allow updates to a single field > w/o > >> re-indexing the entire doc. That's not implemented yet but I think still > >> planned. > >> > >> Cheers, > >> Tim > >> > >> > >> > >> On Fri, Mar 29, 2013 at 9:31 AM, Jack Krupansky < > j...@basetechnology.com > >> >wrote: > >> > >> > I’m still a little fuzzy on DocValues (maybe because I’m still > grappling > >> > with how it does or doesn’t still relate to “Column Stride Fields”), > so > >> can > >> > anybody clue me in as to how useful DocValues is/are? > >> > > >> > Are DocValues simply an alternative to “stored fields”? > >> > > >> > If so, and if DocValues are so great, why aren’t we just switching > Solr > >> > over to DocValues under the hood for all fields? > >> > > >> > And if there are “issues” with DocValues that would make such a > complete > >> > switchover less than absolutely desired, what are those issues? > >> > > >> > In short, when should a user use DocValues over stored fields, and > vice > >> > versa? > >> > > >> > As things stand, all we’ve done is make Solr more confusing than it > was > >> > before, without improving its OOBE. OOBE should be job one in Solr. > >> > > >> > Thanks. > >> > > >> > P.S., And if I actually want to do Column Stride Fields, is there a > way > >> to > >> > do that? > >> > > >> > -- Jack Krupansky > >> >
