Are there any support for real time search like the one google have.
Not to be confused by the term real time search , what i mean was that
search results are displayed long before the entire term is typed.
What i am expecting is some optimizations in this area , may be something
like abandaning a request if another request (which came after ) from same
source is processed.
There was a similar discussion a few months back (I think the answer
on the es optimization side was that it wasn't practical, but I won't
speak for Shay).
What I do for a similar problem, which works completely fine for me,
is just to throttle at the interface side, with something like:
1] On keypress (/new word, whatever), check if there are any pending
requests:
1A] If not send a request
1B] If so, save this request (overwriting anything previously saved)
and return
2] When a request returns, send out the saved request, if there is one
(Obviously you can play similar games on the rendering side if there's
a bottleneck there, ie only displaying the results from [2] if there
are no saved requests that will replace it, unless there has been no
update to the display for a given period)
This very simple algorithm prevents a build up of "old" requests. If
the latency is high enough that this doesn't work reasonably well, my
guess would be that the searches are too slow to be sensibly rendered
in real-time anyway!
Are there any support for real time search like the one google have.
Not to be confused by the term real time search , what i mean was that
search results are displayed long before the entire term is typed.
What i am expecting is some optimizations in this area , may be something
like abandaning a request if another request (which came after ) from same
source is processed.
There was a similar discussion a few months back (I think the answer
on the es optimization side was that it wasn't practical, but I won't
speak for Shay).
What I do for a similar problem, which works completely fine for me,
is just to throttle at the interface side, with something like:
1] On keypress (/new word, whatever), check if there are any pending
requests:
1A] If not send a request
1B] If so, save this request (overwriting anything previously saved)
and return
2] When a request returns, send out the saved request, if there is one
(Obviously you can play similar games on the rendering side if there's
a bottleneck there, ie only displaying the results from [2] if there
are no saved requests that will replace it, unless there has been no
update to the display for a given period)
This very simple algorithm prevents a build up of "old" requests. If
the latency is high enough that this doesn't work reasonably well, my
guess would be that the searches are too slow to be sensibly rendered
in real-time anyway!
Are there any support for real time search like the one google have.
Not to be confused by the term real time search , what i mean was that
search results are displayed long before the entire term is typed.
What i am expecting is some optimizations in this area , may be something
like abandaning a request if another request (which came after ) from
same
source is processed.
The size of the data set and type of data also play a role in what you can
get away with. We built a demo for a for an organization that allowed them
to search people this way (internal employees). The video is here:
We pushed all the rendering out to the client and we're using ngrams. The
code for that demo is here:
The size of the data set and type of data also play a role in what you can
get away with. We built a demo for a for an organization that allowed them
to search people this way (internal employees). The video is here:
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.