Hi Adrien Grand,
Thanks for the response.
a binary blob that
> stores all the data so that you can perform updates.
Could you elaborate on this? Do you mean to have StoredField as mentioned
below to store all other fields which are needed only for updates? is there
any way to use updatedocuments api for this kind of updates instead of
taking out storedfields and delete-add updated documents?
Use a StoredField. You can pass in either the BytesRef, or the byte array
>> itself into the field:
>
>
>> byte[] myByteArray = new byte[100000];
>
> document.add(new StoredField("bin1", myByteArray));
>
> As far as retrieving the value, you are on about the right track there
>> already. Something like:
>
>
>> Document resultDoc = searcher.doc(docno);
>
> BytesRef bin1ref = resultDoc.getBinaryValue("bin1");
>
> bytes[] bin1bytes = bin1ref.bytes;
>
>
Snippet from: http://stackoverflow.com/a/34324561/1382168
--
Kumaran R
On Thu, Feb 16, 2017 at 12:38 AM, Adrien Grand <jpou...@gmail.com> wrote:
> I think it is hard to come up with a general rule, but there is certainly a
> per-field overhead. There are some things that we need to store per field
> per segment in memory, so if you multiply the number of fields you have,
> you could run out of memory. In most cases I have seen where the index had
> so many fields, it was due to the fact that the application wanted to index
> arbitrary documents and provide search for them, which cannot scale, or to
> the fact that the index contained many unrelated documents that should have
> been put into different indices. This limit has been very useful to catch
> such design problems early instead of waiting for the production server to
> go out of memory due to the multiplication of fields.
>
> Le mer. 15 févr. 2017 à 19:44, Kumaran Ramasubramanian <kums....@gmail.com
> >
> a écrit :
>
> > While searching, i use _all_ blob field to search in texts of all fields
> > data.
> >
>
> This is interesting: if all your searches go to a catch-all field, then it
> means that you do not need those thousands of fields but could just have a
> single indexed field that is used for searching, and a binary blob that
> stores all the data so that you can perform updates. So this only requires
> two fields from a Lucene perspective.
>
