Search Integration

DSE Version: 6.0



First and foremost, all nodes in a cluster or datacenter will need to have Search functionality enabled for it to properly function.

  • DataStax Enterprise runs DSE Core and Solr with years of integration work and some secret sauce

  • Both the Search and Core services will use the same Java virtual machine to address atomicity of the data.

  • Datastax Enterprise gains the search capabilities from in Solr and Lucene

  • But our search functionality also benefits from the capabilities of DataStax Core as the core will be the integrated data store.

  • This means: There is No ETL required, Data is automatically replicated and modified as the topology changes, Enhanced functionality from Core benefits such as: Advanced Performance & Traffic Control

  • Search indexes are created on selected Cassandra™ tables, identified by keyspace and name. Index configuration drives what is searchable and how it can be searched/queried. Highly customizable and able to be modified directly through CQL.

  • Cassandra™ stores CQL row data, the data store and “raw” data.

  • Solr™ generates and stores search index information for the rows.

  • Each DSE node indexes it’s data and ranges and stores it locally, which implies replication of the search indexes as well as store data.

  • Indexes are stored on the filesystem in the Cassandra™ data directory under by default and can be configured to be placed in other locations.

  • Search index configuration consists of a Schema and configuration resource files. These are also saved in Cassandra™.

  • Located in the solr_admin.solr_resources table. Why this matters is because Resource metadata are replicated to all nodes in the DC/cluster. Meaning changes only have to be applied to one node.

  • With regards to reading and writing data, Writes are submitted through CQL. A CQL write request will also pass to DSE Search for indexing. The write can occur on any node or datacenter; the write data will be indexed as long as there is a replica on a Search node.

  • Search queries can be executed using the Cassandra Query Language (CQL). For the more Solr specific functionality, the traditional Solr HTTP API is also available. Solr™ will use the search indexes to determine the results for the query. The raw data or rows needed for the search results are then read from Cassandra™ and returned.

  • Cassandra™ data types generally have counterparts in Solr™:

    • Primitives – text, int, float, double, timestamp, uuid, etc.

    • Geo-spatial – PointType, LineStringType

    • Collections – set, list, map

    • Support for custom types – UDTs, tuples and DateRangeFields.

  • Certain Cassandra™ data types are not supported with Search

    • counter

    • Duration

No write up.
No Exercises.
No FAQs.
No resources.
Comments are closed.