: of the components as well as the flow of data and queries. The result is
: a conceptual architecture diagram, clearly showing how Solr relates to
: the app-server, how cores relate to a Solr instance, how documents enter
: through an UpdateRequestHandler, through an UpdateChain and Analysis and
: into the Lucene index etc.
Looks really good, but two bits that i think might confuse people are
the implications that a "Query Parser" then invokes a series of search
components; and that "analysis" (and the pieces of an analyzer chain)
are what to lookups in the underlying lucene index.
the first might just be the ambiguity of "Query" .. using the term
"request parser" might make more sense, in comparison to the "update
parsing" from the other side of hte diagram.
the analysis piece is a little harder to fix cleanly. you really want the
end of the analysis chain to feed back up to the searh components, and
then show it (most of hte search components really) talking to the Lucene
index.
FWIW: the last time i tried to do an arcitecture diagram for solr was my
"Beyond the Box" talk a few years back, targeted at people interested in
writing plugins. I made my job a lot easier then what you tackled by
keeping it at the 50,000 foot level where the SOlrRequestHandler was the
smallest unit of work i described. From that fiew there are nice
parallels that can be drawn with more traditional MVC architectures which
make it a little easier for people to understand...
http://people.apache.org/~hossman/apachecon2008us/btb/
Slides #9 & 10
-Hoss
