lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Visual Logic <>
Subject Re: Using JSON for index input and search output
Date Sun, 30 May 2010 20:11:17 GMT
This is interesting.

I'm coming into this with only the knowledge I gained from the 1st version of the Lucene in
Action book, which I read a few years ago. So when I think of embedded I think that Solr would
be integrated into my app like any API would be. Instead you say Solr is a separate process
that could work adjunct to my app. In other words in my mind it would be a extension module
or even plugin for my app. Would be possible to start/stop it from my app as well? Hope I'm
seeing the picture clearly now?

What I find most useful in Lucene is its searching capability. Since I have pre-structured
data which are the different configurations the different tools and tiers of my app use the
analysis stage is not that involved. Once data is indexed, likely in several indexes/cores,
I would like to search for specific documents and set them to be the current context for different
tools. There are a number different contexts and index documents specific to each of them.
I guess what I am after is a searchable configuration engine for a RIA.

Some of my use cases can tolerate a bit of latency but for others it would not work so well.
Here are two of the more dynamic use cases (slightly simplified to make them clear) where
searching has to be blazingly fast:

1 - I have a draw tool that places different shape types while dragging (each drag forms a
string of shapes) across a canvas. I track the types of shapes the current drag has placed
so far and then what to recommend other shape strings (prior drawn strings are indexed as
they were made) that are similar in order to help the user complete the current draw string.
The query would be created on the fly based on what shapes have been drawn so far and then
used to search the index, the search would also need to be refreshed every time the user moves
the mouse. This use case is similar to type-ahead phrase completion but completely mouse driven
with fired searches in the background and immediate graphics on the canvas. Will Solr running
as a separate local process be able to keep up with the user driven drawing?

2 - My app features a Painter with Renderers for different shapes. The many possible layout
and style details for these shapes and their relation to each other are defined as configurations
per Renderer. The index would contain multiple versions of a configuration for a given Renderer.
A search would then be used to bring up a set of configurations, the set would have a configuration
for each Renderer. This set would then be the active rules (context) for rendering each type
of shape. Then as the user creates shapes by drawing different shape types they are rendered
by their specific Renderer. The given Renderer in turn looks up all the rules for layout and
styling it should have from the active set of configurations. The question is if the lookup
can be on the fly searches to a index or if it is better to pull up the set of configurations
from the index and transfer them to hashmaps that the Renderers would query instead of querying
the index directly? Would Solr be able to keep up with all the real-time lookups the Renders
would be making?


On 2010-05-30, at 1:38 PM, Yonik Seeley wrote:

> On Sun, May 30, 2010 at 2:27 PM, Visual Logic <> wrote:
>> Solr is embeddable but does that not just mean that SolrJ only provides the ability
to call Solr running on some server?
> Nope - embeddable as in running in the same JVM as your application.
>> For some of my use cases using Solr on a remote server would work fine. For other
cases it will not be quick enough,
> Running as a separate server can be on the same host and be very
> quick.  Was it too slow when you tried it?
> It's a common misconception that HTTP is slow... it's really just a
> TCP socket (which can be reused with persistent connections) with some
> standardized headers.  Solr also has a binary protocol that works just
> fine over HTTP, so it's really not more overhead than doing something
> like talking to a database.
> But the right solution probably depends on the details of your
> specific usecases - if you elaborate on them, people may be able to
> provide more specific recommendations.
> -Yonik
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message