DSE Search/Solr versus Open Source Solr
A comparison of DSE Search and Open Source Solr.
By virtue of its integration into DataStax Enterprise, differences exist between DSE Search/Solr and Open Source Solr (OSS).
Major differences
The major differences in capabilities are:
| Capability | DSE | OS Solr | Description |
|---|---|---|---|
| Includes a database | yes | no | A user has to create an interface to add a database to OSS. |
| Indexes real-time data | yes | no | Cassandra ingests real-time data and Solr indexes the data. |
| Provides an intuitive way to update data | yes | no | DataStax provides a SQL-like language and command-line shell, CQL, for loading and updating data. Data added to Cassandra shows up in Solr |
| Indexes Hadoop output without ETL | yes | no | Cassandra ingests the data, Solr indexes the data, and you run MapReduce against that data in one cluster. |
| Supports data distribution | yes | yes [1] | DataStax Enterprise distributes Cassandra real-time, Hadoop, and Solr data to multiple nodes in a cluster transparently. |
| Balances loads on nodes/shards | yes | no | Unlike OSS and Solr Cloud loads can be rebalanced efficiently. |
| Spans indexes over multiple data centers | yes | no | A cluster can have more than one data center for different types of nodes. |
| Automatically re-indexes Solr data | yes | no | The only way to re-index data in OSS is to have the client re-ingest everything. |
| Stores data added through Solr in Cassandra | yes | no | Data updated using the Solr API shows up in Cassandra. |
| Makes durable updates to data | yes | no | Updates are durable and written to the Cassandra commit log regardless of how the update is made. |
| Upgrades of Lucene preserve data | yes | no | DataStax integrates Lucene upgrades periodically and when you upgrade DSE, data is preserved. OSS users must re-ingest all their data when upgrading to Lucene. |
| Security | yes | no | DataStax has extended SolrJ to protect internal communication and HTTP access. Solr data can be encrypted and audited. |
[1] Requires using Zookeeper.
Minor differences
- The methods for importing data using the Data Import Handler differ. The DSE Search/Solr method is configuration-driven.
- You launch DSE Search by starting a DataStax Enterprise node in DSE Search mode. You start Solr using java -jar start.jar.
- DSE Search terminology used to describe objects differs from OSS terminology. The Defining key Solr terms section lists the differences.
- Delete by query in DSE Search differs from OSS. Deletions begin immediately. You do not need to post a commit after posting the delete command.
- The process for creating an index and reloading a schema differs.
- DSE Search has removed the Optimize button from the Core Admin UI.
- In the DSE Search schema, if you do not configure the uniqueKey field as stored
(stored="true"), DataStax Enterprise forces that flag to be true.
This change is necessary to make distributed search work.
- Behavior differs between DSE Search and OSS when you configure a non-unique field as
not stored.
In OSS, the data is lost, whereas in DSE Search, the data is stored in Cassandra. The field does not show up in the search results of DSE Search or OSS.
- DataStax provides a real-time caching directory factory flag, DSENRTCachingDirectoryFactory, that you can use to specify where files are cached.
- The autoCommit element in the Solrconfig.xml is removed in DSE Search/Solr and the
autoSoftCommit element is uncommented. You do not need to use the commit attribute in a
Solr HTTP update command.
In OSS the autoCommit element is present and uncommented. The autoSoftCommit is commented out. You need to use the commit attribute in a Solr HTTP update command.
- OSS supports relative paths set by the <lib> property in the solrconfig.xml, but DSE Search/Solr does not. Configuring the Solr library path describes a workaround for this issue that DataStax Enterprise will address in a future release.
- When using dynamic fields, the default column limit controls the maximum number of indexed columns (overall, not just dynamic field ones), as well as columns returned during queries. The column limit prevents out of memory errors caused by using too many dynamic fields.
- DSE Search/Solr uses the Cassandra commit log instead of the Solr updateLog. Atomic updates and real-time get are not supported. In Cassandra, a write is atomic at the row-level.
- In OSS, you set the data location for saving Solr data files by configuring the <dataDir>xxx</dataDir> element in the solrconfig.xml. DSE Search ignores this element and saves data in Cassandra data directory/solr.data unless you specify another location during start up.
- DSE Search/Solr supports a custom version of the Solr join operation.
Pseudo join and pivot faceting, not fully supported by DataStax Enterprise, do not belong in the differences list because OSS does not support these, or any other OSS features, in distributed mode. OSS does not distribute data in a scalable, peer-to-peer system like DataStax Enterprise does.