![](https://csdnimg.cn/release/download_crawler_static/6325279/bg11.jpg)
©Manning Publications Co. Please post comments or corrections to the Author Online forum:
http://www.manning-sandbox.com/forum.jspa?forumID=828
1.2.5 Extendable (plug-ins)
Figure 1.3 depicts three main sub-systems in Solr: document management, query
processing, and text analysis. Of course, these are high-level abstractions for complex sub-
systems in Solr; we’ll learn about each later in the book. Each of these systems is composed
of a modular “pipeline” that allows you to plug-in new functionality. This means that instead
of overriding the entire query-processing engine in Solr, you plug-in a new search
component into an existing pipeline. This makes the core Solr functionality easy to extend
and customize to meet your specific application needs.
1.2.6 Scalable
Lucene is an extremely fast search library and Solr takes full advantage of Lucene’s speed.
But regardless of how fast Lucene is, a single server will reach its limits in terms of how
many concurrent queries from different users it can handle due to CPU and I/O constraints.
As a first pass to scalability, Solr provides flexible cache management features that help
your server avoid recomputing expensive operations. Specifically, Solr comes preconfigured
with a number of caches to save expensive recomputations, such as caching the results of a
query filter. We’ll learn about Solr’s cache management features in chapter 4.
Caching only gets you so far so at some point, you’re going to need to scale out your
capacity to handle more documents and higher query throughput by adding more servers.
For now let’s focus on the two most common dimensions of scalability in Solr. First is query
throughput, which is the number of queries your engine can support per second. Even
though Lucene can execute each query quickly, it’s limited in terms of how many concurrent
requests a single server can handle. For higher query throughput, you add replicas of your
index so that more servers can handle more requests. This means if your index is replicated
across three servers, then you can handle roughly three times the number of queries per
second because each server handles one-third of the query traffic. In practice, it’s rare to
achieve perfect linear scalability so adding three servers may only allow you to handle two
and one half times the query volume of one server.
The other dimension of scalability is the number of documents indexed. If you’re dealing
with large volumes of documents, then you’ll likely reach a point where you have too many
documents in a single instance and query performance will suffer. To handle more
documents, you split the index into smaller chunks called “shards” and then distribute the
searches across the shards.
Scaling-out with virtualized commodity hardware
One trend in modern computing is building software architectures that can scale
horizontally using virtualized commodity hardware. Put simply, add more commodity
servers to handle more traffic. Fueling this trend towards using virtualized commodity
hardware are cloud-computing providers such as Amazon EC2. Although Solr will run on
virtualized hardware, you should be aware that search is I/O and memory intensive.