How Did The Voting Look Like?

Some of you may be interested in how the voting looked like. In total 48 people gave their votes – committers and PMC and community members, with PMC members having their votes marked as binding. 40 people voted for the split, 8 people voted against the split, with 33 binding votes in favor and 4 binding votes against. I would say it wasn’t a close call, the majority of the people that were voting were in favor of the split.

What Does It Really Mean?

From now on things will be moving forward slowly. The vote that passed means that Lucene and Solr will split their ways. Lucene will be the library that we all use and like and it will be moving forward with the changes in its own pace. Solr will still use Lucene as the full-text search library but may choose to incorporate the changes once they are introduced in the Lucene library or wait.

There are two main JIRA issues for those of you who are interested. The first one, the SOLR-14497 is about moving the Apache Solr project to become an Apache Software Foundation Top-Level Project. Of course it doesn’t only mean separation of the codebase and the WWW service. The PMC needs to be chosen, the commitment of the current committers has to be expressed, it has to be decided what to do with the mailing lists, continues integration, and build servers and it is only the beginning. You can see, that there is a long way ahead of Apache Solr and Lucene, before the split will be finalized. Once it is done through the cleanup of the Lucene code base will happen and the LUCENE-9375 is the JIRA issue to look if you are interested in what needs and what will be done.

The Future for Both Projects

What does the split mean for both projects? For sure it will result in smaller complexity. Each project will have its source, smaller compared to the current one. Each will have its tests and the development will go independently. Solr will not be blocking changes in Lucene and developer who wants to introduce Lucene level change will not have to do the same on Solr level. Some people know Lucene better and people who know Solr better. Smaller code base also means a smaller set of unit tests, which leads to quicker execution. That should support faster development as the developer will be able to test things quicker and in a more efficient way.

But I wanted to say one thing and maybe I should have said that upfront – Lucene and Solr were separate for a long, long time. They only shared the same repository, though two different, separate directories. Of course change in the Lucene code was forcing the changes in Solr in some cases, but that has its pros and cons. As for the rest – the mailing lists were already separate, the release binaries were already separate though highly coupled when it comes to versions, the JIRA issues are separate. What’s more, a lot of patches that are touching both projects were prepared in a way that there was a separate patch for Lucene and a separate patch for Solr.

The Future for Lucene

In my opinion, Lucene will benefit from the change. It will not have to look at Solr when doing changes. There are features like the old and deprecated numeric fields that were already removed from Lucene while still being supported in Solr. That example was brought up in the linked mailing list discussion as one of the things that developers had to struggle with while working on the projects that are tightly coupled.

Smaller, less tightly coupled code means more flexibility, quicker, and easier development. Smaller code base and fewer tests mean quicker and easier development. Not needing to adjust Solr while working on Lucene only is also a benefit, at least when looking from the library perspective.

The Future for Solr

I know, things are not black and white and there are shades of gray. We may be worried that Solr will be falling behind Lucene and not keep up the pace. Yes, this is true, but it could be already happening. Instead of updating Solr, people could just move things around. We can see that people care and that won’t change just because the projects were decoupled from each other. Of course, Solr will be given less attention by the people solely focused on Lucene development, but should they be forced to update Solr that they are not fully familiar with and are not keen on working with. It think the answer is no.

Can Solr keep up the same pace of development as it is now. I think the answer is yes. Solr can be setup to use SNAPSHOT version of Lucene and be ready to be released soon after the release of a new Lucene version. All that depends on the developers and how they will approach the changes. What’s more I think that working on SNAPSHOT version of Lucene may be better, because of using a more stable API. Solr can switch to a given development version once the API for new or updated Lucene feature is in a stable state. That will make it easier for a Solr developer to develop new features. The changes can be also incorporated in Solr own pace, which means that the changes doesn’t have to be rushed and can be polished and tested even better than they are now.

The Future for Solr.pl

Well, for us, it doesn’t change much, at least when it comes to the content that we produce. We will still be writing tutorials, quick looks and release information about Solr, that’s for sure. We also plan on tracking and publishing information about Lucene releases. We think that it will be helpful to keep track of the potential functionalities that will be sooner or later incorporated into Solr code base.

The Summary

I try to see things in bright lights. I think we should think about Lucene and Solr split as something that can help both projects. Smaller code base, faster tests, easier development, dedicated people. Let’s support both projects as we, Lucene and Solr users have interest in keeping them both alive and so does the developers that spend their time working on them. Hopefully, some time from the publication of this post we will be able to get back to it and say: “Yes, things went the right way!”. I’m keeping my fingers crossed for that and I think you should as well, even if there are question that we don’t have answers for at the moment.

A few words before we try

Choosing the right amount of shard a collection should be built of is one of those variables that needs to be known before the final deployment. After our collection was created we couldn’t change the number of shard, we were only able to add more replicas. Of course that came with consequences – if we’ve chosen the number of shards wrong we could end up with too low shards count and the only way to go was creating a new collection with the proper amount of shard and re-index our data. With the release of Apache Solr 4.3 we are now able to split shards of our collections.

Small cluster

In order to test the new shard split functionality I decided to run a small and simple cluster containing a single Solr instance with the embedded ZooKeeper and use the example collection provided with Solr. In order to achieve that I’ve run the following command:

java -Dbootstrap_confdir=./solr/collection1/conf -Dcollection.configName=collection1 -DzkRun -DnumShards=1 -DmaxShardsPerNode=2 -DreplicationFactor=1 -jar start.jar

After launching the mini cluster its view was as follows:

Test data

As usual we need some data for tests and I decided to use the example data provided with Solr. In order to index them I’ve run the following command in the exampledocs directory:

java -jar post.jar *.xml

The number of indexed documents were checked with the following command:

curl 'http://localhost:8983/solr/collection1/select?q=*:*&rows=0'

The response returned by Solr was as follows:

<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader">
  <int name="status">0</int>
  <int name="QTime">5</int>
  <lst name="params">
    <str name="q">*:*</str>
    <str name="rows">0</str>
  </lst>
</lst>
<result name="response" numFound="32" start="0">
</result>
</response>

As you can see we’ve got 32 documents in our collection.

Shard split

So now let’s try to divide the single shard our collection is built of. In order to do that we will use Collections API and a new – SPLITSHARD action. In its simplest form it takes two parameters – collection which is the collection name we want to divide and the shard which is the name of the shard we want to split. So in our case, the command that will split the shard looks like this:

curl 'http://localhost:8983/solr/admin/collections?action=SPLITSHARD&collection=collection1&shard=shard1'

If everything run without a problem, after a few seconds we will get response form Solr that indicates the end of the process. The response will look more or less like this:

<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader">
  <int name="status">0</int>
  <int name="QTime">9220</int>
</lst>
<lst name="success">
  <lst>
    <lst name="responseHeader">
      <int name="status">0</int>
      <int name="QTime">6963</int>
    </lst>
    <str name="core">collection1_shard1_1_replica1</str>
    <str name="saved">/home/solr/4.3/solr/solr.xml</str>
  </lst>
  <lst>
    <lst name="responseHeader">
      <int name="status">0</int>
      <int name="QTime">6977</int>
    </lst>
    <str name="core">collection1_shard1_0_replica1</str>
    <str name="saved">/home/solr/4.3/solr/solr.xml</str>
  </lst>
  <lst>
    <lst name="responseHeader">
      <int name="status">0</int>
      <int name="QTime">9005</int>
    </lst>
  </lst>
  <lst>
    <lst name="responseHeader">
      <int name="status">0</int>
      <int name="QTime">9006</int>
    </lst>
  </lst>
  <lst>
    <lst name="responseHeader">
      <int name="status">0</int>
      <int name="QTime">103</int>
    </lst>
  </lst>
  <lst>
    <lst name="responseHeader">
      <int name="status">0</int>
      <int name="QTime">1</int>
    </lst>
    <str name="core">collection1_shard1_1_replica1</str>
    <str name="status">EMPTY_BUFFER</str>
  </lst>
  <lst>
    <lst name="responseHeader">
      <int name="status">0</int>
      <int name="QTime">1</int>
    </lst>
    <str name="core">collection1_shard1_0_replica1</str>
    <str name="status">EMPTY_BUFFER</str>
  </lst>
</lst>
</response>

Cluster after the split

After the split our cluster view will look like this:

As we can see we have two new shards. In theory each of the new shards should contain a portion of documents from the original shard1 – some of the documents should be placed in  shard1_1 and some in shard1_0. Again using Solr administration panel we can check each of the cores (which are the actual shards):

Shard1_1

Statistics for shard with the name of Shard1_1 are as follows:

Shard1_0

And the statistics for shard with the name of Shard1_0 are as follows:

As you can see we have 32 documents in total, which is the same as in the original collection.

Cleaning up

I’ve left the cleaning up for the end. First of all in order to see the data in new shards we need to run the commit command against our collection. For example, this can be done by using the following command:

curl 'http://localhost:8983/solr/collection1/update' --data-binary '<commit/>' -H 'Content-type:application/xml'

In addition to that we can also remove the original shard, for example by using Solr administration panel or by using the CoreAPI.

Final test

As a summary I decided to test if the documents are available in the shards created by the SPLITSHARD action. In order to do that I’ve used the following command:

curl 'http://localhost:8983/solr/collection1/select?q=*:*&rows=100&fl=id,[shard]&indent=true'

And Solr responded in the following way:

<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader">
  <int name="status">0</int>
  <int name="QTime">7</int>
  <lst name="params">
    <str name="fl">id,[shard]</str>
    <str name="q">*:*</str>
    <str name="rows">100</str>
  </lst>
</lst>
<result name="response" numFound="32" start="0" maxScore="1.0">
  <doc>
    <str name="id">GB18030TEST</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_0_replica1/</str></doc>
  <doc>
    <str name="id">IW-02</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_0_replica1/</str></doc>
  <doc>
    <str name="id">MA147LL/A</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_0_replica1/</str></doc>
  <doc>
    <str name="id">adata</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_0_replica1/</str></doc>
  <doc>
    <str name="id">asus</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_0_replica1/</str></doc>
  <doc>
    <str name="id">belkin</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_0_replica1/</str></doc>
  <doc>
    <str name="id">maxtor</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_0_replica1/</str></doc>
  <doc>
    <str name="id">TWINX2048-3200PRO</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_0_replica1/</str></doc>
  <doc>
    <str name="id">VS1GB400C3</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_0_replica1/</str></doc>
  <doc>
    <str name="id">VDBDB1A16</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_0_replica1/</str></doc>
  <doc>
    <str name="id">USD</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_0_replica1/</str></doc>
  <doc>
    <str name="id">GBP</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_0_replica1/</str></doc>
  <doc>
    <str name="id">3007WFP</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_0_replica1/</str></doc>
  <doc>
    <str name="id">EN7800GTX/2DHTV/256M</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_0_replica1/</str></doc>
  <doc>
    <str name="id">SP2514N</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_1_replica1/</str></doc>
  <doc>
    <str name="id">6H500F0</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_1_replica1/</str></doc>
  <doc>
    <str name="id">F8V7067-APL-KIT</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_1_replica1/</str></doc>
  <doc>
    <str name="id">apple</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_1_replica1/</str></doc>
  <doc>
    <str name="id">ati</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_1_replica1/</str></doc>
  <doc>
    <str name="id">canon</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_1_replica1/</str></doc>
  <doc>
    <str name="id">corsair</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_1_replica1/</str></doc>
  <doc>
    <str name="id">dell</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_1_replica1/</str></doc>
  <doc>
    <str name="id">samsung</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_1_replica1/</str></doc>
  <doc>
    <str name="id">viewsonic</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_1_replica1/</str></doc>
  <doc>
    <str name="id">EUR</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_1_replica1/</str></doc>
  <doc>
    <str name="id">NOK</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_1_replica1/</str></doc>
  <doc>
    <str name="id">VA902B</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_1_replica1/</str></doc>
  <doc>
    <str name="id">0579B002</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_1_replica1/</str></doc>
  <doc>
    <str name="id">9885A004</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_1_replica1/</str></doc>
  <doc>
    <str name="id">SOLR1000</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_1_replica1/</str></doc>
  <doc>
    <str name="id">UTF8TEST</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_1_replica1/</str></doc>
  <doc>
    <str name="id">100-435805</str>
    <str name="[shard]">192.168.56.1:8983/solr/collection1_shard1_1_replica1/</str></doc>
</result>
</response>

As you can see documents came from both shard, which is again what we expected. Please remember that this is only a sample usage and we will get back to shard split topic for sure.