title: Difference(s) between Solr's Cursor and ElasticSearch's Scroll
body: <p>While looking for <em>pagination</em> with <strong>Solr</strong> and <strong>ElasticSearch</strong>, it turned out, both have the same "problem" (deep pagination, especially with shards). Though both search engines provide a solution/workaround for that:</p>
  
  <ul>
  <li><p><strong>Solr:</strong> <code>cursor</code> <a href="https://cwiki.apache.org/confluence/display/solr/Pagination+of+Results">https://cwiki.apache.org/confluence/display/solr/Pagination+of+Results</a></p></li>
  <li><p><strong>ElasticSearch:</strong> <code>scroll</code> <a href="http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-request-scroll.html#scroll-search-context">http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-request-scroll.html#scroll-search-context</a> <br/><br/></p></li>
  </ul>
  
  <p>Now I read those pages and searched the internet, but I'm still a bit clueless at some points:</p>
  
  <ul>
  <li><p><strong><code>cursor</code> / <code>scroll</code> timeouts (garbage collection):</strong></p>
  
  <ol>
  <li><strong>Solr</strong> documentations doesn't seem to provide a way for setting a timeout (or some special query to invalidate a <code>cursor</code> token). That's basically just a question about possible memory leaks, etc.</li>
  <li><strong>ElasticSearch</strong> provides a timeout setting via <code>scroll=1m</code>.<br/><br/></li>
  </ol></li>
  <li><p><strong>backwards pagination:</strong></p>
  
  <ol>
  <li><strong>Solr</strong> will provide a <code>cursor</code> token for each request, so it is possible to access any previous page.</li>
  <li><strong>ElasticSearch</strong> seems to use always the same <code>scroll</code> token. So I cannot go backwards without doing a new search? <br/><br/></li>
  </ol></li>
  <li><p><strong>Alter search query:</strong></p>
  
  <ol>
  <li><strong>ElasticSearch</strong> explicitly requires to use a special URL for <code>scroll</code> queries ( <code>http://localhost:9200/_search/scroll?scroll=1m?scroll_id=...</code>). So there's no possibility to alter the search query.</li>
  <li><strong>Solr</strong> appends the <code>cursor</code> token to the normal query. Does this mean, that I can use some <code>cursor</code> token and change the query (filters, ordering, page size, etc.)? <br/><br/></li>
  </ol></li>
  <li><p><strong>Index changes while using <code>scroll</code> / <code>cursor</code></strong>:</p>
  
  <ol>
  <li><p><strong>Solr</strong> documentation says, that if <em>the sort value of document 1 changed so that it is after the cursor position, the document is returned to the client twice</em>. That's clear to me. But now there are two more questions, which don't get covered:</p>
  
  <ol>
  <li>What happens if I use the <code>cursor</code> token for <em>page 2</em> (where <em>document 1</em> was before the sort value change)? Will I see the old items (including <em>document 1</em>) or will I see a new generated page with freshly calculated documents?</li>
  <li>Basically the same question as before: Solr documentation says: <em>the sort value of document 17 changed so that it is before the cursor position, the document has been "skipped" and will not be returned to the client as the cursor continues to progress</em>. If I use an old <code>cursor</code> token, will I be able to retrieve <em>document 17</em>? Or is it gone forever when using the current <code>cursor</code> token sequence? <br/><br/></li>
  </ol></li>
  <li><p><strong>ElasticSearch</strong> documentation says nothing about what happens if the index changes while using <code>scroll</code>. I could imagine that it behaves the same as Solr, because both use Lucene for that functionality. <strong>But</strong> I'm completely unsure, because there's no information about that scenario.</p></li>
  </ol></li>
  <li><p><strong>How can this be faster than simple <code>size=10&amp;from=10</code> / <code>rows=5&amp;start=0</code>?</strong><br/>
  More kinda technical question, just because I'd like to understand what happens under the hood.</p>
  
  <ul>
  <li>I just wondered how (especially) Solr can do this <code>cursor</code> thing more efficient than normal pagination using <code>start</code> and <code>rows</code>. Reason: (as said above) If a document changes, it will get reindex and can be placed after/before the current <code>cursor</code>. That sounds to me, like it has to reorder all documents. And that's basically the same as the default pagination!?</li>
  </ul></li>
  </ul>
  
  <h2>EDIT:</h2>
  
  <ul>
  <li><strong>ElasticSearch</strong> documentation says <em>"A scrolled search takes a snapshot in time — it doesn’t see any changes that are made to the index after the initial search request has been made. It does this by keeping the old datafiles around, so that it can preserve its “view” on what the index looked like at the time it started."</em> So there's still the question: How does Solr handle this?</li>
  </ul>
  
  <hr>
  
  <p>Would be cool, if someone could give me some explanation how things work.</p>
  
  <p>Thanks in advance! <code>:)</code></p>