anchor.diff:  
   You can set the "parallel_shards" option to "false" to disable this feature to support top N style queries, however, that will reduce read performance in your Spark job, so use it wisely.
   
  +// end::tuning[]
  +// tag::solr-read[]
   
   == Reading data from Solr as a Spark RDD
   
  
positive.code: 
  Another subtle aspect of working with DataFrames is that you as a developer need to decide when to cache the DataFrame based on how expensive it was to create it. For instance, if you load 10’s of millions of rows from Solr and then perform some costly transformation that trims your DataFrame down to 10,000 rows, then it would be wise to cache the smaller DataFrame so that you won’t have to re-read millions of rows from Solr again. On the other hand, caching the original millions of rows pulled from Solr is probably not very useful, as that will consume too much memory. The general advice I follow is to cache DataFrames when you need to reuse them for additional computation and they require some computation to generate.
  
  == Tuning the Solr SparkSQL DataSource
  
  The Solr DataSource supports a number of optional parameters to allow you to optimize performance when reading data from Solr. Let's start with the most basic definition of the Solr DataSource and build up the options as we progress through this section:
  
negative.code: * Read the results from a Solr query as a Spark RDD
  * Read a large results set from Solr using distributed deep paging as a Spark RDD
  
  // tag::spark-build[]
  
  == Build the Jars
  First, build the Jar for this project:
  
  